上下文切换是CPU在多线程间保存并恢复线程状态的开销操作，由操作系统执行；常见触发场景包括sleep、wait、锁竞争、IO阻塞及频繁创建线程；线程数过多反而降低性能，因缓存失效、时间片过短和内存压力增大；ThreadLocal不减少切换次数，误用还易致内存泄漏；根本优化在于减少切换，如控制线程数、使用异步IO、避免阻塞。
上下文切换就是CPU在两个线程之间“换人干活”时的保存+恢复动作
它不是Java独有的概念，而是操作系统层面的动作：当CPU从Thread-1切到Thread-2时，必须把Thread-1当前的程序计数器、寄存器值、栈指针等状态写进内存；再把Thread-2之前存好的状态读回来，才能接着执行。这个过程本身不跑业务逻辑，纯属“搬家耗时”。
哪些代码会悄悄触发上下文切换？
你写的每一行看似“轻量”的调用，都可能让线程被踢出CPU——尤其是以下场景：
-
Thread.sleep(1)：哪怕只睡1毫秒，线程立刻让出CPU，几乎必然触发切换 -
Object.wait()或LockSupport.park()：线程进入阻塞态，OS马上调度其他线程 -
synchronized块内发生竞争：抢不到锁的线程会被挂起，唤醒时大概率要重新调度 - IO操作（如
System.in.read()、FileInputStream.read()）：底层陷入系统调用，线程阻塞 - 频繁创建新线程（比如循环里
new Thread(...).start()）：每个线程启动/终止都伴随至少一次上下文切换
为什么线程数多≠性能高？关键在缓存和时间片
一个4核CPU上启了50个线程，不是“更忙”，而是“更累”——因为：
- 每个切换都要刷新TLB和CPU缓存，导致后续指令/数据大概率miss，被迫从内存取，慢10倍以上
- 时间片变短（比如从10ms缩到0.2ms），线程刚热好CPU缓存，就被切走了
- 线程栈内存持续增长（每个线程默认1MB栈空间），容易触发GC，而GC Stop-The-World又引发新一轮切换
实测常见现象：ExecutorService.newFixedThreadPool(100) 处理纯CPU任务，吞吐量反而比newFixedThreadPool(4)低40%以上。
立即学习“Java免费学习笔记（深入）”；
ThreadLocal不是上下文切换的解药，用错反而加重负担
ThreadLocal 本质是给每个线程配独立变量副本，它不减少切换次数，但能避免因共享变量加锁引发的阻塞切换。不过要注意：
- 在线程池中不
remove()会导致内存泄漏——旧线程复用时仍持有前一个请求的上下文 -
InheritableThreadLocal在线程池里基本失效（子线程是池里预建的，非真正“继承”） - 如果只是传参，用方法参数或封装对象比
ThreadLocal更可控、更易测试
真正降低切换开销的手段，从来不是“怎么传上下文”，而是“怎么少切换”：压减线程数、用异步IO、避免无谓阻塞、优先选无锁结构——这些地方，比琢磨ThreadLocal的set顺序重要得多。
