为什么连续两次处置JDialog框会出现这种效果
经过近五周的努力，我今天解决了一个错误。发生的情况是，在我连续两次处理 JDialog 框后，客户端计算机上的 CPU 出现峰值（50% 到 100%）。
我实际上在对象中处理了它，然后在创建对象的方法中处理了它，这是一个愚蠢的错误。我花了一段时间才找到它，因为我不会导致空指针异常，而是会在进程资源管理器中看到大量与 MSVCR71.dll 关联的 CSWITCH Delta。
使用分析器让我找到了正确的解决方案。
我的问题：
为什么我没有得到空指针异常？
高 CPU 和 CSWITCH Delta 之间有什么联系？
为什么尝试处理对话框两次会导致这种情况？
谢谢，
埃利奥特
I solved a bug today after almost five weeks of effort. What was happening was the CPU on the client machine was spiking (at 50 to 100 percent) after I disposed of a JDialog box twice in a row.
I actually disposed of it in the object and then in the method that created the object, a stupid bug. It took me a while to find it because instead of causing a null pointer exception, I would see in process explorer lots of CSWITCH Deltas associated with MSVCR71.dll.
Using a profiler led me to the right solution.
My questions:
Why didn't I get a null pointer exception?
What was the connection between the high CPU and the CSWITCH Deltas?
Why would trying to dispose a dialog box twice cause this?
Thanks,
Elliott
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
重量级同行
Window是JDialog的父级，由主机操作系统管理。不存在空指针异常，因为那是在 Java 中，而不是主机操作系统。
连接位于
dispose()，它通过 JNI 与主机操作系统通信。我怀疑，但无法证明，受影响的
.dll是罪魁祸首。The heavyweight peer
Windowthat is the parent of theJDialogis managed by the host operating system.There is no null pointer exception because that is in Java, not the host OS.
The connection lies in
dispose(), which communicates with the host OS via JNI.I suspect, but cannot prove, that the affected
.dllis to blame.