为何ReentrantLock比synchronized更适配Java虚拟线程？

为什么Lock优于synchronized？ #

核心差异在于两者阻塞时的JVM调度行为：

• synchronized会触发线程固定：synchronized依赖JVM底层的Monitor机制实现同步。当持有synchronized锁的虚拟线程进入阻塞状态（比如调用Object.wait()、Thread.sleep()，或者等待其他synchronized锁），JVM无法将这个虚拟线程从当前绑定的平台线程（OS线程）上卸载。平台线程会被该虚拟线程一直占用，直到锁被释放——这直接抵消了虚拟线程"用少量平台线程承载大量任务"的核心优势，造成资源浪费。
• Lock的阻塞支持虚拟线程卸载：java.util.concurrent.locks包下的Lock实现，其阻塞逻辑基于LockSupport.park()/LockSupport.unpark()。JVM针对虚拟线程的park操作做了专属优化：当虚拟线程调用park()阻塞时，JVM会将它从当前平台线程上剥离，平台线程可以立即去执行其他虚拟线程；当阻塞条件解除（比如获取到锁、被unpark），虚拟线程会被重新调度到任意可用的平台线程上继续执行，不会占用平台线程的空闲资源。

ReentrantLock会不会引发线程固定问题？ #

不会，原因如下：

• ReentrantLock的同步逻辑完全基于Java层面的AQS（抽象队列同步器）实现，重入计数通过AQS的state变量维护，不依赖底层Monitor。
• 它的阻塞、等待逻辑同样使用LockSupport.park()，符合JVM对虚拟线程的调度规则。即使持有ReentrantLock的虚拟线程进入阻塞状态，JVM依然可以正常将其从平台线程上卸载，不会出现线程固定的情况。

补充：Java后续版本可能会优化synchronized的线程固定问题，但截至Java 22，Lock仍是虚拟线程场景下更高效的同步选择。

内容的提问来源于stack exchange，提问作者gstackoverflow