Java阻塞问题：为什么JVM会在许多不同的类/方法中阻塞线程？
更新：这看起来像一个内存问题。 一个3.8 Gb的Hprof文件表明当发生“阻塞”时，JVM正在转储它的堆。 我们的运营团队发现该站点没有响应，进行了堆栈跟踪，然后关闭了该实例。 我相信他们在堆转储完成之前关闭了网站。 日志没有错误/exception/问题证据 – 可能是因为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 (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运行VM-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -verbose:gc并记录输出。 您是否在故障/锁定时间附近看到过多的GC时间？- 病情可重复吗？ 如果是这样，请尝试在JVM（-Xmx）中使用不同的堆大小，并查看行为是否发生了实质性变化。 如果是这样，请查找内存泄漏或正确调整应用程序的堆大小。
- 如果前一个很难，并且您没有得到
OutOfMemoryError，则可以调整GC可调参数…请参阅JDK6.0 XX选项或JDK6.0 GC调优白皮书 。 请特别注意-XX:+UseGCOverheadLimit和-XX:+GCTimeLimit及相关选项。 （注意这些没有很好的记录，但可能有用……）
- 可能会出现僵局吗？ 只有堆栈跟踪摘录，无法在此确定。 在监视器状态中查找线程被阻塞的循环（与它们持有的东西相比）。 我相信
jconsole可以为你做这个…（ 是的，在线程选项卡下，“检测死锁” ） - 尝试做几次重复的堆栈跟踪 ，看看哪些变化与保持相同的变化……
- 取证器…对于每个堆栈条目“BLOCKED”，请查找特定的代码行并确定是否有监视器。 如果有实际的监视器采集，则识别限制资源应该相当容易。 但是，如果没有透明可用的监视器，您的某些线程可能会显示阻塞，这些将更加棘手……