上下文切换是CPU在切换线程时保存/恢复运行状态的过程，本质是不产生业务价值的资源消耗；其开销包括寄存器操作（1–10μs）、缓存失效、调度器计算及内核态陷出陷进；高频切换常由sleep/wait、锁竞争、I/O阻塞、时间片耗尽及GC等引发；优化需合理设线程池、减锁粒度、用无锁结构、引入虚拟线程并加强监控。
上下文切换，就是CPU从执行一个线程，临时停下，转去执行另一个线程时，必须做的“交接工作”：保存当前线程的运行状态（比如程序计数器、寄存器值、栈指针等），再把下一个线程之前存好的状态恢复回来。这个过程本身不干活，却耗资源——它不是快慢问题，而是“干了没用功”的典型。
上下文切换的真实开销在哪
一次切换看似眨眼之间，但实际包含多个隐性成本：
- 寄存器与内存操作：保存/恢复几十个寄存器、更新栈帧、刷新TLB（地址转换缓存），每次约1–10微秒；高并发下每秒10万次切换，光切换就吃掉近1秒CPU时间
- CPU缓存失效：线程A刚加载的数据还在L1缓存里，切到线程B后缓存被冲刷或挤占，再切回A就得重新从内存加载——这不是延迟，是“伪共享+冷缓存”的双重惩罚
- 调度器参与：Linux CFS调度器要遍历就绪队列、计算虚拟运行时间、做负载均衡，尤其跨CPU核心切换时，还会触发NUMA迁移和远程内存访问
-
内核态陷出陷进：像
wait()、sleep()、synchronized争锁失败，都会触发用户态→内核态→用户态的三段跳，比纯用户态协作开销大得多
哪些代码行为最容易引发高频切换
不是“用了多线程”就会切换，而是特定操作会主动或被动触发调度：
-
显式让出CPU：调用
Thread.sleep(1)、Object.wait()、LockSupport.park() -
锁竞争失败：多个线程抢同一把
synchronized或ReentrantLock，失败者进入阻塞队列，状态变BLOCKED→ 等待唤醒时再次调度 - I/O阻塞：Socket读写、文件操作、数据库查询未设超时，线程挂起，操作系统立即换人
- 时间片耗尽：尤其在大量短任务+小线程池场景下，线程还没做完就被强制切走
- JVM内部动作：Full GC导致Stop-The-World、偏向锁撤销时挂起目标线程
真正管用的优化方式
别只盯着“加机器”或“升版本”，重点落在可控的编码与配置上：
-
线程池大小要算，不能拍：CPU密集型任务，线程数≈CPU核心数；IO密集型可按公式
线程数 = CPU核心数 × (1 + 平均等待时间/平均工作时间)估算，避免“100个线程只干3件事” -
锁要短、要细、要尽量绕开：把耗时操作（如日志、HTTP调用）移出同步块；用
ConcurrentHashMap代替Hashtable；读多写少场景优先选StampedLock或ReadWriteLock -
用无锁替代有锁：计数器类场景直接上
AtomicInteger或LongAdder；队列选ConcurrentLinkedQueue而非synchronized ArrayList -
善用虚拟线程（JDK 21+）：对I/O密集型任务（如Web请求、DB查询），把传统
ExecutorService换成Thread.ofVirtual().start()，百万连接不再意味着百万OS线程 -
监控先行，别猜：用
vmstat 1看cs列；用pidstat -w -p定位进程级切换热点；结合1 jstack查java.lang.Thread.State: BLOCKED线程堆栈
一句话总结
上下文切换不是Java独有，但Java程序员最容易在锁、线程数、阻塞I/O这三处“主动踩坑”；优化不在炫技，而在让线程更少地等、更少地争、更少地进内核——基本上就这些。
