Java1.8_45中ThreadPoolExecutor使用ArrayBlockingQueue引发死锁排查求助

• 检查AQS节点waitStatus异常修改
  ArrayBlockingQueue依赖AQS的Condition实现等待/唤醒逻辑，signal时会检查节点的waitStatus，若不为0则不会unpark线程。排查是否有字节码增强工具（如AOP、自定义Agent）、第三方框架意外修改了队列内部AQS节点的waitStatus值，破坏了Condition的唤醒逻辑。

• 排查消费线程的任务执行异常
  导出线程栈确认消费线程的真实状态：

  • 确认线程是否真的卡在ArrayBlockingQueue.take()的Condition await阶段，还是任务执行中存在隐性阻塞（如未释放的锁、无限循环、IO挂起）导致线程假死；
  • 检查线程是否在任务执行时触发InterruptedException但未重置中断状态，后续调用take()会直接抛出异常退出，导致线程池可用线程逐步耗尽，最终触发队列满+线程池满的拒绝策略。

• 验证JVM版本的已知Bug
  部分JDK版本存在AQS或ArrayBlockingQueue的Condition实现Bug，导致signal无法正常唤醒等待线程。核对当前JDK版本，查看官方Release Notes中是否有相关并发组件的修复记录（如JDK8u20之前的部分版本存在Condition唤醒异常问题）。

• 排查队列的非法并发操作
  确认是否有代码绕过线程池直接操作ArrayBlockingQueue（如手动调用add()/poll()），这种操作可能破坏队列内部状态一致性（如count变量与实际元素数量不匹配），导致signal逻辑无法定位到正确的等待头节点，无法唤醒线程。

• 检查线程池状态与拒绝策略
  确认线程池是否被误触发shutdown()/terminate()；同时验证拒绝策略是否被自定义修改，排除策略异常导致的连锁问题（当前抛出RejectedExecutionException符合默认AbortPolicy，但需确认策略逻辑未干扰队列正常运作）。

内容的提问来源于stack exchange，提问作者yangzhe