Safepoint 是线程主动抵达的安全停靠点，非强制中断点；它提供栈帧稳定、引用清晰的检查窗口，确保GC准确判断对象可达性与线程同步。
Safepoint 不是“停顿点”本身，而是线程主动抵达后才能被安全停下的位置。它不负责强制中断，而是提供一个状态确定、引用清晰的检查窗口——变量能否被回收、线程间如何同步，都依赖这个窗口是否被所有线程共同抵达。
变量回收为什么必须等 Safepoint
GC 要判断一个对象是否可回收，本质是检查它是否还被任何线程的栈帧或寄存器引用着。但 Java 线程在执行中，栈帧可能正在压入/弹出、寄存器内容随时变化，直接扫描会看到“撕裂”的中间态。Safepoint 保证：线程在此处的栈结构稳定、所有局部变量（包括对象引用）的位置和值完全可知。只有这时扫描到的“不可达”，才是真实可回收的。
- 比如一个方法刚 new 出对象，还没赋给局部变量，此时若强行暂停，该对象可能既不在栈顶也不在变量槽，容易漏判
- 而 Safepoint 通常设在方法返回前、循环末尾等位置，此时所有引用已落位，GC 可靠枚举
全局同步靠的是“集体抵达”，不是“统一命令”
JVM 发起 STW 操作（如 GC、偏向锁撤销）时，并不会立刻冻结所有线程。它只是设置一个全局标志（safepoint poll flag），然后等待每个线程自己运行到下一个 Safepoint 检查点并响应。这个过程天然存在延迟——哪个线程卡在长循环、本地方法或自旋里，就会拖慢整体同步。
- HotSpot 在编译热点代码时自动插入 poll 指令，常见位置：方法入口/出口、循环回边（loop back-edge）、非内联方法调用前
- 线程在解释执行时也通过字节码指令轮询；但 native 方法、IO 阻塞、长时间空循环等场景无法插入 poll，就成了“safepoint 抵达盲区”
- 可通过 -XX:+PrintGCApplicationStoppedTime 或 -XX:+PrintSafepointStatistics 查看各线程抵达耗时，定位卡点
理解变量生命周期与 Safepoint 的关系
局部变量的作用域结束 ≠ 引用立即失效。JIT 编译器可能延长其实际存活时间（如做寄存器优化），直到下一个 Safepoint 才真正“确认释放”。这意味着：即使代码里写了 obj = null，只要没到 Safepoint，GC 仍可能认为该引用有效。
- 变量是否“对 GC 可见”，取决于它在 Safepoint 快照中的状态，而非源码逻辑上的作用域边界
- 这也是为什么某些看似无用的对象，在 GC 日志里仍显示为“被栈引用”——它刚好卡在两个 Safepoint 之间，尚未被快照捕获为可回收
- 避免长循环中持有大对象引用，否则会推迟 Safepoint 抵达，间接延长对象存活周期
排查常见 Safepoint 延迟问题
停顿时间长，往往不是 GC 本身慢，而是线程迟迟不到 Safepoint。重点关注三类典型阻塞：
- 纯 Java 长循环：未开启 -XX:+UseCountedLoopSafepoints 时，循环体内部无 poll，需等循环退出才检查
- 本地方法调用：JNI 方法执行期间不检查 poll，特别是 File I/O、加密运算、数据库驱动等易阻塞场景
- 偏向锁竞争撤回：大量线程争抢同一把偏向锁时，JVM 需要所有线程到达 Safepoint 后批量撤销，形成隐式同步瓶颈
