线程切换开销大不仅因栈指针跳转，还涉及寄存器保存/恢复、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），可把串行等待转为异步流水线，降低线程挂起概率。
- 不要在
CompletableFuture的回调里执行阻塞操作（如Thread.sleep()、JDBC 查询），否则会卡住ForkJoinPool.commonPool() - IO 密集型任务建议指定自定义
Executor（如Executors.newCachedThreadPool()），避免污染计算型线程池 -
ForkJoinPool默认并行度是Runtime.getRuntime().availableProcessors() - 1，超线程核心不额外加分，勿盲目调大
慎用 synchronized 和 ReentrantLock，优先考虑无锁或乐观策略
锁竞争是上下文切换最常见诱因之一。一个线程持锁，其余线程要么自旋消耗 CPU，要么挂起让出 CPU——后者直接触发调度器介入。
立即学习“Java免费学习笔记（深入）”；
- 读多写少场景优先用
StampedLock的乐观读（tryOptimisticRead），失败再降级为悲观读锁，避免读线程互相阻塞 - 计数类操作用
LongAdder替代AtomicLong，它通过分段热点缓解 CAS 冲突，减少自旋重试次数 - 避免在锁块内做耗时操作（如网络调用、日志序列化），把锁粒度缩到最小必要范围
- 注意
synchronized的锁膨胀过程：从无锁 → 偏向锁 → 轻量级锁 → 重量级锁，一旦升级为重量级，就会进入操作系统互斥量，必然触发线程挂起
真正影响上下文切换频率的，往往不是线程数量本身，而是线程间交互的模式：锁怎么用、状态怎么传、任务怎么切分。很多“优化线程数”的调优，本质是在掩盖设计上的同步滥用或阻塞误用。
