上下文切换发生在操作系统调度线程时，包括时间片用完、sleep()、wait()、synchronized争抢失败、park()等导致线程让出CPU的环节，每次耗时1~5μs并破坏CPU缓存局部性。
上下文切换到底发生在哪几个环节
Java并发编程里说的上下文切换，不是JVM自己“切”的，而是操作系统在调度线程时强制发生的。只要线程从运行态被剥夺CPU（比如时间片用完、主动sleep()、等待Object.wait()、竞争synchronized失败、或调用LockSupport.park()），内核就得保存当前线程的寄存器、栈指针、程序计数器等状态，并加载下一个线程的对应状态——这个过程就是上下文切换。
常见触发点包括：
-
synchronized块争抢失败且锁不可重入时，线程会进入阻塞队列并让出CPU - 使用
ReentrantLock.lock()且未获取到锁，默认走AbstractQueuedSynchronizer的park()逻辑 - 调用
Thread.sleep()、Object.wait()、Condition.await() - 频繁执行
ExecutorService.submit()但线程池过小，导致任务排队+线程反复唤醒/挂起
一次上下文切换实际耗多少时间
没有固定值，但可以量化参考：在主流Linux x86-64服务器上，一次完整的用户态线程上下文切换通常消耗 1~5 μs（微秒）。这看起来很少，但一旦每毫秒发生几百次，累积开销就直接吃掉CPU周期。
更关键的是，它会破坏CPU缓存局部性：
立即学习“Java免费学习笔记（深入）”；
- 被切换走的线程数据大概率从L1/L2缓存中被踢出
- 新线程加载后要重新预热缓存行，引发大量
cache miss - 如果切换频繁且线程间无数据共享，性能下降可能比纯计算还明显
可以用perf stat -e context-switches,task-clock,cycles实测自己服务的切换频次。
哪些Java写法会悄悄放大上下文切换代价
很多看似“无害”的写法，在高并发下会成倍放大切换频率：
- 用
new Thread()代替线程池——每次创建+销毁都伴随至少2次切换（启动和终止） - 在循环里调用
CountDownLatch.await()或Semaphore.acquire()而不设超时，一旦条件不满足就长期阻塞+唤醒抖动 -
CompletableFuture.runAsync()提交大量短任务，但ForkJoinPool.commonPool()被IO型任务拖慢，导致后续任务排队等待空闲线程 - 用
volatile变量做简单标志位轮询（如while(!done) Thread.yield();），虽不进内核，但yield()仍可能触发调度器介入，且浪费CPU周期
怎么验证你的代码真被上下文切换拖慢了
别猜，用工具定位。最直接的方式是结合JDK自带工具和系统指标：
jstack -l| grep "java.lang.Thread.State" | sort | uniq -c | sort -nr
看WAITING和BLOCKED线程数量是否远高于正常业务负载；再配合：
pidstat -w -t -p1
观察cswch/s（每秒自愿切换）和nvcswch/s（每秒非自愿切换）是否持续超过单核5000次。若nvcswch/s偏高，说明线程常被时间片打断，大概率存在锁竞争或密集计算+频繁阻塞。
真正难察觉的是“伪低切换”场景：比如所有线程都在park()，但唤醒逻辑有延迟，导致任务积压后集中爆发式唤醒——这时pidstat看到的切换峰值可能只持续几毫秒，却足以打爆下游TPS。
