上下文切换由操作系统完成，Java线程不负责保存恢复上下文；高频切换（如200线程跑4核、cs＞50000）会严重拖慢性能；Thread.sleep、频繁创建线程、锁竞争、滥用park等都会触发；可用jstack、vmstat、pidstat定位；线程池需按任务类型设参，避免CachedThreadPool，注意ThreadLocal泄漏。
上下文切换不是Java自己干的，是操作系统在“搬数据”
Java线程本身不保存或恢复上下文——那是操作系统的活。当你看到 Thread.sleep()、Object.wait() 或线程突然卡住又恢复，背后其实是 OS 把当前线程的寄存器、程序计数器、栈指针、TLB 状态等一整套快照存进内存，再把另一个线程的快照加载进 CPU。这个过程不透明、不可控，而且每次都要进内核态，开销在 0.5–10 微秒之间。
真正要警惕的，不是“有没有切换”，而是“切得太勤”。比如 200 个线程跑在 4 核机器上，vmstat 1 里 cs 列轻松破 50000，说明每秒五万次搬运，CPU 时间全花在“打包”和“拆包”上了，根本没剩多少给业务逻辑。
哪些 Java 写法会主动触发高频切换？
很多看似无害的操作，实则是上下文切换的“开关”：
-
Thread.sleep(1)在 for 循环里轮询：每毫秒切一次，比忙等（busy-wait）还伤性能； -
new Thread(() -> {...}).start()一次性起 500 个线程：每个都申请原生 pthread，调度器直接过载； - 大量
synchronized块争同一把锁：失败线程进入BLOCKED状态，不是静止，是在排队入场，随时准备被唤起切换； -
CountDownLatch.await()或LockSupport.park()被滥用：尤其在非阻塞场景下用成“伪异步”，反而制造切换热点。
怎么验证你的代码正在被切换拖垮？
别猜，直接看证据：
立即学习“Java免费学习笔记（深入）”；
- 用
jstack <pid></pid>查线程堆栈：如果一堆线程停在java.lang.Thread.sleep(Native Method)或java.lang.Object.wait(Native Method)，基本就是人为诱导切换； - 用
vmstat 1观察cs（context switch）列：持续 >10000 就该警觉，>30000 通常意味着线程模型或等待策略出了问题； - 配合
pidstat -t -p <pid> 1</pid>看具体哪个线程状态频繁跳变（RUNNABLE → WAITING → RUNNABLE循环），定位到类和方法。
线程池不是银弹，但设错参数等于白搭
用 ExecutorService 是对的，但很多人只改了线程数，没想清楚为什么这么设：
- CPU 密集型任务：核心数设为
Runtime.getRuntime().availableProcessors()，再多就是徒增切换； - I/O 密集型任务：可设为
2 × CPU 核心数左右，但若任务常阻塞在数据库或远程调用，得结合平均阻塞时长估算并发度，而不是盲目加线程； - 拒绝策略别用
AbortPolicy：任务丢了难排查；优先选CallerRunsPolicy，让调用线程自己执行，天然限流且不新增线程； - 别用
Executors.newCachedThreadPool()：它允许无限创建线程，corePoolSize=0+maximumPoolSize=MAX_VALUE，等于把调度压力全甩给 OS。
最常被忽略的一点：线程池里的线程复用，并不自动解决 ThreadLocal 泄漏或上下文传递问题。如果任务需要携带用户身份、事务ID等，得配合 InheritableThreadLocal 或显式透传，否则看似复用了线程，实际每次都在“裸奔”。
