根据收集的证据，大致按照我尝试的顺序列出了这些内容：
- 您是否看过 GC行为 ？您是否承受着记忆压力？这可能会导致
newInstance()
上面的其他一些被阻止。运行VM-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -verbose:gc
并记录输出。在故障/锁定时间附近，您是否看到过多的GC时间？- 条件可以 重复 吗？如果是这样，请尝试在JVM（-Xmx）中使用不同的堆大小，然后查看行为是否发生了重大变化。如果是这样，请查找内存泄漏或为应用程序适当调整堆大小。
- 如果以前的操作很困难，并且您没有获得
OutOfMemoryError
应有的帮助，则可以调整GC可调参数…请参阅JDK6.0 XX选项或JDK6.0 GC Tuning Whitepaper。在专门研究-XX:+UseGCOverheadLimit
，并-XX:+GCTimeLimit
与相关的选项。（请注意，这些文件的记录不充分，但可能会有用…）
- 可能会 陷入僵局 吗？仅具有堆栈跟踪摘录，无法在此处确定。在线程被阻塞的监控器状态（相对于它们所保持的状态）中寻找周期。我相信
jconsole
可以为您做到这一点…（是的，在“线程”选项卡下，“检测死锁”） - 尝试进行多次 重复的堆栈跟踪 ，以查找哪些变化与什么保持不变…
- 对每个表示“已阻止”的堆栈条目进行取证…，然后查找特定的代码行，并确定那里是否有监视器。如果实际购买了监控器，那么确定限制资源应该相当容易。但是，如果没有透明可用的监视器，您的某些线程可能会显示为阻塞，这将更加棘手…
