线程上下文切换是CPU在多线程间切换时保存/加载状态的过程，消耗CPU周期并引发缓存失效，锁竞争和线程数失控是主因；优化需控制线程总数、降低锁竞争、配合JVM调优与监控。
线程上下文切换是CPU在多个线程间切换执行时，保存当前线程状态（如寄存器、程序计数器、栈指针）并加载目标线程状态的过程。它本身不做事，却消耗CPU周期、引发缓存失效（如L1/L2 cache、TLB刷新），是高并发Java系统中典型的“隐性性能杀手”。而锁竞争和线程数量失控，正是触发高频切换的两大主因。优化的核心不是消灭切换，而是让切换更少、更轻、更可控。
控制线程总数：避免“人多活少”式内耗
线程不是越多越好——每个线程默认占用约1MB栈空间，且操作系统调度器需为每个就绪线程做决策。当线程数远超CPU核心数（比如64核机器启了200个活跃线程），大量线程反复争抢时间片，导致每毫秒内发生数百次上下文切换，CPU忙于调度而非计算。
- CPU密集型任务：线程数 ≈ CPU核心数 + 1（+1用于应对偶发阻塞，如缓存未命中）
- I/O密集型任务：可用公式粗估：线程数 = CPU核心数 × (1 + 平均I/O等待时间 / 平均CPU执行时间)，实践中常设为核心数的2–8倍，并通过压测验证
- 务必使用ThreadPoolExecutor替代new Thread()，复用线程、避免创建/销毁开销；拒绝无界队列（如LinkedBlockingQueue无参构造），防止任务积压导致线程池盲目扩容
降低锁竞争频率：减少线程因等待而被挂起
锁竞争直接导致线程从RUNNABLE进入BLOCKED或WAITING状态，一旦被唤醒，大概率触发一次上下文切换。频繁加锁、长持有、大粒度锁，都会放大这一效应。
- 缩小临界区：只把真正需要同步的代码包进synchronized块或lock.lock()/unlock()，把日志、对象构造、网络调用等移出锁外
- 减小锁粒度：用ConcurrentHashMap代替Collections.synchronizedMap；对大集合按key分段加锁（如分段锁、StripedLock）；避免全局单例锁保护多个无关资源
- 优先使用无锁结构：如AtomicInteger、LongAdder（高并发累加场景比synchronized快数倍）、CAS类操作；读多写少时考虑CopyOnWriteArrayList
配合JVM与运行时策略进一步抑制切换
光靠代码逻辑还不够，需结合JVM机制和部署环境协同优化：
立即学习“Java免费学习笔记（深入）”；
- 关闭偏向锁（-XX:-UseBiasedLocking）：在多线程竞争明显的业务场景（如网关、订单服务），偏向锁升级反而增加开销
- 合理配置自旋锁：轻量级锁的自旋可避免立即挂起，但过度自旋浪费CPU；JVM默认启用适应性自旋，无需手动干预，除非明确观测到自旋失败率极高
- 绑定CPU亲和性（Linux下taskset或JNA）：将关键业务线程固定到特定核心，提升缓存局部性，降低切换后cache miss率
- 监控定位：用vmstat -w 1看cs（context switch）列；jstack查BLOCKED/WAITING线程数；Arthas thread -n 5找最耗时锁点
