JBoss应用偶发性崩溃求助：线程WAITING于sun.misc.Unsafe.park

兄弟，我之前也踩过JBoss偶发性崩溃的坑，结合你给出的线程Dump片段，咱们一步步来定位问题：

1. 先锁定等待的具体对象 #

你线程Dump里的<105c9d1d>是等待对象的哈希标识，别小看这个字符串——你可以把完整的线程Dump文件导入到分析工具里（比如Eclipse Memory Analyzer，或者JDK自带的jhat命令），通过这个哈希值直接定位到对应的Java对象。这个对象大概率是某个共享资源：可能是数据库连接池里的连接、全局同步锁，甚至是自定义业务逻辑里的阻塞队列。

2. 排查资源耗尽的可能性 #

既然是偶发性崩溃，最大的嫌疑就是这个等待对象对应的资源被耗尽了，给你几个排查方向：

• 如果定位到是数据库连接：去JBoss的standalone.xml（或者domain.xml）里找<datasource>配置，检查max-pool-size是不是设得太小，再查业务代码里有没有忘记释放连接的情况（比如try块里拿了连接，finally里没close）；
• 如果是自定义锁/同步对象：检查代码里有没有死锁逻辑，或者锁的释放是不是在try-finally里确保执行了；
• 结合VisualVM的监控数据：看看崩溃前的线程数、内存占用、CPU使用率有没有异常飙升，比如线程数突然涨到几百上千，很大可能是资源没回收导致的线程堆积。

3. 补全线程栈信息 #

你给出的线程栈片段不全，完整的栈信息会显示这个线程在进入WAITING状态前执行了哪些方法——比如如果栈里有org.hibernate.Session相关的调用，那可能是Hibernate会话没释放；如果是javax.sql.DataSource.getConnection()，那就是数据库连接的问题。把完整的线程栈拉出来，能直接缩小排查范围。

4. 模拟高并发复现问题 #

偶发问题最难抓，你可以用JMeter这类压测工具模拟高并发场景，尽量复现崩溃。复现成功后，同时抓取完整线程Dump和堆Dump，两个文件结合分析，基本就能找到根因了。

附上你提到的阻塞线程日志：

"http-/0.0.0.0:8080-459" - Thread t@2309
java.lang.Thread.State: WAITING
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <105c9d1d> (a java....

内容的提问来源于stack exchange，提问作者Gian Honório