Java上下文切换是操作系统强制执行的CPU资源让渡过程，涉及状态保存与加载，开销大且易被滥用；new Thread()过多、wait/sleep/join频繁调用、锁竞争激烈均会显著增加切换次数。
Java 中的“上下文切换”不是 Java 语言自己实现的机制，而是 JVM 在操作系统线程之上运行时，由操作系统强制执行的 CPU 资源让渡过程——简单说，就是 CPU 从一个 Java 线程切到另一个 Java 线程时，必须保存前者状态、加载后者状态的操作。它不透明、有开销、且极易被滥用。
为什么 new Thread() 一多就卡？——线程创建直接触发高频切换
每次调用 new Thread().start()，不仅会创建 JVM 线程对象，还会向操作系统申请一个原生线程（pthread）。而 OS 线程数量一旦远超 CPU 核心数（比如 200 个线程跑在 4 核机器上），调度器就必须每几毫秒就做一次切换。实测显示：1000 个短命线程可能引发每秒数万次 cs（context switch）值飙升，vmstat 1 中的 cs 列会突破 50000+。
- 错误写法：
for (int i = 0; i < 500; i++) { new Thread(() -> doWork()).start(); // 每次都新建，毫无复用 } - 正确做法：
用
ThreadPoolExecutor控制并发度，核心线程数建议设为Runtime.getRuntime().availableProcessors()或略高；拒绝策略优先选CallerRunsPolicy，避免任务堆积和线程爆炸 - 注意点：线程池
corePoolSize设得太小会导致任务排队；设得太大（如 >2×CPU 核数）反而加剧切换，尤其在大量 I/O 阻塞场景下
wait()/sleep()/join() 看似无害，实为切换“触发器”
Object.wait()、Thread.sleep(1)、CountDownLatch.await() 这些方法本身不耗 CPU，但会让当前线程进入 WAITING 或 TIMED_WAITING 状态，OS 立即将其从运行队列移出，并调度下一个就绪线程——这是一次完整上下文切换。频繁调用等于主动“交出 CPU”，还附带缓存失效成本。
- 典型陷阱：在 for 循环里写
Thread.sleep(1)做轮询等待，每毫秒一次切换，比 busy-wait 更伤性能 - 替代方案：用
LockSupport.parkNanos()+ 条件检查，或改用非阻塞 I/O（如Selector）、响应式流（如 Project Reactor） - 验证方式：用
jstack查看线程堆栈，若大量线程停在java.lang.Thread.sleep(Native Method)或java.lang.Object.wait(Native Method)，基本可判定是人为诱导切换
锁竞争越激烈，切换越频繁——BLOCKED 状态不是静止，而是“排队入场”
当多个线程争抢同一把 synchronized 锁或 ReentrantLock 时，失败者不会立刻消失，而是被 JVM 加入该锁的等待队列，并进入 BLOCKED 状态。一旦持有锁的线程释放锁，JVM 就唤醒一个等待者——这个“唤醒→调度→切入”的链路，必然伴随上下文切换。
- 现象特征：
pidstat -w显示cswch/s（自愿切换）不高，但nvcswch/s（非自愿切换）飙升，说明线程常被抢占而非主动让出 - 优化方向：缩小同步块范围（只锁必要代码段）、用
StampedLock替代读多写少场景的ReentrantReadWriteLock、对计数类操作优先用LongAdder而非synchronized - 特别注意：
偏向锁在高竞争下会升级为轻量级锁甚至重量级锁，升级过程本身就会挂起/唤醒线程，带来额外切换开销（JDK 15+ 默认关闭偏向锁，但老版本仍需警惕）
上下文切换真正难防的地方在于：它既不报错，也不抛异常，性能衰减是渐进且分散的——你看到的是吞吐下降、P99 延迟毛刺、CPU 利用率虚高，却很难一眼定位到某行代码。最有效的办法，是结合 vmstat、pidstat -w 和 jstack 三连查，在压测中盯住 cs 值与线程状态分布，而不是凭感觉调参数。
