java线程池高并发处理关键在避免用错类型、配错参数、漏掉拒绝策略；需按io/cpu密集型合理设corepoolsize与队列，优先submit()捕获异常，自定义拒绝策略联动监控，分业务隔离线程池，并正确shutdown。
Java 里用线程池处理高并发请求，关键不在“能不能用”，而在于「用错类型、配错参数、漏掉拒绝策略」——这三处出问题，服务会在线上突然卡死或大量丢请求，比不用线程池还危险。
ThreadPoolExecutor 的核心参数怎么设才不翻车
很多人直接 new ThreadPoolExecutor(10, 20, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue(100))，以为“最大20个线程+队列100”就稳了。实际这是典型陷阱：
-
corePoolSize设太小（如 2），突发流量进来，新任务全进队列，等前面线程慢慢消费，响应时间飙升 -
maximumPoolSize和LinkedBlockingQueue同时大（如都设成 1000），OOM 风险极高：每个线程栈默认 1MB，1000 线程光栈就占 1GB+ -
keepAliveTime对corePoolSize以下线程无效，除非调用allowCoreThreadTimeOut(true)，否则核心线程永不回收
更稳妥的做法是按业务类型区分：
- IO 密集型（如 HTTP 调用、DB 查询）：
corePoolSize ≈ CPU 核数 × (1 + 平均等待时间 / 平均工作时间)，常用 2N～4N；队列用SynchronousQueue配合合理maximumPoolSize，逼迫线程池快速扩容而非积压 - CPU 密集型（如加解密、图像处理）：
corePoolSize基本等于 CPU 核数，禁用队列或只用极小容量，避免上下文切换开销
execute() 和 submit() 混用会导致异常丢失
用 execute(Runnable) 提交任务时，如果内部抛出未捕获异常，线程会打印堆栈后静默终止，而线程池可能继续复用该线程——下个任务一运行就崩，但你完全看不到第一次的异常。
立即学习“Java免费学习笔记（深入）”；
submit(Callable) 或 submit(Runnable, result) 则不同：异常会被包装进 Future.get() 抛出，必须显式处理。
- 所有异步任务，优先用
submit()+future.get(timeout, unit)，超时立即感知失败 - 若坚持用
execute()，务必给线程池设置ThreadFactory，在newThread里为线程设置UncaughtExceptionHandler - 别依赖日志框架的全局异常处理器——它收不到线程池内未捕获的异常
拒绝策略不是摆设，要和监控联动
默认的 AbortPolicy 直接抛 RejectedExecutionException，但线上没人 catch 它；CallerRunsPolicy 让调用线程自己执行任务，可能拖慢上游接口，掩盖真实瓶颈。
真正可用的方案是自定义策略：
- 记录被拒任务的
toString()、时间戳、线程池状态（getActiveCount()、getQueue().size()）到独立日志文件 - 触发 Prometheus 指标
threadpool_rejected_total{pool="biz"} 1，配 Grafana 告警 - 必要时降级：比如写缓存失败时，拒绝策略里直接走本地内存缓存（
ConcurrentHashMap），保证基本可用
线程池不能全局单例乱共享
一个 static final ExecutorService 被多个业务模块共用，某个模块因 SQL 慢查询卡住线程，整个服务的定时任务、消息消费、HTTP 回调全被堵死。
正确的隔离方式：
- 按资源类型分池：DB 操作用
dbExecutor，外部 HTTP 调用用httpExecutor，定时任务用scheduledExecutor - 按 SLA 分池：核心支付链路用独立池，非核心日志上报用另一个池，且后者可配置更低的
maximumPoolSize和更激进的拒绝策略 - Spring 用户注意：
@Async默认用SimpleAsyncTaskExecutor（每次新建线程），必须显式配置ThreadPoolTaskExecutorbean 并指定executor属性
最常被忽略的一点：线程池 shutdown 的时机。Web 应用里，要在 ServletContextListener.contextDestroyed() 或 Spring 的 @PreDestroy 中调用 shutdown() + awaitTermination()，否则 JVM 退出时活跃线程被强制 kill，正在写的文件、未 flush 的缓冲区、事务中的 DB 连接全丢。
