Java 阻塞问题 : Why would JVM block threads in many different classes/methods?

Question

更新:这看起来像是内存问题。一个 3.8 Gb 的 Hprof 文件表明，当发生这种“阻塞”时，JVM 正在转储其堆。我们的运营团队看到该站点没有响应，进行了堆栈跟踪，然后关闭了该实例。我相信他们在堆转储完成之前关闭了站点。日志中没有错误/异常/问题的证据——可能是因为 JVM 在生成错误消息之前被终止了。

原始问题我们最近遇到了一个应用程序出现——对最终用户来说——挂起的情况。我们在应用程序重新启动之前获得了堆栈跟踪，并且我发现了一些令人惊讶的结果:在 527 个线程中，463 个线程状态为 BLOCKED。

过去以往被阻塞的线程通常有这样的问题:1)一些明显的瓶颈:例如某些数据库记录锁定或文件系统锁定问题导致其他线程等待。2) 所有被阻塞的线程都将阻塞在相同的类/方法上(例如 jdbc 或文件系统类)

异常数据在这种情况下，我看到各种类/方法都被阻止，包括 jvm 内部类、jboss 类、log4j 等，此外还有应用程序类(包括 jdbc 和 lucene 调用)

问题 什么会导致 JVM 阻塞 log4j.Hierarchy.getLogger、java.lang.reflect.Constructor.newInstance？显然有些资源“稀缺”，但哪种资源呢？

谢谢

将

堆栈跟踪摘录

http-0.0.0.0-80-417" daemon prio=6 tid=0x000000000f6f1800 nid=0x1a00 waiting for monitor entry [0x000000002dd5d000]
   java.lang.Thread.State: BLOCKED (on object monitor)
                at sun.reflect.GeneratedConstructorAccessor68.newInstance(Unknown Source)
                at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
                at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
                at java.lang.Class.newInstance0(Class.java:355)
                at java.lang.Class.newInstance(Class.java:308)
                at org.jboss.ejb.Container.createBeanClassInstance(Container.java:630)

http-0.0.0.0-80-451" daemon prio=6 tid=0x000000000f184800 nid=0x14d4 waiting for monitor entry [0x000000003843d000]
   java.lang.Thread.State: BLOCKED (on object monitor)
                at java.lang.Class.getDeclaredMethods0(Native Method)
                at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
                at java.lang.Class.getMethod0(Class.java:2670)

"http-0.0.0.0-80-449" daemon prio=6 tid=0x000000000f17d000 nid=0x2240 waiting for monitor entry [0x000000002fa5f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
                at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.register(Http11Protocol.java:638)
                - waiting to lock <0x00000007067515e8> (a org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler)
                at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.createProcessor(Http11Protocol.java:630)


"http-0.0.0.0-80-439" daemon prio=6 tid=0x000000000f701800 nid=0x1ed8 waiting for monitor entry [0x000000002f35b000]
   java.lang.Thread.State: BLOCKED (on object monitor)
                at org.apache.log4j.Hierarchy.getLogger(Hierarchy.java:261)
                at org.apache.log4j.Hierarchy.getLogger(Hierarchy.java:242)
                at org.apache.log4j.LogManager.getLogger(LogManager.java:198)

Answer 1

这些大致按照我尝试的顺序列出，具体取决于收集的证据:

• 您是否查看过GC 行为？你有内存压力吗？这可能会导致 newInstance() 和上面的其他几个被阻止。使用 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -verbose:gc 运行您的 VM 并记录输出。您是否在接近故障/锁定时间时看到过多的 GC 时间？
  • 条件是否可重复？如果是这样，请尝试在 JVM (-Xmx) 中使用不同的堆大小，看看行为是否有显着变化。如果是这样，请查找内存泄漏或为您的应用适当调整堆大小。
  • 如果前一个很难，并且您没有在应该得到 OutOfMemoryError 时得到，您可以调整 GC 可调参数...参见 JDK6.0 XX options , 或 JDK6.0 GC Tuning Whitepaper .具体看-XX:+UseGCOverheadLimit和-XX:+GCTimeLimit及相关选项。 (注意这些没有很好的记录，但可能有用...)
• 可能会出现僵局吗？只有堆栈跟踪摘录，无法在此处确定。在线程被阻塞的监视器状态之间寻找周期(相对于它们所持有的)。我相信 jconsole 可以为您做到这一点... ( yep, under the threads tab, "detect deadlocks" )
• 尝试做几个重复的堆栈跟踪，看看有什么变化与什么保持不变...
• 进行取证……对于每个显示“BLOCKED”的堆栈条目，去查找特定的代码行并弄清楚那里是否有监视器。如果有实际的监视器采集，识别限制资源应该相当容易。但是，如果没有透明可用的监视器，您的一些线程可能会显示阻塞，这些会比较棘手...