我是否必须在 Webstart 应用程序中显式调用 System.exit() ？
最近我将 Swing 应用程序转换为 Webstart。 该过程非常简单，但我发现在关闭所有窗口后，我的应用程序的 JVM 并未终止。 线程转储显示有几个非守护线程，特别是 Swing 的 EDT、AWT 和几个与 websart 相关的线程。
实际使用的策略是每个窗口在创建时增加一个计数器，在关闭时减少一个计数器。 默认关闭操作是DISPOSE_ON_CLOSE。 当计数器达到零时，我停止所有线程池并释放所有 JNI 资源。
当我从 bat 文件（相同的 JAR）启动应用程序时，当所有窗口都关闭时它会正常终止，所以我认为问题与 Webstart 有关。
现在的问题是：
- 有人能告诉我到底发生了什么吗？ 为什么 Webstart 会留下僵尸 JVM？
- 有没有办法在不停止 JVM 的情况下显式释放 Webstart 资源？
- 我一直认为，调用 System.exit() 会鼓励不释放资源并依赖操作系统在您之后进行清理的草率做法（如果您稍后重用代码，这可能会导致令人讨厌的意外）...我错过了什么吗？
另请参阅后续内容问题用于检测应用程序是否已由 Webstart 启动。
Recently I converted a Swing application to Webstart. The process was pretty straightforward, but I found that after I close all windows, my application's JVM did not terminate. The thread dump showed that there are a couple of non-daemon threads, notably Swing's EDT, AWT and a couple of websart related threads.
The actual strategy used is that each window increments a counter when it is created and decrements one when it is closed. The default close operation is DISPOSE_ON_CLOSE. Wen the counter reaches zero, I stop all threadpools and release all JNI resources.
When I launched the application from a bat file (same JARs), it terminated fine when all windows were closed, so I figured that the problem has something to do with Webstart.
Now the questions:
- Can anybody tell me what exactly is happening? Why does Webstart leave zombie JVMs?
- Is there a way to release the Webstart resources explicitly without halting the JVM?
- I've always had the opinion that calling System.exit() encourages the sloppy practice of not releasing your resources and relying on the OS to clean up after you (which can lead to nasty surprises if you reuse the code later)... am I missing something?
See also the followup question for detecting whether the app has been launched by Webstart.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
因为 WebStart 中的错误，是的。 WebStart 出于其自身目的启动一个“安全线程”，与 EDT 进行交互。 当所有窗口和 AWT 资源都被释放时，该 SecureThread 可以防止 Java 进程自动终止。
有关详细信息，请参阅 http://www.pushing-pixels.org/?p=232< /a>
Because of bugs in WebStart, yes. WebStart starts up a "secure thread" for it's own purposes that interacts with the EDT. This SecureThread prevents the automatic termination of the Java process one would expect when all windows and AWT resources are disposed.
For more information see http://www.pushing-pixels.org/?p=232
AWT EDT 通常是罪魁祸首。 多年来，当没有未处理的窗口时，它有一些关闭的逻辑。 然而，泄漏问题反复出现，包括在 AWT 和 Swing 的实现中。 因此，我强烈建议在生产版本中使用 System.exit （您可能希望将其保留以进行一些测试以检测泄漏）。
当没有系统窗口（控制台、javax.jnlp 服务和其他对话框）显示时，WebStart 线程应该都是守护进程。
The AWT EDT is usually the culprit. For some years now it has had some logic to shutdown when there are no undisposed windows. However, there are recurrent problems with leaks, including within the implementation of AWT and Swing. Therefore, I strongly suggest using System.exit in production releases (you might possibly want to leave it out for some testing to detect leaks).
The WebStart thread should all be daemon when there are no system windows (console, javax.jnlp services and other dialogs) showing.
Webstart 启动控制台窗口（您可以禁用它）。 控制台窗口用于查看 Webstart 进程的 stdout/err 以及基本日志/调试，但具有创建顶级 AWT/Swing 窗口的副作用。 由于 AWT/EDT 仅在处理完最后一个窗口后才结束，因此控制台窗口会阻碍您的应用程序。 您可能应该调用 System.exit() 来 100% 确定您的应用程序退出（除非您可以保证某个客户端配置，Webstart 控制台关闭）
Webstart starts the Console window (you may be able to disable that). The console window is used to see stdout/err of the webstart process as well as rudimentary log/debug but has the side effect of created a top-level AWT/Swing window. Since the AWT/EDT only ends when the LAST window is disposed, the console window is holding up your application. You should probably call System.exit() to be 100% sure your application exits (unless you can gurantee a certain client configuration, webstart console turned off)
考虑附加 jconsole 并查看 JVM 正在做什么。
Consider attaching with jconsole and get a look at what the JVM is doing.
我在网络启动时遇到了同样的问题。 如果我关闭 java 控制台，该进程不会挂起。 Sun 有任何已知的 bug id 吗？
I experience the same issue with web start. If i turn off java console, the process does not hang up. Any known bug id from Sun?