线程上下文切换是多线程必然开销，每秒数万次即成性能瓶颈；常见于线程数远超CPU核心数、频繁阻塞（如synchronized争抢、BIO读写）或线程池配置不当，导致CPU空转切换而非执行业务。
线程上下文切换本身不干活，却吃掉大量 CPU 时间——它不是 bug，而是多线程运行的必然开销；但一旦每秒发生数万次，就成了性能瓶颈的元凶。
为什么加了线程，吞吐量反而下降？
因为线程数远超 CPU 核心数时，操作系统忙于“救火”：保存 PC、SP、寄存器状态，加载下一个线程的上下文，而不是执行你的业务逻辑。一次切换约耗 1–10 微秒，看似不多，但每秒 5 万次就是 500ms 的纯浪费。
- 常见现象：
vmstat 1中cs（context switch）列持续高于 20000，而%us（用户态 CPU）不高，%wa（I/O 等待）也不高——说明 CPU 正在空转做切换 - 典型场景：用
Executors.newFixedThreadPool(200)跑在 8 核机器上；或大量线程反复调用Object.wait()/LockSupport.park() - 关键误区：认为“线程越多，并发越强”，其实超过
2 × CPU 核心数后，收益急剧衰减，开销开始主导
哪些 Java 操作会触发高频上下文切换？
不是所有线程阻塞都一样——有些操作会让线程立刻让出 CPU 并进入内核调度队列，代价极高；有些则只是自旋等待，可控得多。
-
synchronized争抢失败：重量级锁会调用pthread_mutex_lock，触发内核态挂起/唤醒，伴随完整上下文切换 -
Thread.sleep(1)或Object.wait(10)：主动放弃时间片，强制切出，再由调度器决定何时切入 - 传统 BIO Socket 读写：一次
read()阻塞，线程进入BLOCKED状态，CPU 立即切换；NIO + Selector 可避免此问题 - 频繁创建/销毁线程：每次
new Thread().start()都涉及内核线程创建（clone()系统调用），比复用线程池贵一个数量级
怎么快速定位是不是上下文切换惹的祸？
别猜，用工具看真实数据。重点关注两个维度：切换频次（cs）和切换诱因（谁在频繁 park/unpark 或阻塞）。
- 基础命令：
vmstat 1看cs值；pidstat -w -p <pid> 1</pid>查目标进程每秒切换次数 - 深度追踪：
perf record -e sched:sched_switch -p <pid> sleep 10</pid>，再用perf script分析切换热点线程 - JVM 内视角：Arthas 的
thread -n 5查最忙线程；watch java.lang.Thread park * -n 5监控park调用堆栈 - 注意陷阱：JDK 自带的
jstack只能看快照状态（如WAITING），无法反映切换频率；cs高但线程都在RUNNABLE，大概率是锁竞争或自旋过度
线程池配置和锁优化怎么真正降低切换？
核心原则：减少“被迫切换”、压缩“切换半径”、避免“无效切换”。这不是调参游戏，而是对执行模型的重新设计。
- 线程池大小：优先用
Executors.newWorkStealingPool()（ForkJoinPool），它基于 work-stealing，天然减少空闲线程；固定池推荐公式：corePoolSize = CPU 核心数 × (1 + 平均等待时间 / 平均工作时间) - 锁降级：把
synchronized方法改成ReentrantLock+tryLock(10, TimeUnit.MILLISECONDS)，失败就退避重试或走异步路径，避免死等挂起 - IO 模型升级：将
InputStream.read()替换为AsynchronousSocketChannel或 Netty 的EventLoop，让少量线程处理大量连接 - 警惕伪共享：两个高频更新的
volatile字段（如value1和value2）若落在同一缓存行，会导致多核间缓存同步风暴——看似没锁，实则切换更隐蔽
上下文切换藏得深：它不报错、不抛异常、日志里也看不出慢在哪。你看到的“卡顿”，很可能是线程刚切进来，缓存全失效，又得重新加载指令和数据——这种延迟没法被 profiling 工具直接标红，只能靠 cs 数值+线程状态+系统调用链交叉验证。
