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() 处理任何可能阻塞的操作
