上下文切换发生在操作系统调度线程时，由Java中synchronized争抢失败、ReentrantLock.lock()未获取锁、Thread.sleep()、Object.wait()、Condition.await()、CompletableFuture.runAsync()过载及new Thread()创建销毁等触发。
上下文切换到底发生在哪些 Java 代码里
上下文切换不是 JVM 自己“切”的，而是操作系统在调度线程时强制发生的。只要线程从运行态被剥夺 CPU，内核就得保存寄存器、栈指针、程序计数器等状态——这个过程就是一次上下文切换。
它常被误认为是“Java 层面的切换”，其实触发点全是操作系统可见的阻塞或让出行为：
-
synchronized块争抢失败且锁不可重入 → 线程进阻塞队列，主动让出 CPU -
ReentrantLock.lock()没抢到锁 → 底层调用LockSupport.park() -
Thread.sleep(1)、Object.wait()、Condition.await() - 线程池过小 + 大量
CompletableFuture.runAsync()提交 → 任务排队，线程反复唤醒/挂起 - 用
new Thread()启动短命任务 → 每次创建+销毁至少带来 2 次切换（启动和终止）
1~5μs 的代价，为什么能拖垮服务
单次切换耗时看似微不足道（主流 Linux x86-64 服务器上约 1~5 μs），但高频下会快速累积成显著开销：
- 每秒 10 万次切换 → 直接吃掉
0.1~0.5 秒CPU 时间 - 更致命的是缓存破坏：被切走的线程数据大概率从 L1/L2 缓存中被踢出；新线程加载后要重新预热缓存行，引发大量
cache miss - 若线程间无共享数据（比如纯计算型任务），性能下降可能比纯计算还明显
这不是理论推演——你可以用 perf stat -e context-switches,task-clock,cycles -p <pid> 实测自己服务的切换频次。
立即学习“Java免费学习笔记（深入）”；
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
怎么确认是不是上下文切换在拖慢你的应用
别靠猜。先看系统指标，再对齐线程状态：
- 用
vmstat 1观察cs列（每秒上下文切换次数），持续 >5000 就值得警惕 - 用
pidstat -w -p <pid> 1查看该进程的切换频率 - 用
jstack -l <pid>抓线程快照，重点关注：
– 大量线程处于BLOCKED（锁竞争）
– 大量线程卡在WAITING或TIMED_WAITING（如parking to wait for <xxx>）
如果 cs 高 + jstack 显示大量线程在等锁或等条件，基本可以锁定上下文切换是瓶颈源头。
真正管用的优化手段，不是“少开线程”那么简单
“减少线程数”只是表象。关键在于减少“被迫让出 CPU”的次数：
- 用
ExecutorService替代new Thread()，CPU 密集型任务线程数 ≈Runtime.getRuntime().availableProcessors() - 避免在循环里写
while(!done) Thread.yield()——yield()虽不进内核，但会触发调度器介入，且空转浪费 CPU - 把
synchronized换成AtomicInteger、StampedLock或无锁结构（如ConcurrentLinkedQueue），从根源消除阻塞 - I/O 密集场景慎用
ForkJoinPool.commonPool()，它会被阻塞任务拖慢；改用专用线程池，比如Executors.newCachedThreadPool()或自定义ThreadPoolExecutor
最易被忽略的一点：很多“优化”只关注单点（比如换锁），却没同步调整线程池大小和任务粒度。例如把 synchronized 换成 CAS 后，仍用 200 个线程并发处理 10 万个极短任务，切换压力依然存在——因为线程还是太多，而任务太碎。
