Java 阻塞问题:为什么 JVM 会阻塞许多不同类/方法中的线程?

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

原始问题 我们最近遇到过一种情况,即应用程序似乎(对于最终用户而言)挂起。在应用程序重新启动之前,我们得到了一个堆栈跟踪,我发现了一些令人惊讶的结果:在527个线程中,有463个线程的状态被阻止。

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

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

问题是什么会导致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)

答案 1

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

  • 你有没有看过GC行为?您是否处于记忆压力之下?这可能导致上面的其他一些被阻止。运行 VM 并记录输出。您是否在故障/锁定时间附近看到过多的 GC 时间?newInstance()-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -verbose:gc
    • 这种情况是可重复的吗?如果是这样,请尝试在 JVM (-Xmx) 中使用不同的堆大小,并查看行为是否发生了重大变化。如果是这样,请查找内存泄漏或正确调整应用的堆大小。
    • 如果前一个很难,并且你没有在你应该得到的时候,你可以调整GC可调...请参阅 JDK6.0 XX 选项JDK6.0 GC 调优白皮书。请专门查看 和 相关选项。(请注意,这些没有很好的记录,但可能很有用...)OutOfMemoryError-XX:+UseGCOverheadLimit-XX:+GCTimeLimit
  • 是否会陷入僵局?仅使用堆栈跟踪摘录,无法在此处确定。在监视器状态中查找线程被阻塞的周期(与它们所包含的线程相比)。我相信可以为您做到这一点...(是的,在线程选项卡下,“检测死锁”jconsole)
  • 尝试执行多个重复的堆栈跟踪,并查找哪些更改与保持不变的内容...
  • 做取证...对于每个显示“BLOCKED”的堆栈条目,查找特定的代码行并找出那里是否有监视器。如果有实际的监视器获取,则识别限制资源应该相当容易。但是,您的某些线程可能会在没有透明可用监视器的情况下显示被阻止,这些线程将更加棘手...

答案 2