多线程池隔离与异步化改造需分道运行CPU/IO任务，合理配置线程数、使用有界队列和自定义拒绝策略，配合CompletableFuture异步编排、超时熔断及监控，避免OOM与性能劣化。
多线程池隔离与异步化改造，本质是把“混跑”变成“分道”，再把“干等”变成“边跑边办”。关键不在加线程，而在让每类任务跑在合适的地方、用合适的方式。
CPU密集型和IO密集型任务必须拆开
一个线程池既跑JSON解析（CPU型），又跑HTTP调用（IO型），结果就是快的被慢的拖死。实测中，混合型任务不隔离，吞吐常下降40%以上。
- CPU密集型任务：如加解密、图像缩放、复杂计算，线程数设为 Runtime.getRuntime().availableProcessors() + 1～2 即可，再多只会加剧上下文切换
- IO密集型任务：如远程API调用、DB查询、文件读写，线程数建议从 核心数 × 3 开始压测，上限一般不超过 ×8；更推荐配合异步IO（如CompletableFuture + OkHttp异步客户端）降低对线程的依赖
- 混合型接口：在Spring中用不同@Qualifier注入对应线程池，比如computeExecutor 和 ioExecutor，业务逻辑里明确指定执行器
自定义ThreadPoolExecutor代替Executors工厂方法
newFixedThreadPool 和 newCachedThreadPool 看似方便，但生产环境极易引发OOM或线程爆炸。它们的问题不是功能缺失，而是默认配置“太宽容”。
- 必须显式使用 ThreadPoolExecutor 构造，控制核心参数：corePoolSize、maxPoolSize、keepAliveTime、有界队列（如ArrayBlockingQueue(200)）
- 拒绝策略别用默认的AbortPolicy，改用 CallerRunsPolicy（让调用线程自己执行）或自定义策略（记录日志+降级返回），避免任务无声丢失
- 线程工厂建议命名，例如命名为 "io-pool-%d"，便于监控和排查线程归属
用CompletableFuture做真正的异步编排
单纯submit Runnable不算异步优化——它只是把阻塞从主线程挪到工作线程。真正提升吞吐的是并行发起+非阻塞组合。
立即学习“Java免费学习笔记（深入）”；
- 把串行调用：res1 = callA(); res2 = callB(); return merge(res1, res2); 改成并行：CompletableFuture.allOf(futA, futB).join()
- 绝不在线程池任务里调用 get() 或 join()，改用 thenApply/thenAccept/exceptionally 做回调处理
- Spring MVC中可直接返回 CompletableFuture
，框架自动异步处理，减少Web容器线程占用
配套措施不能少：监控、降级、超时
异步化后系统更“快”，但也更“黑盒”。没有可观测性，等于在高速路上闭眼开车。
- 暴露线程池指标：活跃线程数、队列积压量、拒绝任务数（可用Micrometer + Prometheus采集）
- 所有远程调用必须设超时，HTTP用connect/read timeout，数据库用queryTimeout，避免单个慢请求拖垮整个池
- 关键路径加入熔断降级（如Sentinel或Resilience4j），当IO线程池拒绝率持续超10%，自动切到缓存或空响应
