Java线程池配置中的几个实际问题

在 Java 服务中，线程池通常用于隔离任务、控制并发量。不过，使用 Executors.newFixedThreadPool() 创建线程池虽然方便，它内部使用无界队列。任务提交速度持续高于处理速度时，队列可能不断增长，最终占用大量内存。因此，生产环境更适合根据业务特点显式创建 ThreadPoolExecutor。

线程池的任务调度顺序容易被忽略：线程数未达到核心线程数时，优先创建线程；达到核心线程数后，优先向队列提交任务；队列满了，才继续创建线程，直到最大线程数。由此可见，如果配置的是无界队列，最大线程数通常不会发挥作用。队列容量应结合任务耗时和系统承载能力设置，避免任务无限堆积。

拒绝策略也需要与业务语义匹配。AbortPolicy 会抛出异常，适合希望调用方明确感知失败的场景；CallerRunsPolicy 会让提交任务的线程自行执行任务，可以降低提交速度，但也可能拖慢请求线程。对不能丢失的任务，不应简单采用丢弃策略，而应考虑持久化、重试或消息队列等机制。

线程池关闭时，shutdown() 会停止接收新任务，并等待已提交任务完成；shutdownNow() 则会尝试中断正在执行的任务，并返回尚未开始的任务。由于中断只是协作式通知，任务代码需要正确处理中断信号。服务停止时可以先调用 shutdown()，再通过 awaitTermination() 等待一段时间，超时后再执行强制关闭。

线程池是否配置合理，不能只看线程数。队列长度、活跃线程数、任务等待时间和拒绝次数同样值得监控。结合这些指标观察一段时间，再调整核心线程数、最大线程数和队列容量，通常比依赖固定公式更可靠。