Java线程池参数需依任务特征权衡配置：corePoolSize设为CPU核数的2~4倍（IO型）或±1（CPU型）；maximumPoolSize仅在有界队列满时生效；keepAliveTime控制超量线程存活时长；workQueue类型决定缓冲与拒绝行为；threadFactory应命名线程，handler需按业务选拒绝策略。
Java线程池的参数配置不是套公式，而是根据实际任务特征做权衡。核心在于理解每个参数的含义和相互影响，而不是盲目调大或调小。
corePoolSize：常驻线程的“底线”
这是线程池中长期存活的最小线程数。即使没有任务，这些线程也会保持活跃（除非设置了allowCoreThreadTimeOut(true)）。它决定了系统空闲时的资源占用下限。
- IO密集型任务（如数据库查询、HTTP调用）可设为 CPU核数 × (1 + 平均等待时间/平均工作时间)，常见值是核数的2~4倍
- CPU密集型任务建议设为 CPU核数 ± 1，避免过多线程导致上下文切换开销
- 过小会导致任务排队或频繁创建新线程；过大则浪费内存和调度资源
maximumPoolSize：线程数量的“天花板”
当任务持续涌入、队列已满时，线程池最多可扩展到的线程总数。它只在使用有界队列（如ArrayBlockingQueue）且队列满后才可能被触发。
- 如果用的是无界队列（如LinkedBlockingQueue默认容量Integer.MAX_VALUE），这个值基本无效——因为队列永远不会满，线程数永远不超过corePoolSize
- 设置过大会加剧竞争，可能拖垮JVM；过小会导致大量任务被拒绝（取决于拒绝策略）
- 生产环境建议结合监控数据调整，例如观察高峰时段的活跃线程数和队列积压量
keepAliveTime & unit：空闲线程的“保质期”
超出corePoolSize的线程，在空闲超过该时间后会被回收。单位需配合指定（如TimeUnit.SECONDS）。
- 对突发流量场景，适当延长（如60秒）能让线程多留一会儿，应对后续小高峰
- 对长周期稳定负载，可设短些（如10秒），及时释放资源
- 注意：只有线程数 > corePoolSize 时该参数才起作用
workQueue：任务的“缓冲区”
存放待执行但暂无空闲线程的任务。它的类型和容量直接影响线程扩容时机和拒绝行为。
- SynchronousQueue：不存储任务，直接移交线程。适合高响应要求、任务能快速处理的场景；此时maximumPoolSize必须合理设置，否则容易触发拒绝
-
ArrayBlockingQueue：有界队列。推荐显式指定容量（如200），防止OOM；队列满 + 线程达max
imum → 触发拒绝策略
- LinkedBlockingQueue：默认无界，看似安全，实则隐藏风险——任务持续堆积会吃光堆内存
threadFactory 和 handler：不容忽视的“软性配置”
前者用于自定义线程创建（如命名、设守护线程、加UncaughtExceptionHandler）；后者决定任务被拒绝时怎么处理。
- 务必给线程起有意义的名字（如"order-service-pool-%d"），方便排查问题
- 拒绝策略别只用默认的AbortPolicy（抛异常）。可根据业务选：CallerRunsPolicy（让调用者自己执行）、DiscardOldestPolicy（丢最老的）、或自定义记录日志+告警
- 不要忽略异常处理——未捕获异常会导致线程静默退出，线程池悄悄“缩水”
