核心线程数须依任务类型计算：cpu密集型取逻辑核数+1且禁用动态扩容；i/o密集型按等待占比或qps×耗时估算并预留缓冲；混合型必须分池隔离；同时需兼顾内存与有界队列限制。
核心线程数不能靠经验或拍脑袋定，得按任务行为特征来算。CPU 密集型和 I/O 密集型的资源瓶颈完全不同：前者卡在 CPU 计算能力，后者卡在等待响应的时间。用错公式，轻则吞吐上不去，重则线程堆积、OOM 或下游雪崩。
CPU 密集型：核数 +1 是有依据的底线
这类任务几乎不等外部资源，比如加解密、图像缩放、数值模拟、JSON 序列化高峰段。CPU 持续满负荷，线程再多也抢不到额外计算周期。
- 基础值 = Runtime.getRuntime().availableProcessors()，即逻辑核心数（含超线程）
- 加 1 是为应对短暂阻塞：缺页中断、Stop-The-World GC、TLB miss 等非计算停顿，留一个线程顶上，避免 CPU 周期空转
- maximumPoolSize 建议与 corePoolSize 相同，禁用动态扩容——CPU 型任务不需要“突发弹性”，反而会因上下文切换拖慢整体延迟
I/O 密集型：看“等待占比”，不是翻倍就完事
HTTP 调用、DB 查询、文件读写，真正占用 CPU 的可能只有几毫秒，其余时间都在等网卡收包、磁盘寻道或远程服务返回。此时线程数本质是在“填补等待空隙”。
- 理论公式：corePoolSize ≈ CPU 核数 × (1 + 平均等待时间 / 平均 CPU 工作时间)
- 更实用的做法：用 峰值 QPS × 平均单次 I/O 耗时（秒） 得到瞬时并发连接数，再加 20%～50% 缓冲
- 必须同步检查下游瓶颈：DB 连接池上限、OkHttp 最大路由连接数、Nginx worker_connections、甚至对方服务的限流阈值——线程开再多，卡在连接池里等于白搭
混合型任务：分池隔离比硬凑一个池靠谱十倍
一个接口既做 AES 解密（CPU 型），又查三次 MySQL（I/O 型），如果共用一个线程池，结果往往是：CPU 型任务排队等线程，I/O 型任务又因线程不足堆积在队列里，互相拖垮。
- 优先按主责拆分：计算类走 CPU 优化池（core = 核数 + 1），远程调用走 IO 优化池（core = 核数 × 2～4）
- 调用时显式指定执行器：
CompletableFuture.supplyAsync(task, ioExecutor)，别依赖ForkJoinPool.commonPool() - 若真无法拆分，保守按 I/O 型配，但必须监控
getActiveCount()和getQueue().size()—— 持续高位说明 CPU 型任务已开始饿死
别忘了内存和队列：参数配错，公式再准也白搭
线程本身吃内存（每个线程栈默认 1MB），堆外内存、连接句柄、文件描述符都受系统限制。
- 可结合内存反推上限：比如最大堆 4G，预估每线程占 8MB，则内存允许线程数 ≈ 4096 ÷ 8 × 0.6 ≈ 300（留 40% 给其他开销）
- 队列必须有界：用
LinkedBlockingQueue(1000)或ArrayBlockingQueue(2000)，拒绝策略选AbortPolicy（快速失败）或CallerRunsPolicy（回压到调用方） - 禁用无界队列：
LinkedBlockingQueue()默认容量是Integer.MAX_VALUE，等于变相禁用maxPoolSize，所有任务全进队列，最终 OOM
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
