JVM STW延迟主因是线程停入安全点的协调过程，而非安全点扫描本身；长循环无安全点、JNI阻塞、OS调度延迟、OopMap构建及偏向锁撤销风暴均显著拉长停顿时间。
当 JVM 需要进入 STW（Stop-The-World）阶段时，全局安全点（Safepoint）扫描本身不是耗时主因，真正拖慢的是「让所有线程停到安全点」这一协调过程——尤其在线程数达数万量级时，瓶颈不在于扫描，而在于等待、同步与状态确认。
线程挂起等待是最大延迟来源
JVM 不会主动“扫描”每个线程是否就位，而是通过轮询机制通知线程自行检查 safepoint 标志位。但以下情况会让线程迟迟无法响应：
- 长循环未插入安全点检查：如纯计算型循环（无方法调用、无异常检查、无锁操作），JIT 编译后可能完全省略 safepoint 轮询，导致该线程必须跑完整个循环才能响应，单线程延迟可达数百毫秒甚至秒级；
-
JNI 临界区阻塞：处于 JNI 函数中且未显式调用
Interruptible或未退出临界区的线程，无法在任意位置停顿，必须等其返回 Java 层； - 操作系统级调度延迟：内核调度器未及时唤醒被挂起线程（尤其在 CPU 负载高、cgroup 限频或容器资源受限时），造成“已发信号，但未响应”的假性卡顿。
栈帧遍历与 OopMap 构建开销显著上升
一旦线程停在安全点，JVM 需对其 Java 栈逐帧解析，定位所有对象引用（OopMap）。线程越多、栈越深，这部分开销越明显：
- 每个活跃线程平均栈深度若为 200 帧，数万线程即需处理超 200 万帧；
- OopMap 并非静态缓存，部分 JIT 编译代码会在运行时动态生成或更新，频繁 recompile 会触发额外 OopMap 重建；
- 若存在大量虚拟线程（Virtual Thread），其栈驻留在堆中且需按调度域隔离回收，OopMap 构建还需跨域索引，进一步增加元数据查找成本。
偏向锁撤销成为隐性放大器
在高并发读写场景（如 HBase、Kafka Broker），若开启偏向锁（默认 JDK8~15），数万个线程频繁竞争同一组热点对象，会批量触发偏向锁撤销：
- 每次撤销需挂起持有线程并检查其栈中 Lock Record，本质是一次微型 STW；
- 日志中常表现为
RevokeBias [threads: N]，vmop 耗时可能高达 10–50ms，远超普通 GC 初始标记； - 数万线程下，撤销请求排队+线程状态判断+对象头重写，极易形成“撤销风暴”，把原本微秒级的 safepoint 进入时间拉长至百毫秒级。
安全点统计与定位建议
真实瓶颈不能靠猜测，需用参数实测：
- 加
-XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1，关注spin（轮询等待）、block（OS 级阻塞）、vmop（实际 VM 操作）三段耗时； - 若
spin占比高 → 检查长循环和 JNI； - 若
vmop显著高于 GC 相关操作 → 关注偏向锁撤销、类重定义、JIT 去优化等非 GC 类 VM Operation； - 配合
-XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput可捕获更细粒度的线程停顿归因。
