java中自定义threadpoolexecutor需围绕任务类型、并发量、资源限制权衡七大参数：corepoolsize、maximumpoolsize、keepalivetime、unit、workqueue、threadfactory、handler；按场景选队列（linkedblockingqueue适合稳定负载，arrayblockingqueue可控扩容，synchronousqueue低延迟高吞吐）和拒绝策略（生产环境推荐callerrunspolicy）；cpu密集型设core=maximum≈cpu核数+1，io密集型core≈2×cpu核数、maximum适当放大；须自定义threadfactory便于监控，并用shutdown()配合awaittermination()优雅关闭。
Java 中使用 ThreadPoolExecutor 自定义核心线程池参数，关键在于理解七个构造参数的含义，并根据业务场景合理设置。不是简单套用数字，而是围绕“任务类型、并发量、资源限制”做权衡。
明确七个核心构造参数的作用
ThreadPoolExecutor 的完整构造方法如下：
new ThreadPoolExecutor(
corePoolSize, // 核心线程数，常驻不销毁
maximumPoolSize, // 最大线程数，决定线程池容量上限
keepAliveTime, // 非核心线程空闲存活时间
unit, // 时间单位（如 TimeUnit.SECONDS）
workQueue, // 任务队列（如 LinkedBlockingQueue、SynchronousQueue）
threadFactory, // 线程创建工厂（可设名称、是否守护线程）
handler // 拒绝策略（如 AbortPolicy、CallerRunsPolicy）
);
按场景选合适的队列和拒绝策略
队列类型直接影响线程增长逻辑和内存风险：
-
LinkedBlockingQueue：无界队列（默认 Integer.MAX_VALUE），适合任务提交速率稳定、允许排队等待的场景；但容易掩盖问题——线程数始终为
corePoolSize，即使负载升高也不会扩容，可能导致响应延迟堆积 -
ArrayBlockingQueue：有界队列，配合
maximumPoolSize > corePoolSize，可触发线程扩容；需预估容量，避免频繁拒绝 -
SynchronousQueue：不存储任务，每个任务必须立刻被线程消费，适合高吞吐、低延迟场景；会快速触发线程扩容至
maximumPoolSize，对资源压力大
拒绝策略建议：
- 生产环境慎用
AbortPolicy（抛异常），可用DiscardPolicy（静默丢弃）或CallerRunsPolicy（由提交线程自己执行），后者能自然降速，缓解压力
合理设置 corePoolSize 和 maximumPoolSize
没有万能公式，但可参考以下思路：
- CPU 密集型任务（如计算、加解密）：线程数 ≈ CPU 核心数 + 1，避免过多线程争抢 CPU，
corePoolSize = maximumPoolSize即可 - IO 密集型任务（如数据库查询、HTTP 调用）：线程数可设为
corePoolSize = 2 × CPU 核心数，maximumPoolSize可适当放大（如 2–4 倍），应对突发 IO 等待波动 - 混合型任务：观察实际监控（如线程活跃数、队列积压、GC 频率），用
ThreadPoolExecutor提供的getActiveCount()、getQueue().size()等方法动态调优
别忘了线程工厂和优雅关闭
自定义 ThreadFactory 能提升排查效率：
ThreadFactory namedFactory = r -> {
Thread t = new Thread(r, "biz-task-pool-" + counter.getAndIncrement());
t.setDaemon(false); // 非守护线程，避免 JVM 提前退出
return t;
};
关闭线程池时，优先调用 shutdown()（不再接受新任务，等已有任务结束），必要时再调用 shutdownNow()（尝试中断运行中任务）；建议配合 awaitTermination() 等待完成，避免资源泄漏。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
