Java上下文切换是什么？线程调度机制详解

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 值与线程状态分布，而不是凭感觉调参数。