生产环境必须手动用ThreadPoolExecutor构造函数配置线程池
直接使用 ThreadPoolExecutor 构造函数手动配置，而不是依赖 Executors 工厂方法——这可以说是生产环境唯一可控、可审计且可调优的方式。为什么这么说？我们往下看。
为什么不能用 Executors.newFixedThreadPool 等工厂方法
这些工厂方法的问题在于，它们隐藏了关键的参数细节。更麻烦的是，它们默认使用 LinkedBlockingQueue，其容量高达 Integer.MAX_VALUE。这直接导致 maximumPoolSize 这个参数完全失效。一旦任务提交的速率持续高于消费速率，队列就会无限堆积，最终触发令人头疼的 OOM。
newCachedThreadPool：核心线程数为 0，maximumPoolSize是Integer.MAX_VALUE，空闲线程keepAliveTime = 60L秒。在高并发场景下，它可能瞬间创建数千个线程，轻松打满系统句柄和 CPU 资源。newSingleThreadExecutor：看起来安全，但底层的队列依然是那个无界的LinkedBlockingQueue。一旦某个异常任务卡住了这个唯一的线程，后续所有任务都将陷入永久阻塞。- 所有工厂方法均未指定
ThreadFactory和RejectedExecutionHandler。这意味着你无法追踪线程的来源，也无法感知任务被拒绝的事件，系统变得不透明。
corePoolSize 和 maximumPoolSize 的真实约束关系
这两个参数只有在搭配有界队列时，才能形成有效的制衡关系。如果使用了无界队列，maximumPoolSize 就形同虚设了。
- CPU 密集型任务：
corePoolSize推荐设为Runtime.getRuntime().a vailableProcessors()，maximumPoolSize可以与之相等，或者增加 1 到 2 个（以防个别线程意外卡死）。 - IO 密集型任务：可以用一个公式粗略估算：
corePoolSize ≈ CPU 核数 × (1 + 平均等待时间 / 平均工作时间)。然后，将maximumPoolSize设为corePoolSize × 2～4。不过，这只是一个起点，最终值必须结合实际的压测结果来验证。 - 绝对要避免
maximumPoolSize = Integer.MAX_VALUE：JVM 进程能创建的线程数受限于系统的ulimit -u和堆外内存，超出限制就会抛出OutOfMemoryError: unable to create native thread错误。
workQueue 类型决定线程池是“排队优先”还是“扩容优先”
选错了队列类型，就等于把流量控制权交给了不可控的链表或者系统调度器。
ArrayBlockingQueue：有界、基于数组、使用公平锁 —— 这是生产环境的首选。容量需要明确设置（例如 100 或 200），它会配合maximumPoolSize来触发线程池的扩容逻辑。SynchronousQueue：无缓冲，每个offer()操作必须有一个对应的线程正在poll()—— 适合低延迟、高突发的场景（比如实时风控）。但这就要求corePoolSize足够大，否则任务会直接被拒绝。LinkedBlockingQueue：慎用！ 它的默认构造就是无界的。如果确实要用，必须显式传入容量：new LinkedBlockingQueue(200)。PriorityBlockingQueue：无界、不保证公平性、插入/取数时间复杂度为 O(log n) —— 仅当业务逻辑强依赖任务优先级，并且能接受由此带来的吞吐量下降时，才考虑选用。
拒绝策略和 keepAliveTime 的联动陷阱
很多人只关注修改 handler（拒绝策略），却忽略了 keepAliveTime 这个参数。设置不当，它会让拒绝提前发生，或者让问题延后暴露。
keepAliveTime过短（例如 10ms）：非核心线程刚创建好就被销毁，导致线程池反复进行创建和销毁操作，不仅增加 GC 压力，还会频繁抛出RejectedExecutionException。keepAliveTime过长（例如 30 分钟）：流量峰值过后，大量空闲线程会长时间滞留，持续占用堆外内存和操作系统线程句柄，监控上会看到线程数居高不下。AbortPolicy（默认策略）只是在日志里抛出异常，如果上游调用方没有捕获，任务就会静默丢失。更好的做法是自定义RejectedExecutionHandler，至少记录下command.toString()和System.currentTimeMillis()。- 如果启用了
allowCoreThreadTimeOut(true)，那么keepAliveTime将对所有线程生效。此时务必确保keepAliveTime不小于 10 秒，以避免核心线程集体“闪退”的尴尬局面。
最后，必须强调一个最容易被忽略的关键点：所有这些参数都不是孤立配置的。corePoolSize、workQueue 容量、maximumPoolSize 共同构成了一个“三角约束”。举个例子，如果 core=5、queue=100、max=10，那就意味着系统最多只允许 105 个任务积压；超过这个数，任务就会被拒绝。这个“105”的数字，必须与你的服务等级协议（SLA，例如要求 99% 的任务在 200ms 内响应）对齐，而不是凭感觉拍脑袋决定的。
