java线程池需按任务类型分池管理：注册短信用小池配抛异常策略，订单导出用大池加断点续传，日志落盘用丢弃策略；须手动构建threadpoolexecutor，合理设置core/max线程数、有界队列及拒绝策略；submit适合需结果场景，execute用于纯异步；需监控活跃线程、队列长度等指标并结构化日志。
Java 中线程池处理多线程异步协作的任务分发，核心在于“谁来接活、怎么排队、超时怎么管、失败怎么兜底”。不是简单起个线程就完事，而是围绕业务节奏设计一套可预期、可监控、可伸缩的协作机制。
任务分发前先明确协作边界
异步协作 ≠ 所有任务扔进同一个池子。真实场景中，不同任务类型对资源、延迟、失败容忍度差异很大：
- 用户注册成功后发短信（轻量、低频、强时效）→ 单独小线程池，拒绝策略设为抛异常，避免阻塞主流程
- 订单导出生成百万行 Excel（耗内存、长耗时、可重试）→ 独立大线程池 + 自定义队列（如 LinkedBlockingQueue），配合超时取消和断点续传
- 日志异步落盘（高频、低优先级、允许丢弃）→ 使用 DiscardPolicy 或 DiscardOldestPolicy，不堆积不卡主线程
用 ThreadPoolExecutor 替代 Executors 工厂方法
Executors.newFixedThreadPool() 这类快捷方式隐藏了关键参数，容易在线上压测或突发流量时暴雷。手动构建 ThreadPoolExecutor 才能真正掌控分发逻辑：
- corePoolSize：设为 CPU 核心数 × (1~1.5)，保障计算密集型任务不频繁切换；I/O 密集型可适当放大（如 ×2~3）
- maximumPoolSize：与队列容量配合使用——队列满才扩容，避免无节制创建线程拖垮系统
- workQueue：别默认用无界 LinkedBlockingQueue，改用有界队列（如 ArrayBlockingQueue(1000)），配合合理拒绝策略
- RejectedExecutionHandler：根据业务选策略，比如记录告警+降级为同步执行，而不是直接丢任务
任务提交方式决定协作粒度
submit() 和 execute() 表面只差一个返回值，实际影响整个协作链路：
- 需要结果或异常回调 → 用 submit(Callable)，返回 Future，支持 get(timeout) 主动等待，也支持 isDone()/cancel() 控制生命周期
- 纯 fire-and-forget 场景（如埋点上报）→ 用 execute(Runnable)，开销更小，不产生 Future 对象
- 批量任务统一管理 → 提交多个 Future 到 List，用 invokeAll() 或 invokeAny() 实现超时聚合或最快响应
协作不是靠猜，得靠可观测性
线程池本身不暴露运行态，必须主动注入监控能力：
- 定期采集 getActiveCount()、getQueue().size()、getCompletedTaskCount()，绘制成 Grafana 图表
- 为每个线程池命名（通过 ThreadFactory），让线程 dump 中一眼识别归属（如 “sms-pool-1”、“export-pool-3”）
- 在拒绝任务时打结构化日志，包含任务类型、提交时间、队列长度、当前活跃线程数，方便定位瓶颈
不复杂但容易忽略
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
