线程频繁切换开销巨大，优化核心是“尽量少切”：CPU密集型任务设线程数≈CPU核心数+1，IO密集型按公式估算并上限200；禁用newCachedThreadPool，优先用ForkJoinPool+CompletableFuture实现非阻塞流水线；任务类型隔离、避免阻塞操作混用、消除锁竞争、合理使用ThreadLocal与原子类。
线程频繁切换不是“换了个栈”那么简单，它要保存寄存器、刷新TLB、失效缓存行、进出内核态，一次就耗1–5微秒。高并发短任务下，切换开销可能吃掉整颗CPU。优化核心不是“怎么切得快”，而是“尽量少切”。
合理设置线程池大小，避免盲目扩容
线程数远超CPU核心数，吞吐量不升反降——这不是理论，perf stat -e context-switches能直接看到每秒百万级切换在抢CPU时间。
- CPU密集型任务（如加解密、图像处理）：线程数 ≈ CPU核心数 + 1，+1用于应对页缺失等瞬时停顿
- I/O密集型任务（如HTTP调用、DB查询）：按公式
CPU核心数 × (1 + 平均等待时间 / 平均工作时间)估算，但上限建议控制在200以内 - 别用
Executors.newCachedThreadPool()——它无限扩容，突发流量下可能瞬间拉起数百线程
用ForkJoinPool + CompletableFuture做非阻塞流水线
普通线程池在任务细碎、依赖多时容易排队空转；而ForkJoinPool自带工作窃取机制，空闲线程主动拉任务，保持CPU饱和，减少因等待导致的挂起与切换。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 计算型任务优先走
ForkJoinPool，默认并行度是availableProcessors() - 1，别盲目调大 -
CompletableFuture链式操作（如thenApply、thenCompose）把串行等待转为异步流水线 - 严禁在回调里写
Thread.sleep()或JDBC查询——这会卡住ForkJoinPool.commonPool() - IO操作必须指定独立线程池：
thenApplyAsync(fn, ioExecutor)，别让它污染计算池
消除锁竞争和跨线程共享状态
线程因争抢synchronized或ReentrantLock而挂起、被调度器换出，是上下文切换最常见诱因之一。
立即学习“Java免费学习笔记（深入）”；
- 高频读写的上下文数据（如用户ID、事务ID、SimpleDateFormat）改用
ThreadLocal绑定到线程自身，彻底避开锁 -
ThreadLocal用完必须remove()，尤其在线程池场景下，否则会导致内存泄漏 - 避免存大对象或未关闭资源（如Connection、InputStream）
- 父子线程传参不用全局静态变量加锁，优先选
InheritableThreadLocal或显式透传
任务类型隔离 + 避免阻塞式编程
混合CPU和IO任务在一个线程池里，等于让快线程等慢线程，人为制造切换压力。
- 把DB查询、远程调用等阻塞操作剥离，交给专用IO线程池（如
newCachedThreadPool()或带界队列的ThreadPoolExecutor） - 日志里看到大量
WAITING (on object monitor)，基本就是同步块成了瓶颈，该拆锁或换无锁结构了 - 简单计数、开关标志等场景，优先用
AtomicInteger、AtomicBoolean代替锁，但别硬套CAS去更新复杂对象 - 慎用线程优先级——JVM不保证跨OS行为一致，且可能加剧调度抖动
