上下文切换由操作系统执行，java线程默认一对一映射内核线程，sleep、wait、阻塞i/o、锁竞争和gc等操作会触发切换；高频切换表现为cs持续超5万/秒，优化需控制就绪线程数并排查锁与i/o根因。
上下文切换不是Java发明的，是操作系统干的活
Java线程的上下文切换，本质是操作系统（比如Linux）在调度OS线程时做的保存/恢复动作——Java的Thread对象默认一对一映射到内核线程（1:1模型），所以每次Java线程被切走或切回，都触发一次真实的CPU寄存器搬运、栈指针切换和TLB刷新。它不发生在JVM字节码层面，也不由JVM自己调度；JVM只负责创建、启动、挂起线程，真正“按暂停键”的是内核调度器。
哪些Java代码会悄悄触发上下文切换
你写的每行Java代码本身不会切换，但以下操作会直接让线程进入非RUNNABLE态，从而强制OS介入调度：
-
Thread.sleep(1)：主动让出时间片，线程进TIMED_WAITING，必然切换 -
Object.wait()或LockSupport.park()：挂起当前线程，等待唤醒，OS必须切走它 - 阻塞I/O调用，如
socket.getInputStream().read()：线程卡在系统调用里，状态变WAITING或BLOCKED - 争抢
synchronized锁失败：线程被扔进Monitor的EntryList，状态为BLOCKED，等待锁释放时已被切出 -
System.gc()（尤其用Parallel GC时）：Stop-The-World期间所有应用线程被强制挂起+恢复，算批量切换
怎么确认你的Java程序正被上下文切换拖慢
别猜，用真实指标看。高频切换的典型信号不是CPU高，而是“CPU忙但吞吐低”：
- 跑
vmstat 1，盯cs列：持续 > 50,000/s 就危险；超过10万基本说明调度器快扛不住了 - 查具体Java进程：
pidstat -w -p <pid> 1</pid>，看cswch/s（自愿切换）和nvcswch/s（非自愿切换）——后者高，大概率是时间片耗尽或锁竞争 - 抓线程快照：
jstack <pid></pid>，如果大量线程停在java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject或parking to wait for，就是锁在制造被动切换
减少切换不是靠少写线程，而是控制“可调度实体”数量
很多人以为“用线程池=优化”，但若线程池核心数设成200，而机器只有8核，结果就是200个线程反复抢8个CPU，切换爆炸。关键不是线程少，而是就绪态线程数要贴近CPU可用核心数：
立即学习“Java免费学习笔记（深入）”；
- 计算公式：
线程池大小 ≈ CPU核心数 × (1 + 平均等待时间 / 平均工作时间)（参考Little’s Law） - I/O密集型任务（如HTTP调用）：可适当放大，但别超
2×CPU核心数；否则缓存污染比并发收益还大 - CPU密集型任务：严格控制在
CPU核心数 + 1以内，多一个是为了防某个线程偶尔阻塞 - 替代方案：Java 21+ 的虚拟线程（
Thread.ofVirtual()）把调度从OS下沉到JVM，千万级并发下切换开销几乎归零——但它不解决同步阻塞问题，synchronized照样卡住整个carrier线程
Thread.ofVirtual().unstarted(() -> {
// 这里即使sleep(100)，也不会引发OS级上下文切换
// 但若在此处调用阻塞I/O或拿不到synchronized锁，仍会拖慢carrier
System.out.println("virtual thread running");
}).start();
真正难处理的从来不是“怎么切”，而是“为什么不得不切”——锁设计、I/O模型、GC策略，这些才是上下文切换背后的根因。盯着cs数字调优，不如先看jstack里哪几行代码总在排队。
