ThreadPoolExecutor 中不存在 addWorkerFailed 方法，其 addWorker 失败时的回滚逻辑（如 decrementWorkerCount、移除 workers）均由内部自动完成，用户无需也不应干预。
ThreadPoolExecutor 中并没有名为 addWorkerFailed 的公开或受保护方法。
你可能是看到某些源码分析文章中提到的 addWorker 方法内部的失败回滚逻辑，或者混淆了方法名。实际在 ThreadPoolExecutor 源码（如 JDK 8/11）中：
- 核心方法是
private boolean addWorker(Runnable firstTask, boolean core)； - 当
addWorker执行失败（例如线程创建失败、线程池已 shutdown、拒绝策略触发等），它会 自动执行回滚操作，主要包括：- 如果已成功将 worker 添加到
workers集合，但后续启动线程失败，则从集合中移除该 worker； - 如果只是原子更新了
ctl（即线程数计数器）但 worker 未真正加入集合，则调用decrementWorkerCount()回退计数； - 确保
workerCount（由ctl的低29位表示）与实际存活的 worker 数量严格一致。
- 如果已成功将 worker 添加到
addWorker 失败时的关键回滚步骤
当 `addWorker` 返回 false（表示添加失败），说明整个流程中途退出，此时框架已自行完成一致性修复：
- 先尝试 CAS 更新 ctl 增加 workerCount：若失败（比如线程池状态突变），直接返回 false，无需回滚（因为计数根本没变）；
-
若 ctl 更新成功，但 new Thread() 抛异常（如 OOM）：则立即调用
decrementWorkerCount()恢复计数，并跳过后续添加逻辑； -
若线程创建成功，但加入 workers Set 失败（极罕见，如并发修改）：同样调用
decrementWorkerCount()，并确保该 Thread 不被启动； -
若 worker 加入 Set 成功，但 thread.start() 后立即抛异常：
runWorker尚未执行，该 worker 会在processWorkerExit中被正常清理（包括计数减一、从 Set 移除、触发替换等）。
你不需要、也不应该手动调用“回滚”
这些逻辑全部封装在 `addWorker` 内部，属于线程池自我维护的核心机制：
立即学习“Java免费学习笔记（深入）”；
- 不暴露
addWorkerFailed这样的钩子方法； - 用户代码无法也不应干预
ctl或workers的一致性维护； - 若你自定义了
ThreadFactory并在其中抛异常，线程池仍能正确回退（见上一条）； - 唯一需要关注的是：确保
ThreadFactory.newThread()尽量轻量且不抛预期外异常。
如何验证计数是否准确？
可通过以下方式观察线程池状态，确认无泄漏或计数错乱：
-
getPoolSize()→ 当前 worker 总数（对应workers.size()）； -
getActiveCount()→ 正在执行任务的 worker 数； -
getCompletedTaskCount()+getTaskCount()可辅助判断吞吐是否正常； - 在
RejectedExecutionHandler中记录拒绝事件，间接反映addWorker频繁失败（如资源耗尽）；
如果发现 `getPoolSize()` 长期高于预期，且无活跃任务，大概率是 worker 异常卡死（如死循环、阻塞未响应），而非计数未回滚。
不复杂但容易忽略
