线程池配置需匹配任务特征：过小导致排队延迟，过大引发OOM和上下文切换；应选有界队列、合理设core/maxPoolSize，避免无界队列，优先静态配置并结合监控调优。
线程池太小会导致任务排队严重
当 corePoolSize 或 maximumPoolSize 设置过小（比如固定为 1 或 2），即使 CPU 有多核，大量任务也只能串行执行。尤其在 I/O 密集型场景下，线程常处于 WAITING 或 TIMED_WAITING 状态，但线程池没扩容，新任务只能塞进 workQueue 等待——队列积压、响应延迟飙升，甚至触发拒绝策略。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 监控
ThreadPoolExecutor.getQueue().size()和getActiveCount()，持续非零且增长，说明线程数不足 - 对纯计算任务，
corePoolSize可设为Runtime.getRuntime().availableProcessors() - I/O 密集型（如 HTTP 调用、DB 查询）可适当放大，常见经验值是
2 × CPU核心数到CPU核心数 + 阻塞系数 × CPU核心数，其中阻塞系数 ≈ 平均阻塞时间 / 平均工作时间
线程池太大引发上下文切换和内存开销
盲目调高 maximumPoolSize（例如设为 1000+）会让 JVM 创建大量线程。每个线程默认占用约 1MB 栈空间（可通过 -Xss 调整，但不推荐过小），容易触发 OutOfMemoryError: unable to create new native thread；同时，操作系统频繁调度数百个线程，上下文切换成本剧增，反而拖慢吞吐量。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 避免使用
Executors.newCachedThreadPool()，它不限制maximumPoolSize，高峰时可能创建数千线程 - 用
ThreadPoolExecutor显式构造，明确指定corePoolSize、maximumPoolSize、workQueue容量 - 若需弹性扩容，优先考虑有界队列（如
ArrayBlockingQueue）配合合理的拒绝策略（如AbortPolicy或自定义记录日志的策略），而非无节制扩线程
队列类型和容量比线程数更容易被忽视
很多人只调线程数，却忽略 workQueue 的选择。用 LinkedBlockingQueue 且未指定容量（即默认 Integer.MAX_VALUE），等于把压力从线程池转移到堆内存——任务全缓存住，corePoolSize 永远不会触发扩容，maximumPoolSize 形同虚设。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 高吞吐、低延迟场景：选
SynchronousQueue（无缓冲，直接移交），逼迫线程池快速扩容到maximumPoolSize - 稳态负载、需削峰填谷：用有界
ArrayBlockingQueue，容量建议设为预估峰值 QPS × 平均处理时长（秒） - 绝对不要依赖无界队列掩盖线程数配置问题——它只是把 OOM 延后，且更难定位
动态调整线程池参数需要谨慎
虽然 ThreadPoolExecutor 提供 setCorePoolSize()、setMaximumPoolSize() 等方法，但它们不是“热更新”魔法：增大 corePoolSize 会立即创建空闲线程；减小时，多余线程仅在空闲超 keepAliveTime 后退出——无法立刻释放资源。而且并发修改可能干扰正在运行的任务调度逻辑。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 生产环境优先静态配置，通过压测确定合理值，而非依赖运行时动态调参
- 若真需动态调整（如应对定时大促），应配合指标（如队列长度、活跃线程占比）做平滑变更，并限制调整频次（例如 5 分钟内最多一次）
- 务必重写
beforeExecute/afterExecute记录实际执行耗时与异常，否则调参就像蒙眼开车
getCompletedTaskCount()、队列长度、以及 GC 日志里是否频繁出现线程栈分配失败？ 
