Java线程池需手动构造ThreadPoolExecutor并合理设置7个参数，避免用Executors工具类引发OOM或资源耗尽；核心参数包括corePoolSize、maximumPoolSize、keepAliveTime、unit、workQueue、threadFactory和handler，生产环境推荐有界队列、自定义线程工厂及CallerRunsPolicy拒绝策略。
Java线程池不是“随便 new 一个就完事”，关键在 合理设置参数，否则容易内存溢出、任务堆积或资源浪费。核心是用 ThreadPoolExecutor 构造器，而不是只依赖 Executors 工具类（它封装太死，隐藏风险）。
线程池核心7个参数怎么设
构造 ThreadPoolExecutor 需要7个参数，缺一不可，每个都影响运行行为：
-
corePoolSize：常驻线程数。即使空闲也不被回收（除非设置了
allowCoreThreadTimeOut(true)）。建议设为「CPU核数 + 1」（CPU密集型），或「CPU核数 × (1 + 平均等待时间/平均执行时间)」（IO密集型） - maximumPoolSize：最大线程数。当队列满且已有线程都在忙时，才创建新线程，直到达到此值。一般不超过 CPU 核数的 2–4 倍，避免上下文切换开销过大
- keepAliveTime：非核心线程空闲后最多存活多久。设为 60L、TimeUnit.SECONDS 比较常见
-
unit：keepAliveTime 的时间单位，如
TimeUnit.SECONDS -
workQueue：任务等待队列。慎用
LinkedBlockingQueue（无界）——它会导致 OOM；优先选ArrayBlockingQueue（有界，指定容量，比如 100–1000）或SynchronousQueue（不存储任务，适合直接移交，配合 cached 策略） -
threadFactory：线程创建工厂。建议自定义，给线程起名（如
"biz-task-pool-%d"），便于排查日志 -
handler：拒绝策略。默认
AbortPolicy（抛异常），生产环境建议用CallerRunsPolicy（让调用线程自己执行任务，自然降速）或自定义记录告警
一个安全可用的创建示例
以下是一个贴近生产场景的写法（Spring 环境下可声明为 @Bean）：
ThreadPoolExecutor executor = new ThreadPoolExecutor(
4, // core: 4 核机器，CPU 密集型任务
8, // max: 允许短时突发
60L, // keep-alive: 60秒
TimeUnit.SECONDS,
new ArrayBlockingQueue<>(200), // 有界队列，防无限堆积
new ThreadFactoryBuilder().setNameFormat("order-process-pool-%d").build(),
new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝时由业务线程兜底
);
注意：ThreadFactoryBuilder 来自 Guava，若不用 Guava，可手写简单实现；拒绝策略别用 DiscardPolicy（静默丢任务）——线上基本等于丢数据。
立即学习“Java免费学习笔记（深入）”；
Executors 工具类为什么尽量少用
Executors.newFixedThreadPool(5) 看似方便，但它内部用了 LinkedBlockingQueue（无界），一旦任务提交速度 > 处理速度，队列会无限增长，最终 OutOfMemoryError。同理，newCachedThreadPool() 的最大线程数是 Integer.MAX_VALUE，高并发下可能创建海量线程，压垮系统。所以——
- 开发阶段可以快速验证逻辑，但上线前必须替换成手动构造的
ThreadPoolExecutor - 所有线程池建议统一管理（如 Spring Bean），避免散落在各处，造成参数混乱或泄漏
几个容易忽略但关键的细节
- 线程池不是用完就扔，务必在应用关闭时调用
shutdown()+awaitTermination()，确保任务执行完再退出 - 不要在线程池里执行阻塞操作（如没设超时的远程调用、数据库查询），否则会把线程卡死，拖垮整个池
- 监控很重要：可通过
getActiveCount()、getQueue().size()、getCompletedTaskCount()等方法暴露指标，接入 Prometheus 或日志告警 - 不同业务场景建议隔离线程池（如支付、通知、日志各用一个），避免互相影响
基本上就这些。参数没有标准答案，得结合你的机器配置、任务类型（CPU/IO）、QPS 和失败容忍度来调。先按推荐值起步，再靠监控和压测微调。
