Java并发Executor框架性能详解

本文深入剖析Java并发Executor框架中那些看似正常实则暗藏陷阱的关键细节：从Future不触发get()的三大迷惑性原因（线程池关闭、CachedThreadPool任务“消失”、Runnable提交后get()恒返回null），到FixedThreadPool因无界队列引发的内存溢出风险与有界队列下的静默拒绝；从CompletableFuture默认使用ForkJoinPool.commonPool()在IO密集场景下拖垮整个应用的致命隐患，再到keepAliveTime对核心线程“永不回收”的默认行为所导致的资源泄漏风险——每一条都直击生产环境高频踩坑点，揭示“能跑通”绝不等于“跑得对”，帮助开发者穿透表象，真正掌握线程池性能与稳定性的底层逻辑。

ExecutorService.submit() 返回的 Future 为什么有时不触发 get()

调用 submit() 后没立刻 get()，任务看似“没执行”，其实是线程池未启动或任务被拒绝。常见原因有三：
• 线程池已 shutdown() 或 shutdownNow()，新任务直接走 RejectedExecutionHandler（默认抛 RejectedExecutionException）
• 使用了 Executors.newCachedThreadPool() 但任务极快结束，导致线程在你观察前就回收了，误以为没运行
• 提交的是 Runnable 而非 Callable，submit(Runnable) 返回的 Future 的 get() 永远返回 null，不抛异常也不阻塞——容易误判为“没生效”

FixedThreadPool 的 corePoolSize 和 maxPoolSize 相等，但队列满了仍会拒绝任务

很多人以为 Executors.newFixedThreadPool(n) 是“绝对稳定”的，其实它底层用的是 LinkedBlockingQueue（无界队列）。问题出在：当队列持续积压（比如下游处理慢、任务生成快），JVM 堆内存可能被撑爆；而一旦你手动换成有界队列（如 ArrayBlockingQueue(100)），且没配自定义拒绝策略，任务就会在队列满时立即被拒绝——不是线程不够，是队列挡在前面。
• 必须显式传入 ThreadPoolExecutor 构造器才能控制队列类型和拒绝策略
• newFixedThreadPool 的“固定”只指线程数，不保证任务不丢失

CompletableFuture.runAsync() 默认用 ForkJoinPool.commonPool()，别在 CPU 密集型任务里乱用

CompletableFuture 的异步方法若不指定 Executor，默认走 ForkJoinPool.commonPool()。这个池子大小通常等于 CPU 核数（Runtime.getRuntime().availableProcessors() - 1），适合并行计算类任务；但如果你用它跑大量 IO 或阻塞操作（比如 Thread.sleep()、数据库查询、HTTP 调用），会导致 commonPool 线程长时间占用，拖垮整个应用的并行流（parallelStream()）甚至其他 CompletableFuture 链。
• IO 密集型任务务必传自定义 ExecutorService，例如：

ExecutorService ioExecutor = Executors.newCachedThreadPool();

ThreadPoolExecutor 的 keepAliveTime 对 corePoolSize 线程是否生效？

只对超出 corePoolSize 的空闲线程生效。也就是说：
• 如果你设了 corePoolSize=5、maxPoolSize=10、keepAliveTime=60L，那么第 6~10 号线程空闲满 60 秒会被回收
• 但前 5 个核心线程默认永不回收（除非显式设置 allowCoreThreadTimeOut(true)）
• 这个细节直接影响资源泄漏风险：长期运行的服务若用了 allowCoreThreadTimeOut(false)（默认值）+ 大 corePoolSize，即使流量归零，线程也一直占着内存和上下文切换开销

线程池不是配置完就一劳永逸的事——队列选型、拒绝策略、执行器绑定、超时行为，每个参数都在暗处牵扯着吞吐、延迟和稳定性。最常被忽略的，是把“能跑通”当成“跑得对”。

好了，本文到此结束，带大家了解了《Java并发Executor框架性能详解》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！