安全点是jvm为保障gc等全局操作安全执行而预设的协作式停靠位置，线程需主动运行至该位置才能暂停；其通过主动式中断机制实现，常见于方法返回前、循环回边、方法调用及同步块退出等位置。
安全点（Safepoint）不是“断点”或调试用的暂停位置，而是 JVM 为保障全局操作（比如垃圾回收）能安全执行而预设的一组协作式停靠位置。线程只有运行到这些位置，状态才稳定可查——栈帧结构清晰、寄存器里的对象引用完整、GC Roots 可准确枚举。GC 不会强行打断线程，而是等所有线程自己走到最近的安全点并主动挂起。
安全点是“协作式暂停”，不是强制中断
JVM 启动 GC 前，先设置一个全局标志（如 SafepointRequested）。所有 Java 线程在执行过程中，会在特定位置检查这个标志： - 若已置位，且当前正好在安全点位置，就立即暂停，进入 STW（Stop-The-World）等待； - 若未到安全点，就继续执行，直到下一个检查点再判断。 这种机制叫“主动式中断”，现代 JVM 全部采用，避免了抢先式中断反复恢复/重中断的开销。
哪些位置会被标记为安全点？
JIT 编译器在热点代码中，选择语义明确、状态稳定的指令边界插入轮询逻辑（safepoint poll），常见位置包括： - 方法返回前（areturn、ireturn 等） - 循环末尾（尤其是 for 循环的回边，JIT 能识别计数逻辑） - 调用可能阻塞的方法前（如 Object.wait()、Thread.sleep()、LockSupport.park()） - 同步块退出时（synchronized 方法或代码块结束处） - 异常抛出后、方法入口等控制流关键节点
不同执行模式的线程如何响应安全点？
Java 线程并非都在跑 JIT 代码，JVM 根据执行状态区别处理： - 解释执行：解释器有一张字节码派发表；触发安全点时，VM 将其临时替换为“安全点专用表”，下一条字节码自动跳转至安全点处理逻辑 - JIT 编译代码：C1/C2 编译器在上述位置插入内存轮询指令（如读取 polling page），触发 SIGSEGV 后转入 VM 处理 - Native 线程（JNI）：不直接修改 Java 堆，被视为“天然安全”；但返回 Java 世界前必须检查，若 STW 仍在进行，就在 JNI 边界处挂起 - 阻塞/睡眠线程：已在安全状态（如 wait、sleep、锁竞争中），唤醒时再检查一次，确保不遗漏
为什么没有安全点会导致问题？
看一个典型场景： 一个纯计算的死循环，不调用任何方法、不进同步块、也不抛异常——JIT 可能在其中不插入任何 safepoint poll。这时即使 GC 触发，该线程也永远无法暂停，STW 一直卡住，整个应用假死。 这就是为什么写长循环时建议偶尔插入轻量操作（如 Thread.yield() 或空 synchronized 块），给 JVM 提供插入点；或者用 JFR 或 -XX:+PrintGCApplicationStoppedTime 观察 safepoint 停顿是否异常延长。
