虚拟线程通过用户态轻量调度绕开os线程创建与阻塞机制：不调用clone()、不分配1mb栈、不注册内核调度器，卸载耗时仅几十纳秒，50万并发可在8gb堆内存中实现。
虚拟线程不是“优化”传统线程，而是绕开了 start() 背后那一整套昂贵的物理线程生命周期——它压根不走操作系统创建线程那条路。
虚拟线程的 start() 不触发系统调用
传统 Thread.start() 会立即向内核发起 clone() 系统调用，分配栈内存（默认1MB）、注册调度实体、初始化TLS、陷入内核态完成上下文准备，单次耗时约1.2ms。而虚拟线程的 start()（或 startVirtualThread()、ofVirtual().start()）全程在 JVM 用户态完成：
- 不申请 OS 栈，只在堆上分配一个轻量
VirtualThread对象，初始栈仅几百字节 - 不注册内核调度器，也不绑定 CPU 核心，只是把任务加入 JVM 内部的虚拟线程队列
- 真正执行时，由空闲的载体线程（Carrier Thread，数量≈CPU核心数）从队列中取出并挂载运行
阻塞不再等于“占坑”，卸载比挂起快两个数量级
传统线程遇到 Thread.sleep()、Socket.read() 或锁竞争时，OS 直接将其置为 TASK_INTERRUPTIBLE 状态，整个内核线程挂起，资源锁定不动。虚拟线程则不同：
- JVM 在检测到可中断阻塞点（如
sleep、NIO 阻塞通道、synchronized等）时，自动将当前虚拟线程从载体线程上卸载（unmount） - 卸载动作是纯 Java 层对象状态切换，耗时约几十纳秒，远低于 OS 线程挂起的 1~10 微秒
- 卸载后载体线程立刻从队列拉取下一个就绪虚拟线程继续执行，无空转、无等待
百万并发不再是理论数字，而是堆内存能撑住就行
平台线程的并发上限由 OS 限制和内存硬约束决定：16GB 内存 ≈ 1.5 万个线程。虚拟线程把“并发数”从操作系统维度转移到 JVM 堆维度：
- 每个虚拟线程初始仅占堆中几KB，栈随方法调用深度动态增长，返回时自动收缩
- 栈帧存储在普通 Java 对象中，可被 GC 回收；没有线程局部存储（TLS）膨胀问题
- 实测在 8GB 堆的容器中轻松启动 50 万虚拟线程处理 HTTP 请求，而同等配置下平台线程池超过 2000 就开始 OOM 或调度失灵
API 兼容但语义重定义：start() = 提交任务，不是抢占资源
你仍写 new Thread(runnable).start()，但 JDK 21+ 中若使用虚拟线程工厂，语义已彻底改变：
-
Thread.ofVirtual().start(runnable)：声明“这是一个可卸载、可复用、按需调度的逻辑执行单元” -
Thread.startVirtualThread(runnable)：等价于向 ForkJoinPool 的虚拟线程专用队列投递任务 -
Executors.newVirtualThreadPerTaskExecutor()：每次submit()都新建虚拟线程，但底层复用极少数载体线程，无资源泄漏风险
