优化线程状态切换需聚焦RUNNABLE态，减少阻塞态频次；合理配置线程池大小；用虚拟线程替代平台线程处理I/O；监控OS级上下文切换指标定位瓶颈。
线程状态切换不当会直接拉高上下文切换频率，导致CPU忙于调度而非执行任务，吞吐量不升反降。优化核心不是“避免切换”，而是让切换更少、更轻、更可控。
聚焦 RUNNABLE 状态，减少 BLOCKED/WAITING 进入频次
阻塞态（BLOCKED、WAITING、TIMED_WAITING）是上下文切换的高发区——每次锁竞争失败或调用 wait()/sleep() 都可能触发一次切换。关键在于压缩线程在非运行态的停留时间：
- 用 java.util.concurrent.locks.StampedLock 替代 synchronized，支持乐观读，降低写竞争引发的 BLOCKED 概率
- 避免在临界区内做 I/O 或远程调用；把耗时操作移出 synchronized 块，改用异步回调或分阶段提交
- 慎用 Object.wait()；优先使用 LockSupport.parkNanos() 或 CompletableFuture.delayedExecutor() 实现可控等待
按任务类型压准线程池大小，杜绝“线程过剩”
线程数远超 CPU 核心数时，RUNNABLE 线程争抢 CPU，调度器被迫高频切换。必须区分任务性质来设限：
- CPU 密集型：corePoolSize = Runtime.getRuntime().availableProcessors()，maximumPoolSize 不宜超过该值 + 1
- I/O 密集型：可用公式估算：corePoolSize ≈ CPU核心数 × (1 + 平均等待时间 / 平均计算时间)，实测建议从 ×2 开始调优
- 禁用 Executors.newCachedThreadPool() —— 它的无界线程创建机制极易在流量突增时引发万级线程并发，触发系统级调度风暴
用虚拟线程替代平台线程处理 I/O 阻塞
Java 21+ 的虚拟线程（Virtual Thread）让每个 I/O 等待不再绑定操作系统线程，彻底规避因阻塞导致的上下文切换开销：
立即学习“Java免费学习笔记（深入）”；
- 直接使用 Executors.newVirtualThreadPerTaskExecutor() 启动任务，无需调整线程数
- 原有同步 I/O 代码（如 InputStream.read()、Socket.accept()）可原样保留，JVM 自动挂起/恢复虚拟线程
- 单机轻松支撑 10 万+ 并发连接，栈内存占用仅约 1KB/线程，对比传统线程（默认 1MB）节省百倍资源
监控真实切换指标，别只看线程数
光看活跃线程数容易误判。应采集 OS 层级指标定位问题根源：
- Linux 下用 pidstat -w -p <pid> 1 观察每秒上下文切换次数（cswch/s），持续 >5000 次需警惕
- JVM 内通过 ThreadMXBean.getThreadTotalCpuTime() 和 getThreadUserTime() 对比，若差值占比异常高，说明内核态调度开销过大
- 配合 Arthas 的 thread -n 5 查看最忙线程堆栈，确认是否卡在锁、wait 或无界队列的 take() 上
