线程上下文切换本质是操作系统保存并恢复CPU寄存器、栈指针、内存映射等状态，每次切换需陷入内核、引发缓存失效，平均耗时1–3μs；高频率切换会导致延迟飙升与缓存命中率下降。
线程上下文切换到底在切什么
线程上下文切换不是“换一个线程跑”，而是操作系统保存当前线程的 CPU 寄存器状态（如 rip、rsp、rbp）、内存映射、栈指针、浮点寄存器等，再加载下一个线程的对应状态。这个过程由内核完成，每次切换都涉及至少一次用户态到内核态的陷进（trap），以及若干次缓存失效。
常见错误现象：Thread.sleep(0) 或 Object.wait() 后线程立刻被唤醒但响应变慢；高并发下 CPU usage 不高但 latency 暴涨；vmstat 1 显示 cs（context switch）列持续高于 10k/s。
- Java 应用本身不直接触发上下文切换，但
synchronized争用、LockSupport.park()、I/O 阻塞（如Socket.read()）、GC 停顿都会导致线程让出 CPU，进而引发调度器介入 - 64 位 Linux 下一次完整上下文切换平均耗时约 1–3 μs，看似很小，但在每秒百万级线程切换时，累积开销可达毫秒级延迟
- 频繁切换还会冲刷
L1/L2 cache，导致后续指令/数据访问命中率下降，间接拖慢所有线程
为什么 synchronized 和 ReentrantLock 切换代价不同
synchronized 在无竞争时走快速路径（monitorenter 直接修改对象头），几乎不触发系统调用；一旦发生竞争，JVM 会升级锁并可能调用 pthread_mutex_lock，最终落入内核调度队列。而 ReentrantLock 默认使用 AbstractQueuedSynchronizer（AQS），其 acquire() 中的 LockSupport.park() 本质是调用 nanosleep 或 futex_wait，同样引发上下文切换。
关键差异在于：AQS 支持自旋优化（tryAcquire 失败前可先自旋几次），而 synchronized 的自旋策略由 JVM 决定（可通过 -XX:PreBlockSpin 调整，但 JDK 8+ 已基本废弃该参数）。
立即学习“Java免费学习笔记（深入）”；
- 高争用场景下，
ReentrantLock若未启用fair = false（默认），可能比synchronized更容易造成线程排队和调度抖动 - 使用
StampedLock的乐观读模式可完全避免线程阻塞，但需注意版本校验失败后仍要降级为悲观读，此时仍可能 park - JDK 10+ 的
VarHandle.compareAndSet+ 自定义状态机，能进一步绕过锁机制，减少 park/unpark 次数
如何定位是不是上下文切换成了瓶颈
不能只看 jstack 或 jstat —— 它们反映的是 Java 层状态，而上下文切换是 OS 层行为。真正有效的指标来自操作系统工具：
- 用
pidstat -w -p <pid> 1</pid>观察单个 Java 进程的每秒切换次数（cswch/s字段），持续 >5k/s 就值得警惕 -
perf record -e sched:sched_switch -p <pid></pid>可抓取具体哪两个线程在频繁切换，配合perf script分析热点对 -
cat /proc/<pid>/status | grep ctxt</pid>查看进程累计切换数，对比两次采样差值可估算速率 - 注意区分 voluntary（主动让出，如 wait/park）和 involuntary（被抢占，如时间片用完），前者更易优化
减少不必要的上下文切换的实际手段
很多优化不是“写得更炫”，而是“少做一点”：比如避免在循环里反复加锁、别用 wait/notify 实现忙等、慎用 CompletableFuture.runAsync() 提交短任务到公共 ForkJoinPool。
- 将多个小任务合并为批量操作（如把 100 次
queue.offer()改成一次queue.addAll(list)），降低锁竞争频次 - 用
ThreadLocal缓存昂贵对象（如SimpleDateFormat），避免多线程争抢单例资源 - 异步 I/O（
AsynchronousSocketChannel）或 Netty 的 event loop 模型，能让单线程处理大量连接，从根源上压制线程数量 - JDK 21 的虚拟线程（
Thread.ofVirtual().start()）虽不消除切换，但把调度权交还给用户态调度器（Loom），大幅降低每次 park/unpark 的系统调用开销
上下文切换本身不可消灭，但它的成本是否显著，取决于你有没有让线程在不该停的地方停、在不该醒的时候醒。最常被忽略的一点是：日志框架的同步 appender（如 Log4j 的 ConsoleAppender 默认配置）会在每次 logger.info() 时锁住输出流——这在高并发服务里可能成为隐形的调度放大器。
