用 CompletableFuture.runAsync() 执行无返回值任务完全可行，但必须显式指定自定义线程池、处理异常、管理线程池生命周期，否则易导致 commonPool 被拖垮、异常静默丢失、资源泄漏。
直接说结论：用 CompletableFuture.runAsync() 执行无返回值任务完全可行，但必须注意默认使用的是 ForkJoinPool.commonPool()，生产环境不加控制容易拖垮线程池。
为什么 runAsync() 适合“无返回值”场景
它接收的是 Runnable，不强制要求返回值，语义上比 supplyAsync() 更贴切；底层不会封装 U 类型，避免无谓的泛型擦除开销。
- 不要在
runAsync()里写return null或试图 return 东西——编译不过 - 如果任务实际需要返回结果，别硬套
runAsync()，改用supplyAsync() - 它返回的是
CompletableFuture<void></void>，不是void—— 这意味着你仍可链式调用thenRun()、exceptionally()等
必须显式传入自定义线程池
默认用 ForkJoinPool.commonPool() 是最大陷阱：所有未指定线程池的 runAsync()、supplyAsync() 共享同一个池，一旦某个异步任务阻塞（比如 IO、sleep），就会卡住其他无关任务。
- IO 密集型任务建议用
Executors.newCachedThreadPool()或带队列的ThreadPoolExecutor - CPU 密集型任务线程数设为
Runtime.getRuntime().availableProcessors() - 务必给线程池命名（如通过
ThreadFactory），否则日志里全是pool-1-thread-1，查问题抓瞎
示例：
ExecutorService ioPool = Executors.newFixedThreadPool(10, r -> {
Thread t = new Thread(r);
t.setName("async-io-worker-" + t.getId());
return t;
});
CompletableFuture.runAsync(() -> {
// 模拟 HTTP 调用或文件读取
callExternalApi();
}, ioPool);
异常不会自动抛出，必须手动处理
runAsync() 内部抛出的异常不会打断主线程，也不会打印堆栈——它会静默吞掉，只把异常存在 CompletableFuture 的内部状态里。后续若没调用 join() 或 get()，你就根本不知道任务失败了。
- 最简方案：链式加
exceptionally()记录日志 - 若需重试，用
handle()判断是否为 null（表示成功）或有异常 - 绝对不要依赖
try-catch包裹 lambda 体来捕获——它只捕获构造时异常，不捕获执行时异常
示例：
CompletableFuture.runAsync(() -> {
riskyOperation(); // 可能抛 NPE 或 IOException
}, ioPool)
.exceptionally(ex -> {
log.error("async task failed", ex);
return null;
});
别忘了资源清理和生命周期管理
很多人只管提交任务，忘了线程池本身是重量级资源。尤其在 Spring Boot 应用中，@PostConstruct 创建的线程池若没配 @PreDestroy 关闭，会导致应用停不干净、连接泄漏。
- 非 Web 应用：JVM 退出前显式调用
shutdown()+awaitTermination() - Spring 环境：用
@Bean(destroyMethod = "shutdown")声明线程池 Bean - 避免在每次调用
runAsync()时都新建线程池——那是性能灾难
真正麻烦的从来不是怎么启动一个异步任务，而是确保它跑完、出错能感知、资源不泄露、不影响别人。这几个点漏掉任意一个，线上就等着收告警吧。
