线程上下文切换本质是操作系统保存并恢复CPU寄存器、栈指针和程序计数器等状态，必须经内核完成，单次耗时1~5微秒，高频切换会显著消耗CPU。
线程上下文切换到底在切什么
线程上下文切换不是“换一个线程跑”，而是操作系统保存当前线程的 CPU 寄存器状态、栈指针、程序计数器，再加载下一个线程的对应状态。这个过程必须由内核完成，哪怕只是两个用户态线程（比如 ForkJoinPool 里的工作线程），只要调度权在 OS 手里，就逃不开内核态切换开销。
一次典型切换的实际开销有多大
在主流 x86-64 Linux 上，一次完整上下文切换（包括用户态→内核态→用户态）通常耗时 1~5 微秒。听起来不多，但注意：这是单次成本；如果每毫秒发生几百次切换（比如高并发短任务场景），光切换就吃掉 >50% CPU 时间。
- 频繁调用
Thread.sleep(0)或Object.wait()会主动触发调度，极易引发抖动 -
synchronized块争抢激烈时，线程可能反复进入WAITING → RUNNABLE → BLOCKED状态，隐式放大切换频次 - 使用
ExecutorService但核心线程数设得远高于 CPU 核心数（如 64 核机器配 200 个线程），OS 调度队列膨胀，平均切换延迟上升
哪些 Java 操作会隐式导致上下文切换
很多看似“纯内存”的操作，背后藏着 OS 级调度信号：
-
LockSupport.park()和unpark()：虽然比wait/notify轻量，但仍需内核参与线程挂起/唤醒 -
CompletableFuture.join()在未完成时会阻塞当前线程，若该线程是ForkJoinPool.commonPool()的工作线程，可能触发补偿线程创建+切换 -
Thread.yield()：不保证切换，但多数 JVM 实现会调用sched_yield()，让出 CPU 时间片，增加后续调度概率 - 日志框架中同步写文件（如
FileAppender）若未加缓冲，每次write()可能触发系统调用并伴随线程阻塞
如何观测和定位切换热点
别猜，用工具看真实数据：
立即学习“Java免费学习笔记（深入）”；
perf record -e context-switches -g -p $(pgrep -f 'java.*YourApp') perf report -g --no-children
重点关注：Unsafe.park、os::PlatformEvent::park、pthread_cond_wait 这类符号的调用栈深度；如果 java.lang.Thread.sleep 出现在高频路径里，基本可以确认是人为引入的切换源。
更轻量的方式是看 /proc/PID/status 中的 voluntary_ctxt_switches 和 nonvoluntary_ctxt_switches：前者多说明代码主动让出（如 sleep/wait），后者高则大概率是时间片被抢占或锁竞争严重。
真正难处理的不是“能不能切”，而是“为什么切得这么密”——往往暴露的是任务粒度太小、锁范围过大、或异步链路里混入了同步阻塞调用。
