尧图网页设计 
JEP491中synchronized关键字引发的平台线程钉住解决方法简介前言synchronized关键字引发的平台线程钉住解决方法一、 根因剖析为什么 JDK 21 中 synchronized 会导致 Pinning1. 锁记录Lock Record绑定 Native Stack2. ObjectMonitor::_owner 强绑定 JavaThread*3. 阻塞原语强绑定 OS 线程ParkEvent::park二、 JDK 23/24 JEP 491 核心重构方案概览三、 C 源码级深度剖析1. ObjectMonitor 所有权编码重构 (objectMonitor.hpp)2. 抢锁与 Yield 路径 (ObjectMonitor::enter)3. 锁释放与 Unpark 调度路径 (ObjectMonitor::exit)4. Object.wait() 与 notify() 条件队列改造四、 轻量级锁重构Thread-Local Lock Stack 机制核心设计JavaThread::_lock_stack五、 HotSpot 栈冻结Continuation::freeze的拦截解除六、 演进前后对比与工程价值1. 技术架构演进对比2. 生产工程价值前言本文旨在记录近期研读Java源码的学习心得与疑难问题。由于个人理解水平有限文中内容难免存在疏漏恳请读者不吝指正。synchronized关键字引发的平台线程钉住解决方法在 JDK 21 中Project Loom 带来虚拟线程Virtual Thread时synchronized关键字导致的Pinning线程钉住是最主要的性能隐患——只要虚拟线程在synchronized块或方法内部触发了阻塞操作如网络 I/O、LockSupport.park()、Object.wait()底层的 Carrier 平台线程就会被硬性锁定并随之阻塞无法被释放去调度其他虚拟线程。为了彻底解决这一痛点OpenJDK 团队在JDK 23 中推出了 JEP 491 (Synchronized With Virtual Threads)并在JDK 24中进一步完善。这项重构对 HotSpot 运行时的ObjectMonitor、锁膨胀机制Lock Inflation、轻量级锁Lightweight Locking以及Continuation栈冻结Freeze逻辑进行了深度的 C 源码级改造。以下是对这一重构方案的底层技术实现剖析。一、 根因剖析为什么 JDK 21 中synchronized会导致 Pinning在 JDK 21 及更早的 HotSpot 实现中synchronized锁的实现深度依赖于Carrier 线程的 Native Stack以及特定平台线程绑定的 C 数据结构1. 锁记录Lock Record绑定 Native Stack在无膨胀的轻量级锁Fast Path阶段JVM 会在当前线程的 Native Stack 栈帧中分配一个BasicObjectLock/BasicLock锁记录。当虚拟线程执行Continuation::freeze栈帧冻结时这些位于 Native Stack 上的物理指针在拷贝到堆内的stackChunkOop后会发生地址偏移。传统的轻量级锁依赖栈帧指针RBP/RSP 相对位置进行锁重入计数与解锁一旦解除挂载Unmount并在另一个 Carrier 线程上解冻ThawNative Stack 地址发生变化锁记录指针直接失效。2.ObjectMonitor::_owner强绑定JavaThread*当锁膨胀为重量级锁Slow Path时C 类ObjectMonitor的_owner字段直接存放持有锁的Thread*或JavaThread*指针即底层 OS Carrier 线程的 C 对象指针。ObjectMonitor无法感知当前持有锁的是一个逻辑上的VirtualThread还是物理上的JavaThread。若_owner记录的是 Carrier 线程一旦虚拟线程 Unmount其他 Carrier 线程尝试抢锁时物理_owner指针的语义就会发生混乱。3. 阻塞原语强绑定 OS 线程ParkEvent::park在ObjectMonitor::enter()或Object.wait()争抢锁失败时传统 HotSpot 会调用Thread::current()-_ParkEvent-park()直接触发操作系统级别的阻塞如 Linux 的sys_futex或pthread_cond_wait。这直接冻结了底层的 Carrier OS 线程使其无法退回ForkJoinPool。【JDK 21 阻塞路径导致 Pinning】 VirtualThread - synchronized - ObjectMonitor::enter() | (争抢失败) v ObjectWaiter::park() | v PlatformEvent::park() - Linux sys_futex() (Carrier OS 线程被硬性挂起)二、 JDK 23/24 JEP 491 核心重构方案概览JEP 491 的核心思想是**将ObjectMonitor的所有权、阻塞队列与底层的物理 OS 线程彻底解耦使其能够识别VirtualThread对象并将 OS 级的线程阻塞替换为用户态的Continuation::yield()**。【JDK 23/24 重构后的阻塞路径无 Pinning】 VirtualThread - synchronized - ObjectMonitor::enter() | (争抢失败) v 判断当前 Thread 为 VirtualThread | v 入队 _cxq / _EntryList (挂载 ObjectWaiter 节点) | v VirtualThread.park() - Continuation::yield() (Unmount 卸载) | Carrier 线程释放返回 ForkJoinPool 调度其他任务架构上的四大关键改变_owner字段编码重构能够区分JavaThread*、VirtualThread oop以及匿名锁状态。ObjectWaiter与队列重构等待队列_cxq/_EntryList/_WaitSet支持保存虚拟线程句柄。阻塞/唤醒机制路由抢锁失败时 platform 线程走PlatformEvent::park()virtual 线程走VirtualThread.park()(即Continuation::yield())。轻量级锁脱离 Native Stack全面引入并完善Thread-Local Lock Stack线程本地锁栈机制。三、 C 源码级深度剖析1.ObjectMonitor所有权编码重构 (objectMonitor.hpp)在 JDK 23/24 的 HotSpot 源码中ObjectMonitor内部的_owner字段不再是一个单纯的void*或Thread*而是采用了Tagged Pointer / 多态编码// src/hotspot/share/runtime/objectMonitor.hpp (JDK 23/24)classObjectMonitor{// ...// _owner 现在可以存储// 1. nullptr : 无锁状态// 2. JavaThread* : 平台线程持有锁// 3. oop (VirtualThread 的 Java 对象) : 虚拟线程持有锁// 4. ANONYMOUS_OWNER : 轻量级锁设置的匿名持有标记// 5. DEFLATED_MARKER : 监视器消退标记std::atomicintptr_t_owner;// 辅助 API提取与判断真实持有者inlineboolis_owner_anonymous()const;inlineboolhas_owner()const;inlinevoid*owner()const;inlineoopowner_oop()const;// 若持有者为 VirtualThread返回其 oop (Object OOP)};通过这一改造HotSpot 能够精准知道“究竟是哪个虚拟线程持有该锁”。即使虚拟线程发生了 Unmount_owner中保存的虚拟线程oop在堆内依然合法且能被 GC 屏障正确追踪与更新。2. 抢锁与 Yield 路径 (ObjectMonitor::enter)在src/hotspot/share/runtime/objectMonitor.cpp中当线程试图获取膨胀锁失败时enter方法的分支逻辑发生了根本改变// HotSpot 源码伪代码逻辑 (JDK 23/24 演进)voidObjectMonitor::enter(TRAPS){JavaThread*currentJavaThread::current();// 1. 尝试 CAS 抢锁if(try_enter(current)){return;// 抢锁成功}// 2. 抢锁失败构造等待节点ObjectWaiternode(current);// 判断当前线程是否在运行 VirtualThreadVThread*vthreadcurrent-vthread_object();if(vthread!nullptr){node._is_virtualtrue;node._vthread_oopvthread;// 绑定虚拟线程的 oop}// 3. 将 node 原子入队到 _cxq (Contention Queue)AddWaiterToQueue(node);// 4. 阻塞等待循环for(;;){if(try_lock_or_steal()){break;// 被唤醒后成功抢到锁}if(node._is_virtual){// JEP 491 核心突破点 // 虚拟线程路径不调用 OS 原生 park而是触发 JVM 用户态 park// 这将在底层引发 Continuation::yield()将当前栈帧 Freeze 到堆内并 Unmountcurrent-vthread_park();}else{// 平台线程路径保留原有的 OS 级 ParkEventcurrent-_ParkEvent-park();}}// 5. 抢锁成功出队并恢复状态UnlinkWaiterFromQueue(node);}3. 锁释放与 Unpark 调度路径 (ObjectMonitor::exit)当锁持有者无论是平台线程还是虚拟线程退出synchronized块并调用ObjectMonitor::exit()时它需要唤醒_EntryList或_cxq中的下一个等待节点// src/hotspot/share/runtime/objectMonitor.cppvoidObjectMonitor::exit(boolc2_set_owner,TRAPS){// ... 清理 _owner 标识 ...// 获取队列中的下一个 Waiter 节点ObjectWaiter*wdequeue_next_waiter();if(wnullptr)return;if(w-_is_virtual){// JEP 491 虚拟线程唤醒 // 提取等待节点中保存的 VirtualThread oopoop vthread_oopw-_vthread_oop;// 调用 Java 层的 LockSupport.unpark(vthread) 逻辑// 将该 VirtualThread 重新提交给 ForkJoinPool 任务队列等待 Carrier 调度JavaThread::unpark_virtual_thread(vthread_oop);}else{// 平台线程唤醒直接触发 PlatformEvent 信号w-_event-unpark();}}4.Object.wait()与notify()条件队列改造Object.wait()传统上会导致 OS 线程在_WaitSet队列对应的ParkEvent上挂起。JEP 491 重新整合了WaitSet机制wait()过程虚拟线程将自身作为ObjectWaiter插入_WaitSet释放ObjectMonitor的所有权随后触发Continuation::yield()进行 Unmount。notify()/notifyAll()过程通知者将ObjectWaiter从_WaitSet移至_EntryList或_cxq。重新抢锁被notify的虚拟线程唤醒后重新进入ObjectMonitor::enter()的竞争逻辑。整个过程 Carrier 线程零阻塞。四、 轻量级锁重构Thread-Local Lock Stack 机制除重量级锁ObjectMonitor外HotSpot 在 JDK 21 引入并在 JDK 23 中完善了Lightweight LockingJEP 428/458 演进彻底弃用了依靠 Native Stack 记录锁地址的BasicObjectLock链表。核心设计JavaThread::_lock_stackHotSpot 在JavaThreadC 对象中直接置入了一个固定大小的指针数组LockStack锁栈classJavaThread:publicThread{private:// Thread-Local Lock Stack (JDK 21 引入JDK 23 重构)LockStack _lock_stack;};Native Stack (无 Lock Record 强绑定) JavaThread (C 对象) ------------------------------- ----------------------- | Frame N (c2_compiled) | | _lock_stack (Array) | | - 压栈/弹栈仅触发汇编指令 | | [0] - oop (Object A)| | 更新 JavaThread 锁栈 | ---------- | [1] - oop (Object B)| | Frame N-1 | | [2] - nullptr | ------------------------------- -----------------------锁对象直接入栈当执行轻量级加锁Fast Path时JVM 仅仅是将加锁对象的oop内存地址推入当前线程的_lock_stack数组中并在对象的 Mark Word 中设置轻量级锁标记。剥离 Native Stack 依赖锁状态不再依赖 Native Stack 上某个BasicLock变量的物理内存地址RSP/RBP 偏移。支持栈帧 Freeze/Thaw在虚拟线程 Unmount 时HotSpot 只需把_lock_stack中的对象引用暂存至虚拟线程对应的堆内存数据结构中Mount 时再复原至 Carrier 的_lock_stack即可。这使得轻量级锁在 Fast Path 下同样能够无缝切出。五、 HotSpot 栈冻结Continuation::freeze的拦截解除在 JDK 21 中Continuation::freeze在执行栈漫游Stack Walking之前会检查当前线程是否持有 Monitor 锁或处于synchronized方法内部。如果检查到直接抛出Pinning异常或终止 Unmount。在 JDK 23/24 JEP 491 的实现中Continuation::freeze的检查逻辑被大幅放宽// src/hotspot/share/runtime/continuationFreezeThaw.cpp (JDK 23/24 逻辑演进)FreezeResultContinuation::is_pinned(JavaThread*thread){// JDK 21 原有逻辑// if (thread-has_monitors() || thread-is_in_synchronized_segment()) {// return PINNED_MONITOR; // 强制 Pinning// }// JDK 23/24 JEP 491 逻辑// 移除了对 ObjectMonitor 的硬性 Pinning 检查// 仅在以下极端不可避免的场景保留 Pinningif(thread-has_native_frames()){returnPINNED_NATIVE_FRAME;// 包含 JNI / Native C 代码栈帧}returnUNPINNED;// 允许 Freeze/Unmount}六、 演进前后对比与工程价值1. 技术架构演进对比维度JDK 21 (旧实现)JDK 23 / 24 (JEP 491 重构实现)synchronized与 Unmount强制 Pinning。 Carrier 线程随之物理阻塞。完全解耦。允许虚拟线程切出Unmount。ObjectMonitor::_owner含义仅存储物理JavaThread*指针。多态 Tagged Pointer支持VirtualThread oop。争抢失败阻塞机制调用PlatformEvent::park()(Linuxsys_futex)。路由至VirtualThread.park()(Continuation::yield())。轻量级锁实现绑定 Native Stack 帧上的BasicObjectLock。基于JavaThread::_lock_stack(Thread-Local 锁栈)。唤醒机制OS 级pthread_cond_signal/futex唤醒。触发LockSupport.unpark(vthread)交由ForkJoinPool调度。2. 生产工程价值零成本迁移存量代码以往为了适配虚拟线程企业不得不使用ReentrantLock大面积重构遗留代码库如 Spring 早期版本、MySQL JDBC 驱动、旧版 HttpClient。在 JDK 23/24 中传统的synchronized恢复为其原有的“第一公民”并发原语地位性能与ReentrantLock看齐。彻底解决 Carrier 线程枯竭Exhaustion在百万级并发微服务场景下不再需要设置-Djdk.virtualThreadScheduler.maxPoolSize来防止 Carrier 线程被synchronized耗尽。监视器诊断与 JFR 统一synchronized的监视器事件与 JFR (jdk.JavaMonitorEnter) 无缝融合能够精准呈现 VirtualThread 的真实等待时长而不会误报 Carrier 线程停顿。 JEP491中synchronized关键字引发的平台线程钉住解决方法简介
JEP491中synchronized关键字引发的平台线程钉住解决方法简介前言synchronized关键字引发的平台线程钉住解决方法一、 根因剖析为什么 JDK 21 中 synchronized 会导致 Pinning1. 锁记录Lock Record绑定 Native Stack2. ObjectMonitor::_owner 强绑定 JavaThread*3. 阻塞原语强绑定 OS 线程ParkEvent::park二、 JDK 23/24 JEP 491 核心重构方案概览三、 C 源码级深度剖析1. ObjectMonitor 所有权编码重构 (objectMonitor.hpp)2. 抢锁与 Yield 路径 (ObjectMonitor::enter)3. 锁释放与 Unpark 调度路径 (ObjectMonitor::exit)4. Object.wait() 与 notify() 条件队列改造四、 轻量级锁重构Thread-Local Lock Stack 机制核心设计JavaThread::_lock_stack五、 HotSpot 栈冻结Continuation::freeze的拦截解除六、 演进前后对比与工程价值1. 技术架构演进对比2. 生产工程价值前言本文旨在记录近期研读Java源码的学习心得与疑难问题。由于个人理解水平有限文中内容难免存在疏漏恳请读者不吝指正。synchronized关键字引发的平台线程钉住解决方法在 JDK 21 中Project Loom 带来虚拟线程Virtual Thread时synchronized关键字导致的Pinning线程钉住是最主要的性能隐患——只要虚拟线程在synchronized块或方法内部触发了阻塞操作如网络 I/O、LockSupport.park()、Object.wait()底层的 Carrier 平台线程就会被硬性锁定并随之阻塞无法被释放去调度其他虚拟线程。为了彻底解决这一痛点OpenJDK 团队在JDK 23 中推出了 JEP 491 (Synchronized With Virtual Threads)并在JDK 24中进一步完善。这项重构对 HotSpot 运行时的ObjectMonitor、锁膨胀机制Lock Inflation、轻量级锁Lightweight Locking以及Continuation栈冻结Freeze逻辑进行了深度的 C 源码级改造。以下是对这一重构方案的底层技术实现剖析。一、 根因剖析为什么 JDK 21 中synchronized会导致 Pinning在 JDK 21 及更早的 HotSpot 实现中synchronized锁的实现深度依赖于Carrier 线程的 Native Stack以及特定平台线程绑定的 C 数据结构1. 锁记录Lock Record绑定 Native Stack在无膨胀的轻量级锁Fast Path阶段JVM 会在当前线程的 Native Stack 栈帧中分配一个BasicObjectLock/BasicLock锁记录。当虚拟线程执行Continuation::freeze栈帧冻结时这些位于 Native Stack 上的物理指针在拷贝到堆内的stackChunkOop后会发生地址偏移。传统的轻量级锁依赖栈帧指针RBP/RSP 相对位置进行锁重入计数与解锁一旦解除挂载Unmount并在另一个 Carrier 线程上解冻ThawNative Stack 地址发生变化锁记录指针直接失效。2.ObjectMonitor::_owner强绑定JavaThread*当锁膨胀为重量级锁Slow Path时C 类ObjectMonitor的_owner字段直接存放持有锁的Thread*或JavaThread*指针即底层 OS Carrier 线程的 C 对象指针。ObjectMonitor无法感知当前持有锁的是一个逻辑上的VirtualThread还是物理上的JavaThread。若_owner记录的是 Carrier 线程一旦虚拟线程 Unmount其他 Carrier 线程尝试抢锁时物理_owner指针的语义就会发生混乱。3. 阻塞原语强绑定 OS 线程ParkEvent::park在ObjectMonitor::enter()或Object.wait()争抢锁失败时传统 HotSpot 会调用Thread::current()-_ParkEvent-park()直接触发操作系统级别的阻塞如 Linux 的sys_futex或pthread_cond_wait。这直接冻结了底层的 Carrier OS 线程使其无法退回ForkJoinPool。【JDK 21 阻塞路径导致 Pinning】 VirtualThread - synchronized - ObjectMonitor::enter() | (争抢失败) v ObjectWaiter::park() | v PlatformEvent::park() - Linux sys_futex() (Carrier OS 线程被硬性挂起)二、 JDK 23/24 JEP 491 核心重构方案概览JEP 491 的核心思想是**将ObjectMonitor的所有权、阻塞队列与底层的物理 OS 线程彻底解耦使其能够识别VirtualThread对象并将 OS 级的线程阻塞替换为用户态的Continuation::yield()**。【JDK 23/24 重构后的阻塞路径无 Pinning】 VirtualThread - synchronized - ObjectMonitor::enter() | (争抢失败) v 判断当前 Thread 为 VirtualThread | v 入队 _cxq / _EntryList (挂载 ObjectWaiter 节点) | v VirtualThread.park() - Continuation::yield() (Unmount 卸载) | Carrier 线程释放返回 ForkJoinPool 调度其他任务架构上的四大关键改变_owner字段编码重构能够区分JavaThread*、VirtualThread oop以及匿名锁状态。ObjectWaiter与队列重构等待队列_cxq/_EntryList/_WaitSet支持保存虚拟线程句柄。阻塞/唤醒机制路由抢锁失败时 platform 线程走PlatformEvent::park()virtual 线程走VirtualThread.park()(即Continuation::yield())。轻量级锁脱离 Native Stack全面引入并完善Thread-Local Lock Stack线程本地锁栈机制。三、 C 源码级深度剖析1.ObjectMonitor所有权编码重构 (objectMonitor.hpp)在 JDK 23/24 的 HotSpot 源码中ObjectMonitor内部的_owner字段不再是一个单纯的void*或Thread*而是采用了Tagged Pointer / 多态编码// src/hotspot/share/runtime/objectMonitor.hpp (JDK 23/24)classObjectMonitor{// ...// _owner 现在可以存储// 1. nullptr : 无锁状态// 2. JavaThread* : 平台线程持有锁// 3. oop (VirtualThread 的 Java 对象) : 虚拟线程持有锁// 4. ANONYMOUS_OWNER : 轻量级锁设置的匿名持有标记// 5. DEFLATED_MARKER : 监视器消退标记std::atomicintptr_t_owner;// 辅助 API提取与判断真实持有者inlineboolis_owner_anonymous()const;inlineboolhas_owner()const;inlinevoid*owner()const;inlineoopowner_oop()const;// 若持有者为 VirtualThread返回其 oop (Object OOP)};通过这一改造HotSpot 能够精准知道“究竟是哪个虚拟线程持有该锁”。即使虚拟线程发生了 Unmount_owner中保存的虚拟线程oop在堆内依然合法且能被 GC 屏障正确追踪与更新。2. 抢锁与 Yield 路径 (ObjectMonitor::enter)在src/hotspot/share/runtime/objectMonitor.cpp中当线程试图获取膨胀锁失败时enter方法的分支逻辑发生了根本改变// HotSpot 源码伪代码逻辑 (JDK 23/24 演进)voidObjectMonitor::enter(TRAPS){JavaThread*currentJavaThread::current();// 1. 尝试 CAS 抢锁if(try_enter(current)){return;// 抢锁成功}// 2. 抢锁失败构造等待节点ObjectWaiternode(current);// 判断当前线程是否在运行 VirtualThreadVThread*vthreadcurrent-vthread_object();if(vthread!nullptr){node._is_virtualtrue;node._vthread_oopvthread;// 绑定虚拟线程的 oop}// 3. 将 node 原子入队到 _cxq (Contention Queue)AddWaiterToQueue(node);// 4. 阻塞等待循环for(;;){if(try_lock_or_steal()){break;// 被唤醒后成功抢到锁}if(node._is_virtual){// JEP 491 核心突破点 // 虚拟线程路径不调用 OS 原生 park而是触发 JVM 用户态 park// 这将在底层引发 Continuation::yield()将当前栈帧 Freeze 到堆内并 Unmountcurrent-vthread_park();}else{// 平台线程路径保留原有的 OS 级 ParkEventcurrent-_ParkEvent-park();}}// 5. 抢锁成功出队并恢复状态UnlinkWaiterFromQueue(node);}3. 锁释放与 Unpark 调度路径 (ObjectMonitor::exit)当锁持有者无论是平台线程还是虚拟线程退出synchronized块并调用ObjectMonitor::exit()时它需要唤醒_EntryList或_cxq中的下一个等待节点// src/hotspot/share/runtime/objectMonitor.cppvoidObjectMonitor::exit(boolc2_set_owner,TRAPS){// ... 清理 _owner 标识 ...// 获取队列中的下一个 Waiter 节点ObjectWaiter*wdequeue_next_waiter();if(wnullptr)return;if(w-_is_virtual){// JEP 491 虚拟线程唤醒 // 提取等待节点中保存的 VirtualThread oopoop vthread_oopw-_vthread_oop;// 调用 Java 层的 LockSupport.unpark(vthread) 逻辑// 将该 VirtualThread 重新提交给 ForkJoinPool 任务队列等待 Carrier 调度JavaThread::unpark_virtual_thread(vthread_oop);}else{// 平台线程唤醒直接触发 PlatformEvent 信号w-_event-unpark();}}4.Object.wait()与notify()条件队列改造Object.wait()传统上会导致 OS 线程在_WaitSet队列对应的ParkEvent上挂起。JEP 491 重新整合了WaitSet机制wait()过程虚拟线程将自身作为ObjectWaiter插入_WaitSet释放ObjectMonitor的所有权随后触发Continuation::yield()进行 Unmount。notify()/notifyAll()过程通知者将ObjectWaiter从_WaitSet移至_EntryList或_cxq。重新抢锁被notify的虚拟线程唤醒后重新进入ObjectMonitor::enter()的竞争逻辑。整个过程 Carrier 线程零阻塞。四、 轻量级锁重构Thread-Local Lock Stack 机制除重量级锁ObjectMonitor外HotSpot 在 JDK 21 引入并在 JDK 23 中完善了Lightweight LockingJEP 428/458 演进彻底弃用了依靠 Native Stack 记录锁地址的BasicObjectLock链表。核心设计JavaThread::_lock_stackHotSpot 在JavaThreadC 对象中直接置入了一个固定大小的指针数组LockStack锁栈classJavaThread:publicThread{private:// Thread-Local Lock Stack (JDK 21 引入JDK 23 重构)LockStack _lock_stack;};Native Stack (无 Lock Record 强绑定) JavaThread (C 对象) ------------------------------- ----------------------- | Frame N (c2_compiled) | | _lock_stack (Array) | | - 压栈/弹栈仅触发汇编指令 | | [0] - oop (Object A)| | 更新 JavaThread 锁栈 | ---------- | [1] - oop (Object B)| | Frame N-1 | | [2] - nullptr | ------------------------------- -----------------------锁对象直接入栈当执行轻量级加锁Fast Path时JVM 仅仅是将加锁对象的oop内存地址推入当前线程的_lock_stack数组中并在对象的 Mark Word 中设置轻量级锁标记。剥离 Native Stack 依赖锁状态不再依赖 Native Stack 上某个BasicLock变量的物理内存地址RSP/RBP 偏移。支持栈帧 Freeze/Thaw在虚拟线程 Unmount 时HotSpot 只需把_lock_stack中的对象引用暂存至虚拟线程对应的堆内存数据结构中Mount 时再复原至 Carrier 的_lock_stack即可。这使得轻量级锁在 Fast Path 下同样能够无缝切出。五、 HotSpot 栈冻结Continuation::freeze的拦截解除在 JDK 21 中Continuation::freeze在执行栈漫游Stack Walking之前会检查当前线程是否持有 Monitor 锁或处于synchronized方法内部。如果检查到直接抛出Pinning异常或终止 Unmount。在 JDK 23/24 JEP 491 的实现中Continuation::freeze的检查逻辑被大幅放宽// src/hotspot/share/runtime/continuationFreezeThaw.cpp (JDK 23/24 逻辑演进)FreezeResultContinuation::is_pinned(JavaThread*thread){// JDK 21 原有逻辑// if (thread-has_monitors() || thread-is_in_synchronized_segment()) {// return PINNED_MONITOR; // 强制 Pinning// }// JDK 23/24 JEP 491 逻辑// 移除了对 ObjectMonitor 的硬性 Pinning 检查// 仅在以下极端不可避免的场景保留 Pinningif(thread-has_native_frames()){returnPINNED_NATIVE_FRAME;// 包含 JNI / Native C 代码栈帧}returnUNPINNED;// 允许 Freeze/Unmount}六、 演进前后对比与工程价值1. 技术架构演进对比维度JDK 21 (旧实现)JDK 23 / 24 (JEP 491 重构实现)synchronized与 Unmount强制 Pinning。 Carrier 线程随之物理阻塞。完全解耦。允许虚拟线程切出Unmount。ObjectMonitor::_owner含义仅存储物理JavaThread*指针。多态 Tagged Pointer支持VirtualThread oop。争抢失败阻塞机制调用PlatformEvent::park()(Linuxsys_futex)。路由至VirtualThread.park()(Continuation::yield())。轻量级锁实现绑定 Native Stack 帧上的BasicObjectLock。基于JavaThread::_lock_stack(Thread-Local 锁栈)。唤醒机制OS 级pthread_cond_signal/futex唤醒。触发LockSupport.unpark(vthread)交由ForkJoinPool调度。2. 生产工程价值零成本迁移存量代码以往为了适配虚拟线程企业不得不使用ReentrantLock大面积重构遗留代码库如 Spring 早期版本、MySQL JDBC 驱动、旧版 HttpClient。在 JDK 23/24 中传统的synchronized恢复为其原有的“第一公民”并发原语地位性能与ReentrantLock看齐。彻底解决 Carrier 线程枯竭Exhaustion在百万级并发微服务场景下不再需要设置-Djdk.virtualThreadScheduler.maxPoolSize来防止 Carrier 线程被synchronized耗尽。监视器诊断与 JFR 统一synchronized的监视器事件与 JFR (jdk.JavaMonitorEnter) 无缝融合能够精准呈现 VirtualThread 的真实等待时长而不会误报 Carrier 线程停顿。