blocks|key|3625741|text|你在什么环境中？操作系统、JVM版本、硬件架构？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3625742|这听起来确实像是一个bug，而且考虑到它需要花费很多时间，它听起来像是某种资源耗尽的bug。|3625743|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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

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

blocks|key|1066107|text|在wrapper.ping.timeout+property上阅读。包装器软件每隔一段时间就会与JVM进行通信，以确保它是活动的。如果由于某种原因导致通信失败，包装器会认为进程挂起并尝试重新启动它。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1066108|根据应用程序的体系结构，当包装器试图"ping“应用程序时，JVM可能正忙于处理其他事情。|1066109|entityMap|0|LINK|mutability|MUTABLE|url|http://wrapper.tanukisoftware.org/doc/english/prop-ping-timeout.html^0|1|T|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

Read up on the <a href="http://wrapper.tanukisoftware.org/doc/english/prop-ping-timeout.html" rel="noreferrer">wrapper.ping.timeout property</a>. 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.

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

blocks|key|3625826|text|看看您是否可以使用Visual+VM来查看发生了什么。让Visual+VM全程监控应用程序，当它停止工作时，也许您可以确定哪里出了问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3625827|如果虚拟机挂起，您可以获得线程的状态...我认为在给定设置的情况下，Visual+VM会比通常的ctrl-break组合键(或其他组合键)更容易。|3625828|(根据评论进行编辑)|3625829|3625830|试过这个。上一次挂起时，线程的数量和使用的内存量都很低，所以这两项都不会导致问题。不幸的是，在它挂起和包装器终止它之后，你不能得到一个线程转储。|blockquote|3625831|3625832|3625833|有没有办法在没有包装器的情况下运行它来调试它？此外，如果您使用NetBeans分析器，它可能会在它停止时给您一个处理它的机会(我将在今天晚些时候检查，看看我是否可以发现这是否会有不同的行为)。|3625834|entityMap|0|LINK|mutability|MUTABLE|url|https://visualvm.dev.java.net/^0|9|9|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@$A|Y|B|Z|1|10]]|C|$]]|$1|D|3|E|5|6|7|11|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|12|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|13|8|@]|9|@]|C|$]]|$1|I|3|J|5|K|7|14|8|@]|9|@]|C|$]]|$1|L|3|-4|5|6|7|15|8|@]|9|@]|C|$]]|$1|M|3|-4|5|6|7|16|8|@]|9|@]|C|$]]|$1|N|3|O|5|6|7|17|8|@]|9|@]|C|$]]|$1|P|3|-4|5|6|7|18|8|@]|9|@]|C|$]]]|Q|$R|$5|S|T|U|C|$V|W]]]]

See if you can use the <a href="https://visualvm.dev.java.net/" rel="nofollow noreferrer">Visual VM</a> to 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.

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).

(Edit based on comment)

<blockquote>
 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.
</blockquote>

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).

blocks|key|407162|text|我在类路径上有两个不同版本的库(JBPM)。使用wrapper，您可以使用通配符来包含jars。不过，要注意这一点，因为您可能会意外地包含超过您应该包含的内容。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|407163|下面是一篇关于debugging+hangs+in+Java的文章。它基本上是说有两件事会导致挂起：|offset|length|407164|407165|An死循环，|ordered-list-item|407166|A+deadlock。|407167|407168|从那时起，我不得不调试其他挂起的问题。在linux上，您可以向JVM发送退出信号，让它将线程转储到控制台。这确实有助于找出问题所在。使用以下命令:+kill+-QUIT|407169|编辑2017年6月13日|407170|现在，我使用JDK中包含的jmap来转储程序的全部内存。然后，我使用Eclipse+Memory+Analyzer查看程序崩溃时的确切状态。您可以查看活动线程的列表，然后检查每个堆栈帧中的变量。|407171|/usr/java/latest/bin/jmap+-dump:file=/tmp/app-crash.hprof+<PID>|code-block|syntax|javascript|407172|其中PID是java进程的进程ID。|407173|entityMap|0|LINK|mutability|MUTABLE|url|http://publib.boulder.ibm.com/infocenter/javasdk/v1r4m2/index.jsp?topic=/com.ibm.java.doc.diagnostics.142j9/html/debughangwin.html^0|0|7|N|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|17|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|18|8|@]|9|@$D|19|E|1A|1|1B]]|A|$]]|$1|F|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|1D|8|@]|9|@]|A|$]]|$1|J|3|K|5|I|7|1E|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|1F|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|1G|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1H|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1I|8|@]|9|@]|A|$]]|$1|S|3|T|5|U|7|1J|8|@]|9|@]|A|$V|W]]|$1|X|3|Y|5|6|7|1K|8|@]|9|@]|A|$]]|$1|Z|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]]|10|$11|$5|12|13|14|A|$15|16]]]]

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.

Here is an IBM article that gives information on <a href="http://publib.boulder.ibm.com/infocenter/javasdk/v1r4m2/index.jsp?topic=/com.ibm.java.doc.diagnostics.142j9/html/debughangwin.html" rel="nofollow noreferrer">debugging hangs in Java</a>. It basically says that there are two things that can cause hangs:

<ol>
<li>An infinite loop,</li>
<li>A deadlock.</li>
</ol>

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 

Edit 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.

<pre><code>/usr/java/latest/bin/jmap -dump:file=/tmp/app-crash.hprof &lt;PID&gt;
</code></pre>

Where PID is the process ID of the java process.

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.

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.

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?

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?

Java appears hung

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我在自定义应用程序中使用Java服务包装器已经有一段时间了，它一直运行得很好。由于在最近几天将应用程序更新到新版本，JVM开始挂起，然后包装器在日志中打印以下内容: JVM显示挂起:超时等待来自JVM的信号。然后，它会自动终止JVM并再次启动应用程序。这发生在大约10小时的运行之后，这只会增加调试的难度。当然，我会检查...

问Java显示为挂起
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Java显示为挂起EN