Project Loom虚拟线程非LockSupport.park()场景的停车机制问询

一、除LockSupport.park()外的虚拟线程停车实现 #

虚拟线程的停车本质是暂停执行栈、从平台线程解绑，让平台线程可调度其他任务。除LockSupport.park()外，核心实现分为两类场景：

1. I/O操作场景的非阻塞停车 #

Loom通过改造JDK核心I/O类（如SocketInputStream、FileChannel等）实现虚拟线程的无阻塞等待：

• 当虚拟线程发起阻塞I/O调用时，JDK会将请求注册到操作系统的异步多路复用器（如epoll、kqueue），随后主动触发虚拟线程的续体切换，暂停当前虚拟线程并释放平台线程。
• 当I/O操作完成时，多路复用器通知JDK调度器，将对应的虚拟线程重新挂载到平台线程恢复执行。整个过程对开发者完全透明，无需修改业务代码。

2. continuation yield intrinsic的作用场景 #

你提到的continuation yield intrinsic是HotSpot为虚拟线程定制的底层指令，并非通用性能优化工具：

• 它的核心作用是高效触发虚拟线程的栈切换：当虚拟线程需要暂停（如I/O等待、同步等待）时，JDK会调用该intrinsic，直接与虚拟机底层交互，快速保存当前虚拟线程的执行栈状态，完成与平台线程的解绑。
• 相比普通方法调用，这个intrinsic避免了额外的调用开销，是保证虚拟线程切换高性能的底层支撑。

二、ObjectMonitor在虚拟线程环境下的适配逻辑 #

ObjectMonitor作为synchronized和Object.wait()/notify()的底层实现，原本依赖pthread的mutex和cond，但在虚拟线程环境下做了针对性适配：

• JDK会判断当前线程类型：如果是平台线程，沿用原有的pthread mutex/cond机制；如果是虚拟线程，则将等待逻辑转移到虚拟线程专属的等待队列，不会阻塞平台线程。
• 当等待条件满足（如调用Object.notify()）时，调度器会将对应的虚拟线程重新调度到平台线程上执行，实现“虚拟线程等待不占用平台线程资源”的效果。ObjectMonitor的pthread底层逻辑并未移除，仅针对虚拟线程做了路径分支适配。

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