虚拟线程调用read()、sleep()等白名单阻塞方法时，JVM在字节码层面直接介入挂起：保存栈帧、释放载体线程、标记为WAITING并移出队列；非白名单操作（如native方法、CPU循环）无法触发挂起。
虚拟线程遇到 read()、sleep() 为什么会自动挂起？
因为 JVM 在字节码层面做了增强：只要虚拟线程调用已知的阻塞方法（如 InputStream.read()、Thread.sleep()、Object.wait()、LockSupport.park()），JVM 就会立即捕获该调用点，触发 Continuation 的挂起流程——保存当前栈帧、释放正在运行它的载体线程（carrier thread），然后把该虚拟线程标记为“WAITING”并移出执行队列。
这不是靠 try-catch 或 AOP 实现的，是 JVM 运行时直接介入。你写的是普通阻塞调用，但背后被悄悄转换成了协作式让出。
哪些操作能触发挂起？哪些不能？
能触发挂起的，是 JVM 白名单里的“可挂起阻塞点”。常见包括：
-
Thread.sleep()、Thread.yield() -
Object.wait()、LockSupport.park()及其变体 - 所有标准 I/O（
FileInputStream.read()、SocketInputStream.read()） - Java NIO 的阻塞模式调用（如
FileChannel.read()在阻塞通道上）
不能触发挂起的典型情况：
- 自定义 native 方法（JVM 不知道它是否阻塞）
- 未被 Loom 支持的第三方库阻塞调用（比如老版本 Netty 的某些阻塞封装）
- CPU 密集循环（
while(true) { i++; }）——它不阻塞，也不让出，会霸占 carrier thread - 同步块内长时间持有锁（
synchronized本身不挂起，除非里面调用了可挂起点）
为什么 Executors.newVirtualThreadPerTaskExecutor() 是推荐入口？
它内部封装了调度器生命周期管理，避免你手动处理虚拟线程的启动/异常/关闭问题。更重要的是：它默认使用 ForkJoinPool.commonPool() 作为 carrier thread 池，而这个池支持 Loom 调度器所需的钩子（如 ManagedBlocker 兼容性）。
如果你手写 Thread.ofVirtual().start()，也能挂起，但一旦任务抛异常没捕获，虚拟线程就静默死亡，且 carrier thread 可能因未正确清理状态而轻微抖动。
实操建议：
- 批量任务首选
newVirtualThreadPerTaskExecutor()，尤其配合try-with-resources - 单次简单任务可用
Thread.ofVirtual().start(Runnable)，但记得加try/catch - 千万别用
new Thread()包一层虚拟线程——那只是平台线程套壳，完全失去挂起能力
调试时看不到挂起过程？那是你没开对日志
虚拟线程挂起/恢复是纯 JVM 用户态行为，不会出现在 jstack 的 OS 线程栈里，传统线程分析工具（如 VisualVM 默认视图）会显示所有虚拟线程都跑在 ForkJoinPool-worker-X 上，堆栈还可能被截断或合并。
要确认挂起是否生效，得开 JVM 参数：
-
-Djdk.tracePinnedThread=full：当虚拟线程因调用非挂起点而“钉住”（pinned）carrier thread 时，打印警告 -
-XX:+UnlockDiagnosticVMOptions -XX:+PrintVMQWaitEvents：输出挂起/唤醒事件（JDK 21+） - 用 JFR（Java Flight Recorder）录制，筛选
jdk.VirtualThreadPinned和jdk.VirtualThreadSubmit事件
最容易被忽略的一点：挂起不是“线程暂停”，而是 JVM 主动解绑 + 调度器重分配。它不依赖操作系统信号或调度器抢占，所以没有传统线程切换的毫秒级延迟——但这也意味着，你无法用 Thread.interrupt() 中断一个正在挂起过程中的虚拟线程，中断只对“运行中”或“WAITING”状态有效。
