cpu密集型设核心线程数为cpu核心数+1、最大线程数与之相等，避免上下文切换；io密集型核心线程数取cpu核心数×2～4、最大线程数×6～8并配大容量有界队列；混合型优先拆分任务或监控调优。
核心线程数和最大线程数不能凭感觉设，得看任务在忙什么、机器有多少资源、系统要稳还是要快。
CPU 密集型任务怎么设
这类任务几乎不等外部响应，比如图像压缩、数值计算、加密解密。CPU 一直满负荷，多开线程只会换来频繁切换，拖慢整体速度。
- 核心线程数建议设为 CPU 核心数 + 1（例如 8 核机器设为 9），多出的 1 个用来应对轻微阻塞（如页缺失）
- 最大线程数通常与核心数一致，避免扩容带来额外开销
- 队列推荐用
SynchronousQueue或小容量ArrayBlockingQueue，不希望任务排队，更不想盲目扩线程
IO 密集型任务怎么设
数据库查询、HTTP 调用、文件上传这些操作，线程大部分时间在等网络或磁盘响应，CPU 反而空着。这时可以多放些线程，把空闲 CPU 利用起来。
- 核心线程数常用 CPU 核心数 × 2～4（例如 4 核可设 8～16）
- 最大线程数可放宽到 CPU 核心数 × 6～8，但必须搭配有界队列（如容量 50～200 的
ArrayBlockingQueue），否则容易雪崩 - 如果等待时间远大于计算时间（比如一次 DB 查询耗时 200ms，其中只有 5ms 在计算），可用公式粗估：核心线程数 ≈ CPU 核数 × (1 + 等待时间 / 计算时间)
混合型任务怎么办
现实中多数服务既做计算又发远程调用，强行统一配一个线程池，参数很难兼顾。硬凑出来的数字往往一边压不住并发，一边又浪费资源。
- 优先拆分：DB 操作、缓存刷新、日志上报、消息投递等，各自走专用线程池
- 拆不了就监控驱动调优：上线后观察
getActiveCount()、getQueue().size()、拒绝率、平均响应时间，再小幅调整 - 混合场景经验参考：核心线程数取 CPU 核数 × 1.5，最大线程数取 × 3，队列容量按 峰值 TPS × 平均耗时（秒） 估算
动态调整要注意什么
只有 ThreadPoolExecutor 实例（或 Spring 的 ThreadPoolTaskExecutor）支持运行时修改；Executors.newFixedThreadPool() 这类工具方法返回的不行。
-
setCorePoolSize()和setMaximumPoolSize()都立即生效，但不会中断正在执行的任务 - 调大时，空闲线程可能被复用，新任务会触发创建；调小时，超出部分的空闲线程会在下次空闲时退出
- 最大线程数不能小于当前核心线程数，且调小后若实际线程数超限，只回收空闲线程
- 别高频抖动调整——每分钟改几次，线程启停开销反而压垮系统
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
