线程池优化需匹配业务特征，IO密集型任务应适度放大corePoolSize（如CPU=4时设8～12），启用allowCoreThreadTimeOut；用ArrayBlockingQueue控流（容量为core的2～3倍），拒绝策略优选CallerRunsPolicy；分批处理（如500条/批）并复用数据库连接，异步解耦写库与MQ；必须监控活跃线程、队列积压等指标并告警。
线程池在批量数据导入场景中提升并发吞吐量，关键不是“堆更多线程”，而是让线程、队列、任务划分三者协同匹配业务特征。尤其面对数据库写入、远程调用或文件解析等混合型操作时，盲目增大线程数反而引发连接池耗尽、CPU争抢或GC飙升。
按任务类型定核心线程数
批量导入通常含IO等待（如JDBC写入、HTTP回调）和少量CPU计算（如字段校验、JSON解析），属于典型的IO密集型为主、轻度CPU混合型任务。此时 corePoolSize 不应等于 CPU 核心数，而应适度放大：
- CPU核心数为4时，corePoolSize 可设为 8～12；若平均单条记录处理含500ms以上IO等待，可上探至16
- 避免使用
Runtime.getRuntime().availableProcessors() * 2这类静态公式——需结合压测：观察当线程从8升到12时，DB连接池活跃数是否已达上限、平均响应时间是否下降、线程上下文切换是否陡增 - 启用
allowCoreThreadTimeOut(true)，让低峰期空闲核心线程也能回收，节省内存
用有界队列控流防雪崩
别用无界 LinkedBlockingQueue 接收所有待处理批次——它会让大量任务滞留在内存中，触发Full GC甚至 OOM，且掩盖真实处理瓶颈。
- 推荐
ArrayBlockingQueue，容量设为 2～3 倍核心线程数（例如 core=12 → queue=24） - 队列满后，新批次提交会触发拒绝策略；此时应选
CallerRunsPolicy：由主线程自己执行一个批次，自然降速，避免任务无限堆积 - 若必须保吞吐，可用
SynchronousQueue+ 合理的 maximumPoolSize，实现“来即处理”，但需确保 DB/中间件连接池足够支撑最大并发
分批+异步解耦写入链路
单次提交万级数据易超事务边界或网络包限制，也难控制失败回滚粒度。应将大列表切分为固定大小批次（如 500 条/批），再交由线程池调度：
立即学习“Java免费学习笔记（深入）”；
- 每批次封装为独立 Runnable/Callable，内部完成连接获取→批量插入→异常捕获→日志记录全流程
- 关键点：数据库操作务必复用连接（通过 HikariCP 等连接池），禁止每个批次新建 Connection
- 对强一致性要求不高的场景，可将“写库”与“发MQ通知”分离——先落库成功，再异步提交消息，避免阻塞主线程池
监控与拒绝策略要落地
没有监控的线程池就像盲开高速车。必须暴露以下指标并接入告警：
- 活跃线程数、队列积压数、已提交/已完成任务数（可通过
ThreadPoolExecutor的 API 获取） - 自定义拒绝策略中记录被拒批次ID和原因，便于定位是DB慢、下游超时还是配置过紧
- 配合 Micrometer + Prometheus，绘制“每秒完成批次”曲线，识别吞吐拐点
