线程池大小需据任务类型校准：CPU密集型取核心数+1，I/O密集型按等待占比放大，上限受内存与上下文切换制约，最终须压测验证。
线程池大小不能拍脑袋定，得看任务在 CPU 上“忙”还是“等”。CPU 核心数是起点，不是终点——它告诉你硬件最多能并行跑几个纯计算线程，但真实业务里线程常被 I/O、锁、GC 拖住。所以核心数只是基准，关键在结合任务行为做校准。
CPU 密集型任务：核心数 + 1 是稳妥选择
这类任务几乎不等待，比如矩阵运算、视频转码、加解密。每个线程会持续占用一个 CPU 核心。线程数超过核心数，只会增加上下文切换开销，降低吞吐量。
- 推荐公式：corePoolSize = Runtime.getRuntime().availableProcessors() + 1
- 多出的 1 个线程，用来兜底应对偶尔的阻塞（如页缺失、轻量系统调用），避免 CPU 空转
- maximumPoolSize 通常设为与 corePoolSize 相同，因为没必要动态扩容——任务本身已占满算力
I/O 密集型任务：按“等待占比”放大核心数
数据库查询、HTTP 调用、文件读写……线程大部分时间在等响应。此时 CPU 是空闲的，可以塞更多线程进去“填坑”。
- 基础经验公式：corePoolSize ≈ CPU 核心数 × 2 ～ 4
- 更精准的估算：CPU 核心数 × (1 + 平均等待时间 ÷ 平均 CPU 计算时间)
- 例如：4 核机器，一次请求平均等 80ms、计算只花 20ms → 4 × (1 + 80/20) = 20 个核心线程
- maximumPoolSize 可设为 corePoolSize 的 2 倍左右，配合有界队列防雪崩
别光看核心数，还得卡住资源底线
就算公式算出 200 个线程，也得看机器扛不扛得住。
立即学习“Java免费学习笔记（深入）”；
- 每个线程默认栈空间约 1MB（可通过 -Xss 调整），4GB 可用堆外内存，实际线程上限≈ 4000；但通常远达不到这个数就因上下文切换拖垮了
- 用 Runtime.getRuntime().availableProcessors() 获取核心数，注意它返回的是逻辑核数（含超线程），对 CPU 密集型任务可视为有效并行单元
- 如果机器还跑着数据库、中间件等其他服务，要预留 20%～30% CPU 和内存余量，别把线程池设成“独食者”
最终得靠压测验证，不是靠公式定案
公式给的是初始值，真实最优值藏在监控数据里：
- 观察 活跃线程数 是否长期接近 corePoolSize（偏低说明线程过剩，偏高说明可能不足）
- 检查 任务队列长度 是否持续增长（说明处理不过来，需扩容或优化单任务耗时）
- 盯紧 CPU 使用率 和 GC 频率：CPU 不到 70% 但响应慢，可能是 I/O 瓶颈；GC 暴增，说明线程太多导致内存压力大
