full gc引发的stw会使线程池所有工作线程被jvm强制挂起，状态仍显示runnable但实际不执行代码，任务执行延迟、队列积压，根本解法是减少full gc而非调优线程池。
当 Java 应用在运行期因 Full GC 触发 Stop-The-World（STW）时，线程池中的工作线程会全部进入阻塞状态，且线程状态统一变为 RUNNABLE（但实际不执行任何用户代码）——这是 JVM 层面的强制暂停，与线程本身的逻辑状态无关。
这个现象容易被误解。表面上看，用 jstack 查到的线程仍显示为 java.lang.Thread.State: RUNNABLE，但这只是 JVM 线程状态机的“名义状态”，不代表线程正在 CPU 上运行或执行任务。真实情况是：所有用户线程（包括线程池中正在处理任务的 Worker 线程）被 JVM 在安全点（SafePoint）强制挂起，等待 GC 完成。
Full GC 期间线程池线程的实际表现
- 所有活跃的线程池线程（如
ThreadPoolExecutor$Worker）停止执行业务逻辑，不响应新任务、不处理队列、不调用run()中的代码 - 线程堆栈停留在 GC 发生前的任意位置（可能是
Runnable.run()、Future.get()、IO 阻塞前、甚至synchronized块入口），但不会推进 - 线程未进入
WAITING或BLOCKED状态，因此不会出现在锁竞争或条件等待的排查路径中 - 如果线程正持有锁（如
ReentrantLock或synchronized），该锁会被一直持有，直到 STW 结束——这可能间接加剧后续请求的排队或超时
如何验证线程是否受 STW 影响
可通过以下方式交叉确认：
使用
jstat -gc <pid></pid>观察FGC（Full GC 次数）和FGCT（Full GC 总耗时）突增，同时jstack <pid></pid>输出中大量线程停在相似方法调用处（如Object.wait、Unsafe.park、或某业务方法中间）-
开启 GC 日志（
-Xlog:gc*,safepoint），查看safepoint相关日志，例如：Safepoint "GenCollectForPermanentAllocation" (reason: GC) reached in 12.432ms Total time for which application threads were stopped: 0.387s
这说明所有线程（含线程池线程）被挂起约 387ms
注意：
jstack抓取的是 STW 结束后的快照，所以看到的是“恢复后”的状态，不是 STW 过程中实时冻结态；真正冻结时，JVM 不允许任何 Java 级操作（包括 jstack 本身也无法获取完整一致快照）
对线程池行为的连带影响
- 任务提交不受影响（
execute()/submit()仍成功），但实际执行被延迟，导致任务队列积压、拒绝策略触发、Future.isDone()返回false时间延长 -
ScheduledThreadPoolExecutor的定时任务会整体“跳过” STW 时段，下次执行时间 = 原定时间 + STW 时长（取决于scheduleAtFixedRate还是scheduleWithFixedDelay） - 若 STW 持续时间超过监控阈值（如健康检查超时、RPC 调用超时），可能引发熔断、重试风暴或下游级联故障
关键提醒
- 线程池本身不能规避 STW，它无法“绕开” JVM 的内存管理机制
- 减少 Full GC 是根本解法，而非调整线程池参数（如增大核心线程数或队列容量）——后者反而可能因更多对象存活加剧老年代压力
- 若发现线程池线程频繁卡在
Unsafe.park或Object.wait后长时间无进展，需优先排查是否由 Full GC 引起，而不是直接归因为锁或 IO 问题
本质上，线程池只是用户线程的组织形式；STW 是 JVM 对所有用户线程的统一调度干预，不区分来源。识别这点，才能避免在线程分析中走入“查锁、查死循环、查同步块”的误区。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
