线程上下文切换是CPU保存当前线程状态并恢复另一线程状态的过程，涉及PC、寄存器、栈信息、内存管理上下文及Java特有状态；频繁切换导致CPU时间浪费、缓存失效、TLB刷新和特权级切换开销。
线程上下文切换，就是CPU从执行一个Java线程，临时停下来，把它的“当前状态”存好，再加载另一个线程的状态，继续执行的过程。它不是Java独有，但Java线程（1:1映射到OS线程）的每一次切换，都会触发操作系统级的保存与恢复动作，开销真实且可观。
上下文切换到底在切什么
切换的不是代码，而是线程的“运行快照”，主要包括：
- 程序计数器（PC）：记录下一条要执行的字节码指令地址；
- CPU寄存器值：如栈指针（SP）、通用寄存器、状态寄存器等；
- 线程栈信息：包括当前方法的栈帧、局部变量表、操作数栈、返回地址；
- 内存管理上下文：页表基址、TLB状态、虚拟内存映射；
- Java特有状态：如ThreadLocal变量副本、锁持有情况、JVM线程状态（RUNNABLE/BLOCKED/WAITING等）。
为什么频繁切换会拖慢Java应用
每次切换看似瞬间，但在高并发场景下，累积效应明显：
- CPU时间被“搬运”吃掉：单次切换耗时通常在0.5–10微秒，若每秒发生50万次，仅切换就占用0.25–5毫秒CPU时间——这还不算调度决策和缓存惩罚；
- CPU缓存反复失效：线程A刚把热点数据载入L1缓存，切到线程B后缓存被覆盖，再切回A就得重新从内存加载，延迟飙升；
- TLB刷新带来间接开销：跨线程常伴随虚拟地址空间切换，TLB（地址转换快表）失效会导致多次页表遍历；
- 用户态/内核态来回跳转：Java线程依赖系统调度，每次切换都需陷入内核完成上下文保存/恢复，额外增加两次特权级切换开销。
哪些Java操作最容易引发上下文切换
分两类看，一类是线程主动交出CPU，一类是被系统强制换下：
立即学习“Java免费学习笔记（深入）”；
-
自发性切换（可优化）：调用
Thread.sleep()、Object.wait()、LockSupport.park()、Thread.yield()； - 非自发性切换（需诊断）：时间片耗尽（尤其线程数远超CPU核心数时）、I/O阻塞（Socket读写、文件操作）、锁竞争导致BLOCKED、GC引发Stop-The-World暂停、偏向锁撤销时挂起线程。
怎么观察和定位过度切换问题
不能靠猜，得用工具实测：
-
系统层：
vmstat 1看cs列（每秒上下文切换次数），超过1万/秒就值得警惕；pidstat -w -p <pid> 1定位具体Java进程的切换频率； -
JVM层：
jstack <pid>检查大量线程卡在WAITING或BLOCKED状态，暗示锁或等待瓶颈； - 应用层：配合APM工具（如SkyWalking）关联线程状态变化与接口RT突增、吞吐下降，判断是否为切换诱发的性能拐点。
