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

Question

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

原始问题我们最近出现了应用程序出现的情况 - 最终用户 - 要挂起.我们在应用程序重启之前得到了一个堆栈跟踪,我发现了一些令人惊讶的结果:527个线程,463个线程状态为BLOCKED.

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

不寻常的数据 在这种情况下,除了应用程序类(包括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)

Answer 1

根据收集的证据,这些大致按照我尝试的顺序列出:

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