Future不触发get()的常见原因有三：线程池已关闭导致任务被拒绝；CachedThreadPool中快速任务被误判为未执行；Runnable提交后get()恒返回null。
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();
• 不要用
commonPool() 处理任何可能阻塞的操作
ThreadPoolExecutor 的 keepAliveTime 对 corePoolSize 线程是否生效？
只对超出 corePoolSize 的空闲线程生效。也就是说：
• 如果你设了 corePoolSize=5、maxPoolSize=10、keepAliveTime=60L，那么第 6~10 号线程空闲满 60 秒会被回收
• 但前 5 个核心线程默认永不回收（除非显式设置 allowCoreThreadTimeOut(true)）
• 这个细节直接影响资源泄漏风险：长期运行的服务若用了 allowCoreThreadTimeOut(false)（默认值）+ 大 corePoolSize，即使流量归零，线程也一直占着内存和上下文切换开销
1、架构轻盈，完全免费与开源采用轻量MVC架构开发，兼顾效率与拓展性。全局高效缓存，打造飞速体验。 2、让简洁与强大并存强大字段自定义功能，完善的后台开关模块，不会编程也能搭建各类网站系统。 3、顶级搜索引擎优化功能纯静态、伪静态，全部支持自由设置规则，内容、栏目自由设置URL格式。 4、会员、留言、投稿、支付购物神马一个不能少不断升级完善的模块与插件，灵活的组装与自定义设置，满足你的多样需求。
立即学习“Java免费学习笔记（深入）”；
线程池不是配置完就一劳永逸的事——队列选型、拒绝策略、执行器绑定、超时行为，每个参数都在暗处牵扯着吞吐、延迟和稳定性。最常被忽略的，是把“能跑通”当成“跑得对”。
