Phaser“伪死锁”本质是线程池资源不足导致onAdvance()无法执行，进而阻塞阶段推进；应为Phaser单独配置线程池、避免onAdvance()内同步调用其他Phaser、使用超时机制并监控phase停滞与队列积压。
这个问题本质不是 Phaser 本身死锁，而是线程池资源不足导致 Phaser 阶段无法推进，形成“伪死锁”——所有参与者都抵达了屏障点，却因没有空闲线程执行 onAdvance() 或后续阶段任务而无限等待。
为什么 Executors 线程数不足会让 Phaser “卡住”
Phaser 的每个阶段结束时，若注册了 onAdvance() 回调，该回调默认由**触发 arriveAndAwaitAdvance() 的线程**（即最后一个抵达的线程）同步执行。但若该线程来自一个已满载的固定线程池，它完成 onAdvance() 后立刻被复用去执行新任务；而如果 onAdvance() 内部又提交了新任务到同一线程池，且池中无空闲线程，新任务就会排队——此时若这些新任务又依赖下一轮 arriveAndAwaitAdvance()，就形成了“等线程→等屏障→等线程”的闭环。
更隐蔽的是：若 onAdvance() 中调用了另一个 Phaser 的 arriveAndAwaitAdvance()，而那个 Phaser 也运行在同一个紧张的线程池里，两个 Phaser 就会相互阻塞，表面看像死锁，实则是线程饥饿。
关键排查信号
- jstack 显示大量线程处于
WAITING on java.util.concurrent.Phaser$Root，且堆栈末尾是arriveAndAwaitAdvance，但线程池活跃数已达 corePoolSize - 监控发现 Phaser 的
getPhase()长时间停滞不增，同时线程池队列长度持续上涨 -
onAdvance()方法体简单（如只打日志），但阶段切换延迟达秒级——说明不是逻辑慢，是没线程可跑
稳妥的修复策略
- 为 Phaser 相关任务单独配置线程池：使用
newCachedThreadPool()或带合理corePoolSize的ThreadPoolExecutor，避免与业务线程池混用 - 若必须复用现有线程池，确保其
corePoolSize ≥ 最大并发 Phaser 阶段数 × 每阶段平均参与者数，并把队列设为有界（如ArrayBlockingQueue(128)），防止任务无限堆积掩盖问题 - 在
onAdvance()内绝不调用任何可能阻塞或触发新 Phaser 等待的操作；如需异步处理，显式提交到独立线程池，并做好异常捕获 - 对关键 Phaser 设置超时：用
phaser.awaitAdvanceInterruptibly(phase, timeout, unit)替代无参版本，超时后主动记录告警并尝试恢复，避免无限挂起
一个典型错误写法与修正
错误示例（共用紧张线程池）：
❌Phaser phaser = new Phaser(3);
executor.submit(() -> {
// ... 处理阶段1数据
phaser.arriveAndAwaitAdvance(); // 最后一个线程执行 onAdvance
});
其中 onAdvance() 内又调用了 anotherPhaser.arriveAndAwaitAdvance() —— 两个 Phaser 在同一个线程池里互相等。
正确做法：
✅Phaser phaser = new Phaser(3);
// 单独配一个轻量线程池专供 Phaser 回调
ExecutorService phaserPool = Executors.newFixedThreadPool(4);
phaser.register(); // 主动注册，便于控制
phaser.onAdvance((phase, parties) -> {
if (phase == 0) {
// 异步触发下游，不阻塞当前线程
phaserPool.submit(() -> anotherPhaser.arriveAndAwaitAdvance());
}
return false;
}); 
