java假死真正诱因是长循环（如while(true)）绕过safepoint导致gc线程无限等待，jstack显示线程runnable但无栈帧；修复需插入thread.onspinwait()、parknanos(1)或改用标准调度机制。
长循环本身不会直接触发 JVM 假死，但会让线程长期卡在 Safepoint 门外，导致 GC 线程等不到所有线程进入安全点而无限等待 —— 这才是假死的真正诱因。
为什么 while(true) 会让 jstack 看不到线程栈？
Java 线程只有在到达 Safepoint（如方法返回、循环边界、方法调用前）才能被 JVM 暂停。如果代码写成：
while (true) {
// 没有方法调用、没有分支跳转、没有内存分配
i++;
}
JVM 就无法插入 Safepoint 检查，线程会一直跑在原生指令里，jstack 查看时状态显示为 runnable 但堆栈为空或只到 Unsafe.park 之类底层调用，实际是“不可暂停”。GC 线程发起 Stop-The-World 后，卡在这类循环里的线程不响应，整个 STW 就卡住，表现为 CPU 高、接口无响应、jstat 显示 GC 挂起超时。
- 常见场景：监控轮询、自旋等待、未加
Thread.yield()或LockSupport.parkNanos(1)的忙等逻辑 - 注意：
-XX:+UseCountedLoopSafepoints可在计数循环中插 Safepoint，但仅对for(int i=0; i<n i> 类型有效，对 <code>while(true)或while(flag)无效 - 验证方式：用
jstat -compiler <pid></pid>查看failed_safepoint_count是否持续增长（JDK 8u212+ 才暴露该字段）
如何用 jstack 和 top -Hp 定位卡在 Safepoint 外的线程？
先用 top -Hp <pid></pid> 找出高 CPU 线程 ID，再转成十六进制，用 jstack 搜索：
jstack <pid> | grep -A20 'nid=0x[0-9a-f]'</pid>
重点看两类现象：
- 线程状态是
runnable，但堆栈只到JavaMain、Interpreter或空行，没业务代码行号 - 大量线程堆栈停在
Unsafe.park、Object.wait等阻塞点，但jstat -gcutil <pid> 1000</pid>显示FGC时间极长（比如 >5s），且YGC频次骤降 —— 说明 GC 在等这些线程进 Safepoint - 配合
jinfo -flag +PrintSafepointStatistics <pid></pid>（需提前开启，或用sudo jcmd <pid> VM.native_memory summary</pid>辅助）可查看 Safepoint 进入耗时分布
怎么避免循环绕过 Safepoint？
不是所有循环都危险，关键看 JVM 能否在循环体中插入检查点。以下写法风险递增：
- ✅ 安全：
for (int i = 0; i （JIT 编译后通常有 Safepoint） - ⚠️ 风险：
while (i++ （依赖循环变量变化，部分 JDK 版本可能漏插） - ❌ 高危：
while (true) { /* 纯计算 */ }、while (flag) { /* 无方法调用 */ }
修复建议：
- 在循环体内加
Thread.onSpinWait()（JDK 9+），提示 JVM 此处是自旋，可主动插入 Safepoint - 或退化为
Thread.sleep(1)/LockSupport.parkNanos(1)，强制让出 CPU 并确保 Safepoint 可达 - 避免手写“无副作用”长循环；改用
ScheduledExecutorService或带超时的wait()等标准协作机制
PrintSafepointStatistics 日志怎么看？
启用后（启动参数加 -XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1），GC 日志里会出现类似：
Safepoint "ThreadDump", Time since last: 123456789 ns Total time for which application threads were stopped: 456789012 ns
重点关注：
-
Time since last异常大（秒级）→ 说明有线程迟迟不进 Safepoint -
application threads were stopped超过 100ms → STW 严重，用户请求必然超时 - 日志末尾的
Threads waiting to reach safepoint列出具体线程 ID，直接对应top -Hp结果
这类日志必须在问题复现时开启，线上慎用（有性能开销）；更推荐用 AsyncProfiler 抓取 safepoint_begin 事件做采样分析。
