高频循环无安全点导致STW飙升，因线程卡在安全点门外；while(true)、long型for循环、纯计算循环及深度内联嵌套循环易绕过安全点；可通过PrintSafepointStatistics、jstat、jstack等定位；修复用Thread.onSpinWait()或parkNanos(1)等主动触发安全点。
高频循环里没有安全点，GC 就只能干等线程自己“走过来”，停不下来，STW 时间就飙升——这不是 GC 慢，是线程卡在了安全点门外。
哪些循环会绕过安全点？
HotSpot 只在特定位置插入安全点检查，不是所有循环都自带“停车区”：
- while(true)、while(flag)：无明确退出条件，JIT 不认为是计数循环，不插安全点
- for(long i = 0; i （N 是 long 类型）：JIT 默认不视为计数循环，回边处无安全点
- 纯计算密集型循环（如只做 i++、System.nanoTime()、位运算）：没方法调用、没分支跳转、没对象分配，JIT 优化后可能完全剔除安全点检查
- 深度内联后的嵌套循环：JIT 为性能省略部分安全点插入，尤其在热点方法中
怎么确认是安全点卡住，而不是 GC 真的慢？
不能只看 GC 日志里的 “pause time”，那只是总耗时。关键要看线程进入安全点的等待时间：
- 加启动参数：-XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1，观察日志中 “Time to wait for sigal” 是否持续超 100ms+
- JDK 8u212+ 可用：jstat -compiler
查看 failed_safepoint_count 是否持续增长 - jstack 输出某线程状态为 RUNNABLE，但堆栈为空或只显示 Unsafe.park / JVM_InvokeMethod 等底层帧，大概率正卡在无安全点区域
- 监控指标：GC 触发后，jstat -gc 显示 YGC/OldGC 的“GCT”时间突增，但 GC 前后堆内存变化不大，说明停顿主要花在等线程就位
修复方案：让循环主动“靠边停车”
核心思路是在线程执行流中插入轻量级安全点触发点，不打断逻辑，只提供暂停入口：
- Java 9+：循环体内加 Thread.onSpinWait()，语义明确、开销极低，专为此类场景设计
- 通用兼容写法：插入一次 LockSupport.parkNanos(1) 或 Thread.yield()，强制触发安全点轮询
- 隐式触发：调用一个空的 final 方法（如 Objects.requireNonNull(null, "")），利用方法调用前的安全点；或调用 System.nanoTime()（有副作用，慎用于高精度场景）
- 避免误用：-XX:+UseCountedLoopSafepoints 仅对 int 类型的 for 循环有效，对 while 和 long 循环无效，别依赖它救火
预防与上线前检查
高频轮询、自旋等待、状态机驱动逻辑最容易踩坑，建议形成开发规范：
- 所有 while(true) 或长周期轮询代码，必须显式包含至少一种安全点提示调用
- CI 流程中加入字节码扫描规则，检测连续 10 条以上无方法调用/分支指令的循环体（可用 ASM 或 Byte Buddy 实现）
- 压测阶段开启 -XX:+PrintSafepointStatistics，验证高峰期 failed_safepoint_count 为零或稳定低位
- 线上服务配置 -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation，结合 JIT 编译日志检查热点方法是否遗漏 safepoint 字段
