安全点检查由JIT静态插入预设位置，与循环长度无关；仅在方法调用/返回、循环回边、异常抛出等固定语义边界插入轮询指令，空循环或纯计算循环可能被优化剔除安全点。
编译期不会在长循环中“隐式插入”安全点检查指令——这个说法本身存在误解。JVM 的安全点（Safepoint）检查不是由编译器根据“循环长度”或“运行时间”动态判断后插入的，而是严格依据预定义的、有限的几类代码结构，在编译（尤其是 JIT 编译）阶段**静态插入轮询指令（safepoint poll）**。
安全点插入位置是固定且有限的
HotSpot JVM 只在以下明确语义边界处插入 safepoint poll：
- 方法调用前、方法返回后
- 循环回边（loop back-edge），即 for/while 循环末尾的条件判断跳转处（如
i++ && i 判断后） - 异常抛出点、JNI 调用进出点
- 某些字节码指令的解释执行入口（解释器中通过 safept_table 分发表实现）
注意：这些位置与“循环是否很长”无关，只与控制流结构是否匹配 JIT 预设的轮询模板有关。一个空循环 while(true) { } 或纯计算循环 while(flag) { x = x * 2 + 1; }，若未包含方法调用、对象分配、锁操作或显式分支跳转，JIT 可能完全省略回边轮询，生成无 safepoint 的紧致机器码。
JIT 不会为“长耗时”主动加检查
JIT 编译器的设计目标是吞吐优先，不是可调试性。它不会分析循环体内部指令数、估算执行时间，再决定是否插 poll。相反：
- 若循环被识别为热点且满足优化条件（如无副作用、无调用），会被内联、展开甚至向量化，进一步减少或消除回边
- 一旦循环体中没有 JIT 认可的 safepoint 插入点，该线程在循环执行期间就无法响应 GC 请求或 jstack 采样
- 所谓“长循环卡住 STW”，本质是线程始终没走到下一个合法 safepoint，而非编译器“忘了插”
解释器和 JIT 的行为差异
解释执行时，每个字节码分发（dispatch）前都会检查 polling page，因此即使死循环也较容易进入 safepoint；但 JIT 编译后，执行的是原生指令，轮询仅存在于上述约定位置。这也是为什么 同一段代码在解释模式下可被挂起，而 JIT 后却“失联” 的根本原因。
如何让长循环可暂停？
若业务逻辑中存在必须长时间运行的循环，又需保障 JVM 可控性，应主动引入 JIT 可识别的 safepoint 触发点：
- 在循环体内加入空的
Thread.onSpinWait()（JDK9+，提示 JIT 保留轮询） - 插入无副作用的方法调用，如
Blackhole.consumeCPU(1)（JMH 工具类）或自定义空方法（需确保不被内联） - 定期执行轻量对象分配（如
new Object()），触发 GC 检查点（但代价较高） - 使用
System.nanoTime()等带 safepoint 语义的 JDK 方法（部分版本中其调用点含 poll）
这些做法不是“让编译器识别长循环”，而是**主动构造 JIT 认可的安全点锚点**。
