Thread.sleep(1000)卡住5秒的主因并非sleep本身，而是JVM需先完成Safepoint进入；若线程正运行JIT优化掉Safepoint的长循环（如for(long i=0; i
Thread.sleep 本身不触发 SafePoint 等待，但它的调用位置决定了线程能否及时响应 JVM 的 Safepoint 请求；真正拖慢 STW 的，往往是它前面那段“没 safepoint”的长循环。
为什么 Thread.sleep(1000) 会卡住 5 秒？
现象不是 sleep 慢，而是 JVM 在执行 Thread.sleep 前必须先完成一次 Safepoint 进入——如果当前线程正卡在一个 JIT 优化掉 Safepoint 的长循环里（比如 for (long i = 0; i ），它就只能干等线程自己“走到下一个安全点”。
- JIT 编译器对计数循环（counted loop）默认移除 Safepoint poll，因为认为它“短”且“可预测”，但实际运行几秒甚至几十秒时，就成了 STW 瓶颈
-
Thread.sleep是一个 Java 方法调用，调用前会插入 Safepoint 检查；但检查只发生在方法入口，不解决调用前那段纯计算的阻塞 - 典型错误日志：
Time to wait for sigal: 4823ms（来自-XX:+PrintSafepointStatistics），说明线程花了近 5 秒才从循环里出来
int 循环和 long 循环在 Safepoint 插入上的差异
JIT 对循环变量类型的判断直接影响 Safepoint 是否保留：用 int 写的计数循环（如 for (int i = 0; i ）通常仍保有 Safepoint；而 <code>long 类型、大范围、无分支的循环极易被优化剔除。
-
int循环：JIT 可能推断出迭代次数有限（即使很大），保留 poll 检查 -
long循环：尤其当上限是常量（如5_000_000_000L），JIT 认为“不会溢出、无需检查”，直接删掉 Safepoint - 验证方式：加
-XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly（需 hsdis），看汇编里有没有safepoint_poll指令
如何手动插入 Safepoint？不是加 sleep，而是加 poll
别用 Thread.sleep(0) 或 Thread.yield() —— 它们开销大、语义不符，且不一定触发 poll。正确做法是插入一个轻量、无副作用、能强制 JIT 保留 Safepoint 的调用。
- Java 9+ 推荐：
Thread.onSpinWait()，专为此设计，零开销，明确告诉 JIT “这里可能要等” - 兼容低版本：
System.nanoTime()或Class.forName("java.lang.Object")，利用方法调用触发隐式 Safepoint poll - 避免写成
if (i % 1000 == 0) Thread.onSpinWait();—— 条件分支本身可能被 JIT 优化掉，应确保每次迭代都执行 - 示例修复：
for (long i = 0; i < 5_000_000_000L; i++) {
sum += i;
Thread.onSpinWait(); // ✅ 显式插入，JIT 不敢删
}
诊断时最容易忽略的 SafePoint 场景
SafePoint 等待不仅出现在 GC，也出现在 jstack、jmap、JFR.start、甚至 Thread.getAllStackTraces() 这类诊断操作中——它们都要求所有线程进入 Safepoint 才能获取一致栈帧。
- 线上加监控脚本时，如果定时跑
jmap -histo，而业务线程恰好在跑长计算循环，就会导致整个 JVM 卡住数秒 -
-XX:GuaranteedSafepointInterval=1000可强制每秒轮询一次，缓解问题，但不能替代代码修复 - 关键信号：GC 日志显示停顿仅
0.012s，但应用 P99 延迟飙升到800ms以上，基本就是 Safepoint 等待在背锅
真正难的不是加一行 onSpinWait()，而是意识到“这段看起来最安全的纯计算代码”，恰恰是最容易让 JVM 失控的隐患点。
