虚拟线程是jvm在os线程之上实现的轻量级调度优化，仍遵循完整线程语义，而协程是用户态执行流控制，两者抽象层级、设计目标与适用场景均不同，不可互换或类比。
虚拟线程不是协程
Java 的 VirtualThread 和 Kotlin/Python/Rust 里的协程（coroutine）根本不是一个抽象层级的东西。虚拟线程是 JVM 在 OS 线程之上做的调度优化，它仍遵循完整线程语义：有栈、可中断、能被 Thread.currentThread() 拿到、支持 synchronized 和 Object.wait()；而协程是用户态的执行流控制，不绑定 OS 资源，没有真实线程 ID，靠挂起/恢复实现非阻塞——两者解决的问题不同，不能互换或类比。
虚拟线程本质是“自动托管的平台线程”
它背后仍是 PlatformThread（即传统 OS 线程），但由 JVM 自动复用和调度。你调用 Thread.ofVirtual().start()，JVM 不立刻申请 OS 线程，而是把任务提交给一个共享的 ForkJoinPool，等真正执行 I/O 或计算时才绑定到某个空闲平台线程上。
常见错误现象：Thread.sleep(1000) 在虚拟线程里不会阻塞平台线程，但 Thread.currentThread().isVirtual() 返回 true，而 Thread.currentThread().getThreadGroup() 会抛 UnsupportedOperationException——这是有意设计，因为虚拟线程不属于任何传统线程组。
- 不要试图给虚拟线程设置优先级：
setPriority()无效，会静默忽略 - 避免在虚拟线程中调用
Thread.stop()、Thread.suspend()等已废弃方法，它们对虚拟线程无意义 - 调试时注意：IDE 断点停在虚拟线程里，堆栈可能显示为
ForkJoinWorkerThread，不是你启动时写的类名
协程需要语言/库层配合，虚拟线程是 JVM 原生能力
Java 没有语法级协程支持，yield、suspend、resume 这类关键字不存在；所有“挂起”行为都依赖阻塞式 API（如 InputStream.read()）被 JVM 自动检测并让出底层平台线程。而 Kotlin 协程靠编译器重写函数为状态机，再配合 Continuation 接口手动控制流转。
立即学习“Java免费学习笔记（深入）”；
使用场景差异明显：
- 高并发 HTTP 请求（每请求一虚拟线程）→ 适合
VirtualThread，代码几乎不用改老式阻塞风格 - 复杂状态流转、需细粒度暂停/恢复逻辑（比如游戏帧循环、DSL 解析器）→ 必须用协程模型，虚拟线程做不到
- 想跨语言协作（如 Java 服务调用 Kotlin 协程封装的 SDK）→ 注意调用边界：虚拟线程进入协程后，就脱离 JVM 调度控制了
性能拐点和隐蔽开销
虚拟线程快，但不是免费的。当并发数极低（比如
容易踩的坑：
- 在虚拟线程里做长时间 CPU 密集计算（如大数组排序），会独占平台线程，拖慢其他虚拟线程——应显式用
ForkJoinPool.commonPool().submit()或专用计算线程池 - 虚拟线程默认栈大小约 1KB，远小于平台线程（通常 1MB）。递归过深或局部变量过多会直接
StackOverflowError -
ThreadLocal在虚拟线程中默认不继承，若需传递上下文（如 traceId），必须用InheritableThreadLocal或改用ScopedValue（Java 21+）
最常被忽略的一点：虚拟线程的生命周期完全由 JVM 控制，你无法像协程那样主动 launch { ... }.cancel()。一旦启动，只能等它自然结束或被中断——而中断是否生效，取决于它当前是否处于可中断的阻塞点。
