线程上下文切换会触发内核态切换，因Java线程映射到OS线程，JVM让出CPU需系统调用（如sys_sched_yield），涉及寄存器保存、TLB刷新等硬件开销，典型耗时1–5μs。
线程上下文切换为什么会触发内核态切换
Java 线程本质是映射到操作系统线程（如 Linux 的 pthread），每次 JVM 要让出 CPU 给另一个线程，就必须调用系统调用（如 sys_sched_yield 或 sys_futex）进入内核态。这个过程涉及寄存器保存、TLB 刷新、页表切换、缓存行失效等硬件级开销。
常见触发点包括：
-
synchronized块争抢失败时挂起当前线程 -
Object.wait()或LockSupport.park()主动阻塞 - 线程执行完时间片被调度器强制抢占（尤其在可运行线程数 > CPU 核心数时）
一次上下文切换实际耗时多少
不是固定值，但可在典型服务器上实测参考：
perf stat -e context-switches,cpu-clock sleep 1显示单次上下文切换平均消耗约
1–5 μs（微秒）。听起来很小，但若每毫秒发生上千次切换（如高并发短任务场景），CPU 时间就大量消耗在“换人干活”而非“干活”本身。
关键影响因素：
立即学习“Java免费学习笔记（深入）”；
- 是否跨 NUMA 节点迁移：跨节点切换会带来远程内存访问延迟，开销翻倍
- 是否触发 TLB miss：切换后新线程首次访存可能引发 TLB 重填，额外增加
100+ ns - 是否伴随锁竞争：如
ReentrantLock的 AQS 队列操作 + park/unpark，叠加 JVM 层开销
如何判断应用正被上下文切换拖慢
不能只看线程数，要结合 OS 和 JVM 指标交叉验证：
- Linux 层：
vmstat 1观察cs（context switch）列是否持续 > 10k/s；pidstat -w -p查看目标进程每秒切换次数1 - JVM 层：
jstack抓堆栈，若大量线程卡在java.lang.Thread.State: BLOCKED或WAITING (parking)，且持有锁的线程极少，大概率是锁+切换双瓶颈 - 火焰图：
async-profiler录制--event context-switch，直接定位高频切换热点方法
减少不必要切换的实用手段
核心思路是降低阻塞频率、延长单次执行时间、避免线程数膨胀：
- 用
LongAdder替代AtomicInteger：减少 CAS 失败重试导致的自旋或退避式 park - 批量处理代替逐条提交：比如把 100 次小
ExecutorService.submit()合并为单次invokeAll()，减少任务调度和线程唤醒次数 - 调整线程池大小：不要盲目设成
Runtime.getRuntime().availableProcessors() * 2，对 I/O 密集型可用IO_WAIT_TIME / CPU_TIME * core估算，避免空转线程堆积 - 慎用
Thread.sleep(1)等短间隔轮询：改用LockSupport.parkNanos()或事件驱动（如Selector）
真正难的是识别“隐性切换”——比如一个 CompletableFuture 链中嵌套了 5 层 thenApply，每次回调都可能跨线程调度，看似异步实则放大切换次数。这类问题只能靠 profiler 定位，没法靠经验猜。
