是的，threadlocal 仍为每个虚拟线程维护独立副本，但因虚拟线程数量庞大、生命周期短，频繁初始化 threadlocalmap 会导致 metaspace 溢出和 gc 压力激增；推荐优先使用 scopedvalue（java 21+）替代。
虚拟线程下 ThreadLocal 还是“每个线程一份副本”吗？
是的，语义没变——ThreadLocal 依然为每个线程（包括虚拟线程）维护独立副本。但关键差异在于：虚拟线程生命周期极短、数量可能达百万级，而传统 ThreadLocal 的内部实现（ThreadLocalMap）在频繁创建/销毁时会暴露明显开销。
常见错误现象：OutOfMemoryError: Metaspace 或 GC 压力陡增，不是因为内存泄漏本身，而是大量虚拟线程反复初始化 ThreadLocalMap 导致的临时对象爆炸。
-
ThreadLocal的set()第一次调用会触发ThreadLocalMap初始化，该 map 是弱引用 key + 强引用 value 的结构，但 map 实例本身是强引用挂在Thread对象上 - 虚拟线程（
VirtualThread）复用底层平台线程，但其Thread实例仍是完整对象，threadLocals字段照常分配 - 如果你在每个虚拟线程里都
new ThreadLocal()并set()，等于每毫秒都在 new 几百个ThreadLocalMap实例
怎么测出真实开销？别只看单次 get() 耗时
单次 ThreadLocal.get() 在虚拟线程下确实很快（纳秒级），但掩盖了更关键的成本：map 初始化、扩容、弱引用清理、GC 扫描压力。实测重点应放在高并发短生命周期场景。
推荐做法：
- 用
ForkJoinPool.commonPool()或Executors.newVirtualThreadPerTaskExecutor()启动 10w+ 虚拟线程，每个执行ThreadLocal.set()+ThreadLocal.get()+ 短计算 - 开启 JVM 参数：
-XX:+PrintGCDetails -XX:+UseG1GC -Xlog:gc+metaspace=debug，观察 metaspace 分配速率和 young GC 频次 - 用 JFR 录制，筛选事件：
jdk.ThreadStart、jdk.ThreadEnd、jdk.GCPhasePause，对比有无ThreadLocal的线程启动延迟分布
你会发现：无 ThreadLocal 时，10w 虚拟线程启动耗时约 80ms；加一个空 ThreadLocal 后升至 220ms —— 差异主要来自 map 初始化和哈希桶预分配。
替代方案：优先用方法参数或 ScopedValue（Java 21+）
ScopedValue 是 JDK 21 引入的、专为虚拟线程优化的轻量上下文传递机制，它不绑定到线程实例，而是通过栈帧传播，避免了 ThreadLocalMap 的所有开销。
适用场景：
- 需要跨方法传递请求 ID、租户 ID、认证上下文等只读值
- 值生命周期与当前执行栈一致（即不逃逸到异步回调或子线程）
- 你已升级到 Java 21 或更高版本
示例对比：
// ❌ 传统方式（虚拟线程下成本高）
static final ThreadLocal<string> requestId = ThreadLocal.withInitial(() -> UUID.randomUUID().toString());
// ✅ ScopedValue 方式（零 map 分配，GC 友好）
static final ScopedValue<string> REQUEST_ID = ScopedValue.newInstance();
...
ScopedValue.where(REQUEST_ID, "req-123", () -> {
// 所有嵌套调用可通过 REQUEST_ID.get() 获取
process();
});
</string></string>
注意：ScopedValue 不支持可变状态，也不能被子虚拟线程继承（除非显式调用 fork()），这点和 ThreadLocal 的“自动继承”不同。
如果必须用 ThreadLocal，怎么减负？
不是不能用，而是要规避高频初始化和泄露风险。核心原则：复用、静态、及时清理。
- 把
ThreadLocal声明为static final，避免每次 new 实例（否则每个实例都带独立 hash seed 和 map 初始化逻辑） - 避免在虚拟线程中调用
remove()——它只是清 value，map 结构还在；真正省资源的是让虚拟线程结束时 map 能被回收，这依赖于线程对象被 GC - 若需存储大对象（如缓存 buffer），改用
SoftReference包装 value，防止阻塞 GC - 不要在虚拟线程里做
ThreadLocal<list>.get().add(x)</list>这类操作——list 扩容会触发多次数组复制，放大开销
最易被忽略的一点：虚拟线程默认不执行 ThreadLocal 的 onExit 清理（Java 22+ 才引入实验性支持），所以依赖 remove() 的清理逻辑，在虚拟线程密集场景下大概率失效。
