Java线程池并发控制需围绕任务进入、线程配置、队列选型、超限拦截四方面设计：CPU密集型设corePoolSize≈CPU核数+1，IO密集型可设为CPU核数×(2～8)；优先选用有界队列如ArrayBlockingQueue，慎用无界LinkedBlockingQueue；拒绝策略应体现系统承压边界，如AbortPolicy快速失败、CallerRunsPolicy反压降速；执行方式依业务选CompletableFuture编排、链式异步或execute提交。
Java线程池的任务并发执行控制，核心在于“任务怎么进、线程怎么配、队列怎么用、超限怎么拦”。它不是简单开个线程池就完事，而是要根据业务特征（CPU密集 or IO密集）、吞吐要求、资源约束和失败容忍度，做有针对性的配置与策略选择。
线程数量配置：看任务类型，别硬套公式
核心线程数（corePoolSize）和最大线程数（maximumPoolSize）不能拍脑袋定。关键看任务性质：
- CPU密集型任务（如大量计算、图像处理）：线程数建议设为 CPU核心数 + 1，避免过多线程争抢CPU导致上下文切换开销过大
- IO密集型任务（如HTTP调用、数据库查询、文件读写）：线程数可适当放大，常见做法是 CPU核心数 × (2～8)，因为线程常处于等待状态，多些线程能提升CPU利用率
- 混合型任务：建议压测验证——用监控工具（如JMC、Arthas）观察线程活跃率、CPU使用率、GC频率，动态调整
任务队列选型：有界优先，慎用无界
队列类型直接影响线程池行为和系统稳定性：
- ArrayBlockingQueue（有界数组队列）：容量固定，内存占用可控；当队列满时触发扩容或拒绝策略，适合对资源敏感、需强控并发量的场景
-
LinkedBlockingQueue（链表队列，默认无界）：插入快、吞吐高，但若任务提交速度长期高于消费速度，会导致队列无限堆积，最终OOM；如必须用，建议显式指定容量（如
new LinkedBlockingQueue(1024)） -
SynchronousQueue（同步移交队列）：不存储任务，每个任务必须立刻被线程取走；配合
maximumPoolSize较大时，可实现“来一个活儿，马上拉新线程干”，适合响应延迟敏感、任务突发性强的场景
拒绝策略设计：不是兜底，而是决策信号
拒绝策略不是“出错了随便抛个异常”，而是系统承压能力的明确边界表达：
立即学习“Java免费学习笔记（深入）”；
-
AbortPolicy（默认）：直接抛
RejectedExecutionException，适合不允许任务丢失、需快速失败并告警的场景 - CallerRunsPolicy：由提交任务的线程（比如主线程）自己执行该任务，会降低提交速率，起到反压作用，适合防止雪崩、允许短暂降级的系统
- DiscardPolicy：静默丢弃，无日志无提示，仅适用于可丢失、低优先级任务（如埋点上报）
- DiscardOldestPolicy：丢弃队列头部最老任务，腾出空间接纳新任务，适合任务有时效性（如实时行情推送）
执行方式选择：同步阻塞 vs 异步编排
控制“并发执行”不等于只靠线程池参数，任务提交后的协调逻辑同样关键：
- 需要等全部完成再统一返回结果 → 用 CompletableFuture.allOf() 编排异步任务，支持超时控制（
get(timeout, unit)）和异常聚合 - 任务间有依赖或需按序处理部分环节 → 结合 thenApply/thenCompose 实现链式异步流，避免阻塞主线程
- 纯粹追求“发出去就不管” → 直接用
executor.execute()，但务必确保任务内有完备异常捕获，否则异常会静默吞掉 - 绝对不允许任务丢失且必须顺序执行 → 不适合用线程池并发，应考虑消息队列+单消费者模型
