线程池大小不能简单设为CPU核心数+1，需根据任务类型与平均等待时间占比确定：CPU密集型≈核心数，混合型=核心数×(1+等待时间/工作时间)，高I/O型需结合连接池与熔断。
线程池大小设为 CPU 核心数 + 1 就对了吗？
不对。这个常见经验公式只适用于纯 CPU 密集型、无阻塞的计算任务，而现实中绝大多数 Java 服务（如 Web 接口、数据库访问、RPC 调用）都涉及 I/O 阻塞。盲目套用会导致线程饥饿或资源浪费。
真正决定线程池大小的关键是：任务类型 + 平均等待时间占比。你需要估算一个任务中 CPU 计算耗时与阻塞耗时（如网络响应、磁盘读写、锁竞争）的比例。
- CPU 密集型（如图像处理、加密解密）：线程数 ≈
Runtime.getRuntime().availableProcessors()，最多 +1 防止偶发上下文切换损失 - 混合型（典型 Spring Boot 服务）：推荐用公式
corePoolSize = CPU核心数 × (1 + 平均等待时间 / 平均工作时间)，例如 DB 查询平均等 200ms、计算耗 50ms，则乘数为 1 + 200/50 = 5 → 线程数 ≈ 核心数 × 5 - 高度 I/O 阻塞（如大量 HTTP 调用）：可能需要几十甚至上百，但必须配合连接池、超时和熔断，否则只是把问题转移到下游或触发 OOM
为什么 Executors.newFixedThreadPool(200) 是危险操作？
它创建的是无界队列 + 固定线程数的线程池，看似可控，实则隐藏两个致命问题：
- 当任务提交速率持续高于消费速率，
LinkedBlockingQueue（默认容量Integer.MAX_VALUE）会无限堆积任务，最终吃光堆内存，触发OutOfMemoryError: GC overhead limit exceeded - 所有 200 个线程一旦因慢 SQL、第三方接口卡住，整个池就失去弹性；新请求要么排队等死，要么被拒绝，且无法区分优先级
- 没有显式命名线程工厂，线程名全是
pool-1-thread-1这类，线上排查Thread Dump时根本分不清哪个池在干啥
正确做法是：用 ThreadPoolExecutor 手动构造，明确设置 queueCapacity、rejectedExecutionHandler，并传入带业务前缀的 ThreadFactory。
立即学习“Java免费学习笔记（深入）”；
如何根据压测结果反推最优 corePoolSize？
不要靠猜，要靠观测。在稳定流量下用 jstack 或 Arthas 的 thread 命令采样，重点关注三组数据：
-
getActiveCount()：当前活跃线程数。若长期接近corePoolSize，说明可能不足；若长期低于 30%，说明可能过大 -
getQueue().size()：队列积压量。非零且持续增长，是扩容或加限流的强信号 -
getCompletedTaskCount() / uptimeSeconds：实际吞吐率。结合平均响应时间，可反推理论最小并发需求
示例：压测中发现 activeCount = 12，queue.size = 84，平均 RT = 1.2s，QPS = 60 → 理论并发需 ≈ 60 × 1.2 = 72，说明 corePoolSize 至少调到 32～48，并配合理想队列长度（如 200）和 CallerRunsPolicy 拒绝策略。
CompletableFuture 默认使用 ForkJoinPool.commonPool() 有什么隐患？
这是最容易被忽视的“隐形线程池”。它的并行度默认为 Runtime.getRuntime().availableProcessors() - 1（至少为 2），且全局共享、不可配置。
- 如果任意一个业务代码用了
supplyAsync(() -> {...})且内部含阻塞调用（如Thread.sleep、JDBC 查询），就会拖慢所有其他用到commonPool的地方（比如 JSON 序列化、日志异步刷盘） - Spring 6+ 的
@Async默认也走这里（除非显式配置taskExecutor），导致不同模块相互干扰 - 无法设置拒绝策略、队列容量、线程命名，出问题后
Thread Dump里只能看到ForkJoinWorkerThread，定位困难
解决方式很简单：所有阻塞操作，强制指定自定义线程池，例如 supplyAsync(() -> db.query(), customIoPool)；非阻塞计算才放心交给 commonPool。
复杂点往往不在公式本身，而在你是否清楚每个任务真实花时间的地方——是 CPU、网络、锁，还是 GC。不看监控、不采样、不区分场景地调数字，和闭眼调参没区别。
