线程切换开销大不仅因栈指针跳转，还涉及寄存器保存/恢复、TLB刷新、缓存失效、内外核态切换及页表遍历；频繁切换显著降低高并发短任务吞吐量。

为什么线程切换开销大，而不是“只是换个栈”

线程切换不是简单跳转到另一个 Thread 的栈指针，它涉及 CPU 寄存器保存/恢复、TLB 刷新、缓存行失效、内核态与用户态切换（尤其在阻塞 I/O 或锁竞争时），甚至可能触发页表遍历。频繁切换会显著拉低吞吐量，尤其在高并发短任务场景下，Thread.yield() 或 synchronized 争抢都可能成为隐形瓶颈。

用 ThreadLocal 避免跨线程共享状态的锁竞争

当多个线程反复读写同一份上下文数据（如用户 ID、事务 ID、格式化器），容易因同步引发切换。用 ThreadLocal 把状态绑定到线程自身，消除共享和锁，自然减少因等待锁导致的调度让出。

• ThreadLocal 不是万能缓存，需主动调用 remove() 防止在线程池中内存泄漏（尤其 ExecutorService 复用线程时）
• 避免在 ThreadLocal 中存大对象或未关闭资源（如 Connection、InputStream）
• 若必须传递上下文（如父子线程），优先用 InheritableThreadLocal 或显式透传，而非全局静态变量加锁

用 ForkJoinPool + CompletableFuture 替代传统 new Thread() 或固定大小线程池

普通 ThreadPoolExecutor 在任务粒度细、依赖多时，容易因队列排队、线程空闲/过载不均导致无效切换。ForkJoinPool 的工作窃取机制让空闲线程主动拉取其他线程队列里的任务，保持 CPU 饱和且减少阻塞等待；配合 CompletableFuture 的非阻塞组合（thenApply、thenCompose），可把串行等待转为异步流水线，降低线程挂起概率。

JavaScript 测试模式

使用 Jest、Vitest 和 Testing Library 实施全面的测试策略，包括单元测试、集成测试和端到端测试，涵盖模拟、测试夹具和测试驱动开发。在编

下载

• 不要在 CompletableFuture 的回调里执行阻塞操作（如 Thread.sleep()、JDBC 查询），否则会卡住 ForkJoinPool.commonPool()
• IO 密集型任务建议指定自定义 Executor（如 Executors.newCachedThreadPool()），避免污染计算型线程池
• ForkJoinPool 默认并行度是 Runtime.getRuntime().availableProcessors() - 1，超线程核心不额外加分，勿盲目调大

慎用 synchronized 和 ReentrantLock，优先考虑无锁或乐观策略

锁竞争是上下文切换最常见诱因之一。一个线程持锁，其余线程要么自旋消耗 CPU，要么挂起让出 CPU——后者直接触发调度器介入。

• 读多写少场景优先用 StampedLock 的乐观读（tryOptimisticRead），失败再降级为悲观读锁，避免读线程互相阻塞
• 计数类操作用 LongAdder 替代 AtomicLong，它通过分段热点缓解 CAS 冲突，减少自旋重试次数
• 避免在锁块内做耗时操作（如网络调用、日志序列化），把锁粒度缩到最小必要范围
• 注意 synchronized 的锁膨胀过程：从无锁 → 偏向锁 → 轻量级锁 → 重量级锁，一旦升级为重量级，就会进入操作系统互斥量，必然触发线程挂起

真正影响上下文切换频率的，往往不是线程数量本身，而是线程间交互的模式：锁怎么用、状态怎么传、任务怎么切分。很多“优化线程数”的调优，本质是在掩盖设计上的同步滥用或阻塞误用。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南