虚拟线程上下文切换仅纳秒级，因不陷入内核，只在JVM用户态栈帧间跳转；千万级并发不爆内存靠按需分配、可回收栈及极简对象（~300字节），但CPU密集型任务反致性能下降。
协程上下文切换成本到底有多低？
Java 虚拟线程（Virtual Thread）的“上下文切换”本质上不走 OS 级调度，所以没有传统线程那种寄存器保存/恢复、TLB 刷新、cache line 污染等开销。它只是在 Java 栈帧之间跳转，类似 Thread.yield() 或 LockSupport.park() 后的栈挂起/恢复，耗时通常在纳秒级。
关键点在于：这不是“省了切换”，而是“压根没切到内核”。虚拟线程阻塞时，背后承载它的平台线程（Platform Thread）会去跑别的虚拟线程——调度逻辑在 JVM 用户态完成。
- 真实开销主要来自：JVM 内部的栈快照（如挂起时记录
StackFrame）、GC 对栈根的扫描（但虚拟线程栈小，影响极小） - 对比：OS 线程切换平均 1–10 微秒；虚拟线程让出控制权约 50–200 纳秒
- 注意：如果代码里频繁调用
Thread.sleep(1)或短超时CountDownLatch.await(1, TimeUnit.MILLISECONDS)，反而会因反复挂起/唤醒放大 JVM 调度开销，得不偿失
千万级并发不爆内存的关键在哪？
不是虚拟线程“轻量”，而是 JVM 对它们做了三件事：栈空间按需分配、栈内存可回收、线程对象本身极简。
默认情况下，每个虚拟线程只分配约 256KB 栈空间（可调，见 -XX:MaxVirtualThreadStackSize），且这个栈是堆内分配的（ByteBuffer.allocateDirect() 或堆上字节数组），不受 -Xss 限制；更重要的是：一旦虚拟线程结束，它的整个栈内存立即被 GC 回收，不像 OS 线程栈要等线程彻底退出才释放。
立即学习“Java免费学习笔记（深入）”；
- 一个活跃的虚拟线程对象本身只占 ~300 字节（不含栈），而 OS 线程对象在 JVM 里也要几百字节 + 内核侧 KB 级资源
- 常见误判：以为“开了 100 万虚拟线程就占 100 万 × 256KB”，其实绝大多数时间它们处于
WAITING或TERMINATED状态，栈已释放或尚未分配 - 风险点：
ThreadLocal在虚拟线程中仍有效，但若绑定大对象（如缓存Map），会导致内存泄漏——因为虚拟线程退出后ThreadLocal不自动清理，必须手动remove()
什么时候虚拟线程反而更慢？
不是所有场景都适合。当任务是 CPU 密集型、无阻塞、持续占用平台线程时，虚拟线程不仅没收益，还会因调度器额外判断和栈管理带来负优化。
- 典型反模式：用
Executors.newVirtualThreadPerTaskExecutor()跑纯计算循环（如for (int i = 0; i ） - 平台线程数不足也会拖慢：默认最多使用
ForkJoinPool.commonPool().getParallelism()个平台线程（通常是 CPU 核数），若大量虚拟线程同时执行 CPU 工作，会排队等待平台线程，吞吐反而下降 - IO 驱动的场景才真正受益：数据库查询、HTTP 调用、文件读写——这些操作会让虚拟线程主动挂起，把平台线程腾出来干别的事
怎么确认你的虚拟线程真在“轻量运行”？
别只看线程数。用 JDK 自带工具查两个指标：jstack 看状态分布，jstat 看栈内存实际占用。
-
jstack <pid> | grep "virtual"应该看到大量java.lang.VirtualThread$VThreadContinuation.run()和状态为WAITING (parking)的条目，而不是全卡在RUNNABLE -
jstat -gc <pid>中关注EU（Eden 使用量）和OU（老年代使用量）是否随虚拟线程数量线性增长——正常情况应该基本平稳，暴涨说明栈或ThreadLocal泄漏 - 别依赖
Thread.activeCount()：它只统计活着的Thread实例，而虚拟线程退出后对象可能还被引用（比如被ThreadLocal持有），得靠 MAT 或 jfr 分析堆快照
ThreadLocal 不乱绑——这些地方一松懈，千万并发就变成千万个内存黑洞。 
