虚拟线程通过jvm用户态调度、动态栈伸缩与自动挂起机制，将上下文切换降至纳秒级，解决传统线程因os内核切换（3–5微秒）和1mb栈占用导致的高开销与资源浪费问题。
Java 19 起引入的虚拟线程（Virtual Threads），不是协程，但解决了传统线程最痛的上下文切换开销问题——它不靠避免切换，而是让切换本身变得极轻。
为什么传统线程上下文切换那么贵
操作系统每次切换平台线程，都要保存寄存器、更新页表、刷新 TLB、调度队列重排。实测平均耗时 3–5 微秒。看似微小，但在每秒处理 10 万请求、每个请求触发 3 次阻塞调用（如 DB 查询 + HTTP 调用 + 日志刷盘）的场景下，光是线程切换就可能吃掉数毫秒 CPU 时间，成为吞吐瓶颈。
更关键的是：这些线程多数时间在等待 I/O，却仍独占一个 OS 线程和约 1MB 栈空间，资源严重浪费。
虚拟线程怎么把“切换成本”打下来
虚拟线程不依赖 OS 调度，由 JVM 在用户态统一管理。它的“切换”本质是栈帧的挂起与恢复，发生在 JVM 内部，无需陷入内核：
- 栈空间动态伸缩，初始仅几 KB，百万级并发也不爆内存
- 阻塞操作（如 Thread.sleep()、FileInputStream.read()、JDBC 查询）触发自动挂起，立刻释放底层载体线程（Carrier Thread）
- JVM 将成千上万个虚拟线程复用到少量平台线程（默认 ForkJoinPool.commonPool）上执行，大幅减少真实 OS 线程数量
- 调度决策由 JVM 完成，绕过内核调度器，避免 TLB 刷新和上下文寄存器压栈等开销
它和协程的区别在哪
协程（如 Kotlin 的 suspend 函数）靠编译器重写为状态机，在单一线程内协作式调度；虚拟线程是抢占式、透明的，开发者完全不用改写逻辑。
关键差异在于挂起粒度与控制权：
- 协程只能在 suspend 函数边界挂起，需全链路适配协程 API
- 虚拟线程可在任意阻塞点（包括第三方库的 Object.wait()、LockSupport.park()）自动挂起，对旧代码零侵入
- 协程上下文（CoroutineContext）可携带结构化信息；虚拟线程无原生上下文传递机制，跨载体线程时易丢失 MDC、事务绑定等
什么时候该用，什么时候不该用
虚拟线程不是万能加速器，适用性取决于任务特征：
- 适合：HTTP 请求处理、REST API 编排、数据库连接池交互、文件批量读写——共性是 I/O 阻塞多、CPU 计算少、请求独立
- 不适合：图像渲染、加密解密、科学计算等长时 CPU 密集型任务——会抢占载体线程，拖慢其他虚拟线程
- 慎用：持有锁时间过长、调用未适配 Loom 的本地 JNI 库、或依赖 ThreadLocal 存储不可序列化对象（挂起恢复后可能失效）
不复杂但容易忽略：它不改变并发模型的本质，只是把“一个请求一个线程”的高开销做法，变成了可行且高效的默认选择。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
