Java 出现挂起

Java appears hung

提问by Sarel Botha

I've been using the Java Service wrapper in a custom application for quite a while and it's been working fine. Since updating our application to a new version in the last few days the JVM started hanging and then wrapper prints this in the log: JVM appears hung: Timed out waiting for signal from JVM.

我在自定义应用程序中使用 Java 服务包装器已经有一段时间了，它运行良好。由于在最近几天将我们的应用程序更新到新版本，JVM 开始挂起，然后包装器在日志中打印：JVM 出现挂起：超时等待来自 JVM 的信号。

It then automatically terminates the JVM and starts the app again. This happens after about 10 hours of running, which just makes it harder to debug.

然后它会自动终止 JVM 并再次启动应用程序。运行大约 10 小时后会发生这种情况，这只会增加调试难度。

Of course I am going to look through the changes that we've made, but no major changes were made that I would suspect is causing this type of problem.

当然，我将查看我们所做的更改，但没有进行我怀疑会导致此类问题的重大更改。

Where can I look to try and figure out what is happening? Debug messages from the application don't indicate anything interesting. If the JVM just crashes it will usually create a dump, which can help in debugging it, but it's hanging, so it's not creating a dump. If I make it not restart the service automatically is there anything I can do to get some useful information out of the JVM before restarting it?

我在哪里可以尝试找出正在发生的事情？来自应用程序的调试消息没有表明任何有趣的事情。如果 JVM 刚刚崩溃，它通常会创建一个转储，这有助于调试它，但它挂起，所以它不会创建转储。如果我让它不自动重新启动服务，我可以做些什么来在重新启动之前从 JVM 中获取一些有用的信息？

It seems to me that the JVM shouldn't hang from typical programming errors. What have you run into before that can cause the JVM to hang?

在我看来，JVM 不应该因为典型的编程错误而挂起。您之前遇到过什么会导致 JVM 挂起？

采纳答案by Sarel Botha

I had a couple different versions of a library on the classpath (JBPM). With wrapper you can use wildcards to include jars. Be careful with this though as you may accidentally include more than you should.

我在类路径 (JBPM) 上有几个不同版本的库。使用包装器，您可以使用通配符来包含 jar。不过要小心，因为您可能会意外地包含超出应有的内容。

Here is an IBM article that gives information on debugging hangs in Java. It basically says that there are two things that can cause hangs:

这是一篇 IBM 文章，提供了有关Java 中调试挂起的信息。它基本上说有两件事会导致挂起：

1. An infinite loop,
2. A deadlock.

1. 无限循环，
2. 陷入僵局。

Since then I've had to debug other hanging issues. On linux you can send the JVM the QUIT signal to make it do a thread dump to the console. This really helps figuring out where the issue is. Use this command to do that: kill -QUIT

从那以后，我不得不调试其他挂起的问题。在 linux 上，您可以向 JVM 发送 QUIT 信号，使其向控制台执行线程转储。这确实有助于找出问题所在。使用此命令执行此操作：kill -QUIT

Edit 6/13/2017

编辑 6/13/2017

These days I use jmap included in the JDK to dump the entire memory of the program. Then I use Eclipse Memory Analyzer to see the exact state of the program when it crashed. You can look at the list of threads that are active and then inspect the variables in each stack frame.

这些天我使用JDK中包含的jmap来转储程序的整个内存。然后我使用 Eclipse Memory Analyzer 查看程序崩溃时的确切状态。您可以查看活动线程列表，然后检查每个堆栈帧中的变量。

/usr/java/latest/bin/jmap -dump:file=/tmp/app-crash.hprof <PID>

Where PID is the process ID of the java process.

其中PID是java进程的进程ID。

回答by Kevin

Read up on the wrapper.ping.timeout property. The wrapper software communicates with your JVM every so often to make sure that it is alive. If that communication fails for whatever reason, the wrapper deems the process hung and attempts to restart it.

阅读wrapper.ping.timeout 属性。包装器软件每隔一段时间与您的 JVM 通信以确保它是活动的。如果该通信由于某种原因失败，则包装器认为该进程挂起并尝试重新启动它。

Depending on how your application is architected, your JVM might be busy processing something else when the wrapper tries to "ping" it.

根据您的应用程序的架构方式，当包装器尝试“ping”它时，您的 JVM 可能正忙于处理其他事情。

回答by TofuBeer

See if you can use the Visual VMto see what is going on. Have the Visual VM monitor the app for the whole time and when it stops working perhaps you can determine what is wrong.

看看您是否可以使用Visual VM来查看发生了什么。让 Visual VM 全程监控应用程序，当它停止工作时，也许您可​​以确定哪里出了问题。

If the VM hangs you can get the state of the threads... I think the Visual VM will make it a bit easier given your setup than the usual ctrl-break (or whatver the key combo is).

如果 VM 挂起，您可以获得线程的状态......我认为 Visual VM 会让您的设置比通常的 ctrl-break（或任何关键组合）更容易一些。

(Edit based on comment)

（根据评论编辑）

Tried this. Last time it hung the number of threads and the amount of memory in use were quite low, so neither of those are causing the problem. Unfortunately after it hangs and wrapper terminates it you can't get a thread dump.

试过这个。上次它挂起的线程数和使用的内存量都非常低，所以这两者都没有导致问题。不幸的是，在它挂起并且包装器终止它之后，您将无法获得线程转储。

Is there any way you can run it without the wrapper to debug it? Also if you use the NetBeans profiler it might give you a chance to deal with it when it stops (I'll check later today and see if I can find out if that would behave differently).

有没有什么方法可以在没有包装器的情况下运行它来调试它？此外，如果您使用 NetBeans 分析器，它可能会在它停止时为您提供处理它的机会（我将在今天晚些时候检查，看看我是否能找出它的行为是否有所不同）。

回答by Charlie Martin

What environment are you in? OS, JVM version, hardware architecture?

你在什么环境？操作系统、JVM 版本、硬件架构？

That does sound like a bug, and given that it takes many hours, it sounds like a resource-exhaustion bug of some sort.

这听起来确实像一个错误，而且考虑到它需要很多小时，这听起来像是某种资源枯竭的错误。