safepoint 是 jvm 暂停线程执行全局操作（如 gc）前必须等待所有线程到达的安全检查点；线程仅在 jit 插入的 safepoint poll 位置（如方法返回、循环末尾）主动检查并暂停，而非任意指令处中断。
什么是 Safepoint：JVM 暂停线程的“红绿灯”
安全点不是代码里的某个函数或配置项，而是 JVM 设计的一个执行时机约定：只有当所有 Java 线程都到达某个 safepoint，JVM 才能安全地暂停它们执行 GC、类卸载、JIT 退优化等全局操作。它不是随时可停，而是“等你走到路口再拦车”。
线程不会在任意指令处被中断——比如正在执行 System.arraycopy 或热点循环中的原生指令时，JVM 无法直接插手；必须等它主动检查是否该进 safepoint。这个检查叫 safepoint poll，由 JIT 编译器在合适位置（如方法返回前、循环回边）插入。
哪些代码会触发 safepoint 检查
不是所有 Java 字节码都会生成 safepoint poll。JIT 编译后，以下场景大概率有：
- 方法返回（
areturn/ireturn等） - 循环末尾（特别是带计数的
for，JIT 会识别并插入） - 调用可能阻塞的方法（如
Object.wait()、Thread.sleep()） - 显式同步块退出（
synchronized方法/块结束）
但要注意：while(true) { /* 空循环 */ } 或纯计算型 long 循环（没方法调用、没内存访问），JIT 可能完全不插 safepoint poll，导致线程长时间卡住，拖慢整个 GC 停顿——这就是典型的 Thread.stop() 已废弃、safepoint 又没机会触发的危险组合。
如何观察 safepoint 延迟和停顿
加 JVM 参数才能看到真实行为：
-
-XX:+PrintGCApplicationStoppedTime：打印每次应用线程被停多久（单位 ms） -
-XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1：输出每次 safepoint 的详细耗时，包括“进入等待时间”（即哪个线程迟迟不来） -
-XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile=jvm.log配合上面，把日志导出分析
常见错误现象：Application time: 0.0001234 seconds 后紧跟着 Total time for which application threads were stopped: 123.456789 seconds——说明某线程卡在非 safepoint 区域，其他线程干等它，实际 GC 工作只占几毫秒，但总停顿被拖到百毫秒级。
为什么 String::intern 和 Thread::onSpinWait 会影响 safepoint
String::intern 在字符串常量池竞争激烈时，可能触发锁争用 + 长时间 native 调用，而 native 方法默认不设 safepoint poll，线程就“隐身”了；Thread::onSpinWait 是 JDK9+ 提供的提示，告诉 JVM “我正在自旋等待，别插 poll”，但它本身不保证安全——如果用在不该用的地方（比如替代锁等待），反而会让线程跳过检查点。
性能影响很直接：一个没 poll 的长循环，会让所有 GC 停顿被迫等待它；兼容性上，不同 JDK 版本对循环识别策略不同（比如 JDK8 对简单 while 循环更保守，JDK17 更激进插 poll），所以同一段代码在不同版本里 safepoint 行为可能差异很大。
复杂点在于：safepoint 不是开关，而是编译器、运行时、硬件三者共同协商的结果；容易被忽略的是——哪怕你没写死循环，JNI 调用、GraalVM native image、甚至某些 CPU 指令重排，都可能让 poll 失效或延迟。真要压测，得看 PrintSafepointStatistics 输出里那个 “time to wait for threads” 列，而不是只盯着 GC 日志里的停顿时间。
