需要调用System.err.close()，否则JVM不会退出。为什么？
我们有一个（非常）多线程的应用程序，它可以通过所有单元测试，但从 IDE 或命令行运行时不会退出。该应用程序不仅是多线程的，它还执行本机进程，并写入标准错误和标准输出。 问题是应用程序会在退出时挂起。最终，我减少了应用程序，直到它与单元测试相同，但它仍然会挂起，因此，我认为 JUnit 正在做一些命令行启动没有做的事情。
当我在 main(args) 末尾调用 System.exit() 时，应用程序将退出，最终导致我进入 System.err.close()。
当然，应用程序永远不会“打开”System.err 或 System.out。它只是写入它们，并在完成后调用flush()。我只在 64 位 Windows 上进行了测试，稍后我将在 Linux 上进行测试。 JVM 是 Java(TM) SE 运行时环境（内部版本 1.6.0_24-b07）
您知道为什么 JVM 不会退出吗？
We have a (very) multithreaded application that would pass all unit tests, but would not exit when run from the IDE or command line. This app is not only multi-threaded, it executes native processes, and writes to standard error and standard out.
The problem was that the app would hang on exit. Eventually, I reduced the app until it was identical to the unit tests, and it would still hang, so, I figured that JUnit was doing something that a command-line launch was not.
When I called System.exit() at the end of main(args), the app would exit, which finally lead me to System.err.close().
Of course, the app never "opens" System.err or System.out. It just writes to them, and calls flush() when finished. I've only tested on 64 bit Windows, I'll test later on Linux. The JVM is Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Any ideas why the JVM won't exit?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我似乎记得当你调用本机进程时，你必须小心地完全读取本机进程和/或错误流，否则事情可能会锁定。我认为您可能需要生成一个线程来处理这个问题。只是一个想法。
I seem to remember that when you are calling native processes, you have to be careful to fully read the native processes out and/or err streams, or things can lock up. I think you may need to spawn off a thread to handle this. Just a thought.
Linux 上的所有程序都在某种程度上面临这个问题。具有打开文件句柄的进程（您显然有一个，即使您没有专门打开一个文件句柄，它来自您的系统命令操作之一）在所有句柄都关闭之前不会完全退出。目前我能想到的最好的例子是我在工作中遇到的一个问题，启动java进程的启动脚本（bash）从未退出。问题是，我们正在做2>&1> /path/to/log & 不会关闭标准输入（文件句柄 0）。将其链接到 > /path/to/log 解决了这个问题，因为 &>表示所有文件句柄，而另一个仅表示 stdin 和 stderr。
您的问题是相似的，并且它是多线程的事实加剧了问题。
All programs on Linux face this problem to some extent. A process with an open filehandle (and you obviously have one, even though you didn't specifically open one, it came from one of your system command operations) won't fully exit until all the handles are closed. The best example I can think of at the moment is a problem I had at work where a startup script (bash) which starte a java process never exited. The problem was, we were doing 2>&1 > /path/to/log & which doesn't close stdin (file handle 0). Chainging it to &> /path/to/log fixed the problem, because &> means all filehandles, while the other just meant stdin and stderr.
Your problem is similar, and the fact that it is multithreaded exacerbates the issue.