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

更新：这看起来像一个内存问题. 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)

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

你看过GC行为吗？你在记忆中的压力吗？这可能会导致newInstance()和其他几个被阻止.使用-XX：PrintGCDetails -XX：PrintGCTimeStamps -verbose：gc运行虚拟机并记录输出.在故障/锁定时间附近是否看到过多的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”的每个堆栈条目进行取证…,查找特定的代码行,并找出是否有监视器在那里.如果有一个实际的监视器采集,应该很容易识别限制资源.但是,有些线程可能会在没有透明可用的监视器的情况下显示被阻止,这些将会更加棘手…