Java线程池需合理配置参数、队列与拒绝策略：计算密集型设corePoolSize≈CPU核数，I/O密集型可设2–4倍核数并配有界队列；禁用newFixedThreadPool和newCachedThreadPool；优先手动构建ThreadPoolExecutor，选用ArrayBlockingQueue和CallerRunsPolicy等策略。
Java线程池是并发编程中最常用也最容易出问题的组件之一。它不是“开了就能用”的黑盒，配置不当反而会放大并发风险——比如任务堆积引发内存溢出、线程争抢导致响应延迟、拒绝策略误用造成业务丢失。关键在于理解线程池各参数的协作逻辑，以及它们在真实场景中的行为边界。
线程池核心参数失配
线程池性能问题往往源于参数与业务类型不匹配。计算密集型任务（如加解密、图像处理）应设 corePoolSize ≈ CPU 核数，避免过多线程争抢 CPU；而 I/O 密集型任务（如数据库查询、HTTP 调用）因大量等待时间，可适当提高 corePoolSize（例如 2–4 倍核数），但需配合有界队列控制资源占用。
- 避免使用
newFixedThreadPool：它底层用无界LinkedBlockingQueue，任务持续涌入时会无限堆积，最终触发 OOM。 - 慎用
newCachedThreadPool：最大线程数为 Integer.MAX_VALUE，突发流量下可能创建海量线程，耗尽系统资源。 - 推荐手动构建
ThreadPoolExecutor，明确指定有界队列（如ArrayBlockingQueue(1024)）和拒绝策略（如CallerRunsPolicy，让调用线程自己执行，起到自然限流作用）。
任务队列与拒绝策略误用
队列类型直接决定线程池的响应行为和稳定性。无界队列看似“容错”，实则掩盖背压；同步队列（SynchronousQueue）虽能避免排队，但要求必须有空闲线程承接任务，否则立即触发拒绝策略。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 高一致性要求场景（如支付扣款）：选用有界队列 +
AbortPolicy，失败即报错，便于快速发现容量瓶颈。 - 高吞吐容忍丢弃场景（如日志采集）：可用
DiscardPolicy或自定义策略，静默丢弃非关键任务。 - 需保障任务不丢失场景（如订单创建）：配合
CallerRunsPolicy，由业务线程兜底执行，但要注意该策略可能拖慢上游调用链。
线程安全与共享状态隐患
线程池本身不解决任务内部的线程安全问题。多个任务共用同一对象（如静态变量、单例 Bean 中的非 final 字段），或在 Runnable/Callable 中修改外部集合，极易引发竞态条件或数据污染。
立即学习“Java免费学习笔记（深入）”；
- 任务类尽量设计为无状态：所有依赖通过参数传入，避免闭包捕获可变引用。
- 确需共享状态时，优先使用
ConcurrentHashMap、AtomicInteger等线程安全类型，而非对HashMap或普通 int 加 synchronized。 - 禁止在任务中直接操作 ServletRequest、Session 等容器管理对象——它们不具备跨线程安全性。
资源泄漏与生命周期失控
线程池未正确关闭、任务未释放连接或文件句柄、异步回调未清理监听器，都会导致资源缓慢泄漏，尤其在长期运行的服务中后果严重。
- 使用
try-with-resources或显式close()确保数据库连接、HTTP 客户端、流等资源释放。 - 在线程池 shutdown 后，调用
awaitTermination()等待任务结束，并检查isTerminated()状态，必要时调用shutdownNow()强制中断。 - 避免在任务中启动新线程或注册全局监听器，除非明确管理其生命周期。
