最有效方式是用两个独立线程池物理隔离冷热数据任务：CPU密集型池配SynchronousQueue与核数线程，IO密集型池配LinkedBlockingQueue与2–4倍核数核心线程，并通过显式@Async绑定或独立Executor实例实现代码层隔离。
直接用两个独立线程池，而不是一个“万能”线程池，是解决冷热数据混跑导致性能抖动最有效的方式。“冷数据”对应 CPU 密集型任务（持续占满 CPU），而“热数据”对应 IO 密集型任务（频繁等待、CPU 空闲）。混在一起跑，IO 任务卡住线程会让计算任务饿死，计算任务压满 CPU 又会让 IO 任务无法及时调度——这不是参数调优能绕开的问题，必须隔离。
为什么必须物理隔离？
核心矛盾在于线程行为不可调和：
- CPU 密集型任务线程几乎不阻塞，长期占用 CPU，线程数稍多就引发严重上下文切换开销
- IO 密集型任务线程大部分时间在 WAITING（如 SocketRead、JDBC wait），真正 CPU 工作占比可能不足 5%，需要更多线程“填满”等待间隙
- 共用一个线程池时，即使设置了大 corePoolSize，IO 任务堆积会耗尽所有线程，导致 CPU 任务排队进队列；而队列又可能撑爆内存或触发拒绝策略，形成雪崩
两个线程池怎么配？关键不是数字，而是逻辑边界
配置要从任务特征反推，不是套公式：
- CPU 密集型池：corePoolSize = Runtime.getRuntime().availableProcessors()，maximumPoolSize 相同，keepAliveTime 可设为 0（不扩容），workQueue 用 SynchronousQueue（拒绝扩容，强制立即执行或拒绝）
- IO 密集型池：corePoolSize 建议为 CPU 核数 × 2～4，maximumPoolSize 可设为 CPU 核数 × 8～16（留弹性），keepAliveTime 设为 60 秒，workQueue 用 LinkedBlockingQueue（容量建议 100～1000，避免无限堆积）
- 两个池的 threadFactory 必须命名区分，例如 “cpu-pool-%d” 和 “io-pool-%d”，便于日志追踪和监控定位
代码层如何真正隔离？不能只靠 @Async
Spring 的 @Async 默认走同一个线程池，必须显式绑定：
- 定义两个 Bean：@Bean("cpuTaskExecutor") ThreadPoolTaskExecutor 和 @Bean("ioTaskExecutor") ThreadPoolTaskExecutor
- 异步方法上标注：@Async("cpuTaskExecutor") void doHeavyCalc() 和 @Async("ioTaskExecutor") void fetchRemoteData()
- 非 Spring 环境（如纯 Java），直接 new ThreadPoolExecutor 实例，不同任务 submit 到不同实例，禁止复用
别忽略拒绝策略和监控埋点
隔离后仍需防御性设计：
- CPU 池建议用 AbortPolicy（快速失败），因为计算任务延迟敏感，排队不如重试或降级
- IO 池建议用 CallerRunsPolicy（由调用线程自己执行），避免丢请求，尤其对下游稳定性要求高的场景
- 两个池都要暴露 Actuator 端点或接入 Micrometer，重点关注 activeCount、queueSize、completedTaskCount，发现某池长期满负荷就要检查任务是否误入
