偏向锁撤销必然触发STW，因需在安全点暂停所有线程以原子修改堆中对象头和各线程栈帧中的锁记录；JDK15+默认禁用，因其撤销开销远超轻量级锁自旋收益。

锁记录在虚拟机栈帧中不是“存放在某个固定地址”，而是由 JVM 在线程执行同步块前，动态在当前栈帧的局部变量表或操作数栈上方分配的一段连续内存空间（通常紧邻栈帧底部），结构包含 displaced_header（备份原对象头 Mark Word）和 owner 指针（指向该锁记录本身）。它属于线程私有、生命周期与栈帧绑定——方法退出即自动失效，不涉及堆内存管理。

为什么这个排布会加剧偏向锁撤销的高并发冲突

偏向锁撤销必须同时修改两处：堆中对象头的 Mark Word（共享），以及所有可能持有该锁的线程栈帧里的锁记录（私有）。而栈帧中的锁记录没有统一索引或全局视图，JVM 无法按需定位——只能靠安全点机制强制所有线程停步，逐个扫描其栈帧，查找是否含对应锁记录。

• 高并发下线程数多，每个线程栈帧结构不同，扫描耗时呈线性增长
• 栈帧深度大（如嵌套调用、大量局部变量）时，锁记录位置浮动，解析开销上升
• 虚拟线程（Project Loom）进一步放大问题：一个平台线程承载数百虚拟线程，每个都可能有自己的栈帧和锁记录，但安全点仍需暂停整个平台线程——等效于一次 STW 拖住全部虚拟线程

撤销过程暴露的物理约束

撤销不是“改一个字段”，而是一次跨内存域的原子协调：

• 对象头在堆中，受 GC 线程、其他 Java 线程共同访问，修改需保证可见性与一致性
• 锁记录在栈中，只对该线程可见，且随方法返回自动销毁；若线程正执行 native 方法或 JIT 编译中，栈帧可能被优化掉（如锁消除后未生成记录），导致状态不一致
• JVM 必须等所有线程到达安全点，才能确保：栈帧完整、锁记录未被复用、对象头未被并发修改——这本身就是对执行流的强干预

实际可观测的表现

当大量同类型对象频繁触发偏向锁撤销（例如批量达 40 次后类级撤销），你会看到：

• jstack 中大量线程卡在 VM Thread 等待状态，而非用户代码
• GC 日志出现 Safepoint sync time 显著升高（>5ms），但无 Full GC
• CPU 使用率平稳甚至偏低，而请求 P99 延迟突增——典型 STW 阻塞特征
• perf 或 async-profiler 抓取到大量 safepoint_poll 和 thread_local_handshake 调用栈