threadpoolexecutor 高性能关键在于参数匹配任务类型、拒绝策略兜底、生命周期可控；cpu密集型设核心线程≈cpu核数+1，io密集型取2–4倍核数并用有界队列，混合型建议拆分或增大maxpoolsize；拒绝策略禁用abortpolicy，优选callerrunspolicy或自定义策略；提交任务须统一用submit()配合try-catch或全局异常处理器；spring中用threadpooltaskexecutor并优雅关闭，禁用executors工厂方法。
用 ThreadPoolExecutor 实现高性能异步任务处理，关键不在“堆线程”，而在参数匹配任务特性、拒绝策略兜底、生命周期可控。直接套默认配置容易在高并发时卡死或 OOM。
按任务类型选核心参数
CPU 密集型任务（如加解密、图像处理）：核心线程数建议设为 CPU 核数 + 1，避免过多线程争抢 CPU；keepAliveTime 可设为 0 或极短，非核心线程几乎不启用。
IO 密集型任务（如 HTTP 调用、数据库查询）：线程常处于等待状态，核心线程数可设为 CPU 核数 × (1 + 平均等待时间 / 平均计算时间)，实践中常取 2–4 倍核数；队列容量需限制，推荐使用 ArrayBlockingQueue 而非无界队列。
混合型任务（如 Web 请求含计算+DB+远程调用）：建议拆分任务类型，用多个专用线程池隔离；若共用一个池，maxPoolSize 应明显大于 corePoolSize，配合有界队列和合理拒绝策略。
拒绝策略不能只用默认的 AbortPolicy
生产环境遇到突发流量时，AbortPolicy 直接抛异常会中断调用链，影响用户体验。更稳妥的选择：
- CallerRunsPolicy：让提交任务的线程自己执行，天然限流，适合对延迟敏感但能容忍少量慢请求的场景
- DiscardOldestPolicy：丢掉排队最久的任务，适合任务有时效性（如实时行情推送）
- 自定义拒绝策略：记录日志 + 上报监控 + 触发降级逻辑（例如返回缓存数据）
任务提交方式影响异常可见性
别只看 submit() 返回 Future 就觉得更“高级”——实际差异直接影响问题排查：
- 用
execute(Runnable)提交：异常会直接抛到线程的UncaughtExceptionHandler，若未设置，就静默丢失 - 用
submit(Runnable)或submit(Callable)：异常被包装进 Future，必须显式调用get()才触发，否则也看不到 - 安全做法：统一用
submit()+ 包装 try-catch，或为线程池设置全局异常处理器
务必管理好线程池生命周期
Spring 环境下推荐用 ThreadPoolTaskExecutor（本质是 ThreadPoolExecutor 的封装），它支持优雅关闭：
- 应用关闭前调用
shutdown()，等待已提交任务完成 - 超时后调用
shutdownNow()强制中断运行中任务（注意：需确保任务本身可中断） - 避免使用
Executors.newFixedThreadPool()等工厂方法创建的线程池——它们用的是无界队列，极易内存溢出
线程池不是万能加速器，而是需要精细调节的资源调度器。参数调得准，比加机器更有效。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
