安全点是GC停顿得以安全发生的必要条件，决定STW起始时机；线程需主动运行至安全点才响应GC请求，卡在无安全点长循环中会延长STW时间；安全区域则覆盖JNI、阻塞等场景，避免GC无限等待。
安全点直接影响垃圾回收停顿的起始时机和实际时长，但它本身不是停顿原因，而是停顿得以安全发生的必要条件。
安全点决定 GC 何时能真正开始
GC 线程发出 STW 请求后，并不会立刻冻结所有线程。它只是设置一个全局标志，然后等待每个 Java 线程自己运行到下一个安全点并主动检查该标志。只有当最后一条线程抵达安全点，JVM 才算完成“线程收敛”，GC 的标记、清理等核心阶段才能启动。
- 如果某条线程卡在无安全点的长循环里（如
while (true) { i++; }），其余线程都已就位，GC 也只能干等——这期间计入 STW 时间，但实际 GC 还没开始 - 日志中 “GC pause” 时间 = 等待线程就绪时间 + 真实 GC 工作时间。前者常被误认为是 GC 效率问题，实则是安全点抵达延迟
- 可通过
-XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1查看 “Time to wait for safepoint” 字段，定位拖慢者
安全点位置影响对象可达性判断准确性
GC Roots 枚举依赖线程栈上引用的精确快照，而这个快照只在安全点处有效。线程未到安全点时，局部变量可能还在寄存器中、栈帧可能正在构造或销毁，引用关系处于中间态。
- 例如：方法刚 new 出对象，还没赋给局部变量，此时强制暂停，GC 可能完全看不到该引用，导致误回收
- 安全点通常设在方法返回前、循环末尾等位置，确保所有引用已落位、栈帧稳定，GC 扫描结果才可靠
- 这也解释了为什么
obj = null写了之后对象未必立即可回收——JIT 可能延长其存活，直到下一个安全点才被快照捕获为“不可达”
安全区域补充覆盖非 Java 执行场景
当线程进入 JNI 调用、I/O 阻塞、Thread.sleep() 等状态时，它已脱离 JVM 控制，无法响应安全点轮询。这时安全区域机制启用：
- 线程一进入阻塞态，JVM 就将其标记为“已在安全区域”，GC 不再等待它，直接开始
- 线程唤醒后，必须先到达下一个安全点才能继续执行 Java 代码——这一步完成状态同步与校验
- 没有安全区域，GC 可能无限期等待一个卡在
read()系统调用里的线程，STW 时间彻底失控
常见拖慢安全点抵达的代码模式
这些写法会让线程长时间不触发安全点检查，成为 GC 停顿的瓶颈：
-
for (long i = 0; i < Integer.MAX_VALUE; i++) { /* 纯计算，无方法调用 */ }—— JIT 可能省略回边安全点 - 密集使用
Unsafe.copyMemory()或VarHandle.setOpaque()—— 绕过 JVM 控制，需手动插入Thread.yield() - 深度内联的热点方法中嵌套多层循环 —— JIT 编译优化可能减少安全点插入频率
- 解决办法：在循环体内加入轻量调用，如
Thread.onSpinWait()（Java 9+）或System.nanoTime()，触发隐式轮询
