CompletableFuture 本身不会导致内存泄漏，问题在于使用不当：未消费的 Future 会强引用任务和上下文，静态缓存需配对清理，链式调用须有终端操作并兜住异常，线程池应自定义且上下文需显式传递。
CompletableFuture 本身不是内存泄漏的源头，问题出在使用方式上——尤其是对任务生命周期、引用关系和线程上下文的疏忽。只要抓住“谁持有谁”“何时该释放”“异常是否被兜住”这三个关键点，就能避开绝大多数隐患。
别让未消费的 Future 堆在内存里
调用 submit() 或 supplyAsync() 后，如果完全不保存返回的 CompletableFuture，也不做 get()、join() 或注册回调，这个 Future 就会一直卡在线程池的任务队列或内部状态中，强引用着任务逻辑、闭包变量甚至整个 Spring 上下文。
- 避免裸调用：
executor.submit(() -> doWork())→ 改成显式接收并处理：CompletableFuture.runAsync(() -> doWork(), executor) - 若确实不需要结果，至少加个空回调标记完成：
.thenRun(() -> {}).exceptionally(e -> { log.error("ignored task failed", e); return null; }) - 对定时/周期性异步任务，务必配合超时控制：
orTimeout(30, TimeUnit.SECONDS)，防止长期挂起
慎用静态集合缓存 Future 对象
把 CompletableFuture 存进 static Map 是常见但高危操作。即使任务已完成，Future 实例仍被 Map 持有，其内部的 result、exception、依赖链等一并无法回收。
- 改用弱引用容器（如
WeakHashMap<String, CompletableFuture>），或更推荐：只存业务 ID，结果存在 Redis / DB，Future 执行完立即移除 - 所有缓存操作必须配对清理：startTask() 存入 → finishTask() 或 cancelTask() 中主动 remove()
- 考虑用 CompletionStage 替代 CompletableFuture 作为接口返回类型，避免暴露可手动 complete 的能力，降低误用风险
链式调用要收尾，异常必须显式兜底
CompletableFuture 链一旦形成，每个阶段都可能持有上游对象。如果链没走到终端操作（如 join()、get()、whenComplete()），又没设置异常处理器，整条链就可能滞留在堆中，尤其当某个环节抛异常却无人捕获时。
立即学习“Java免费学习笔记（深入）”；
- 每条链至少有一个终端操作：哪怕只是
.whenComplete((r, t) -> {})，确保链被“激活”并自然结束 - 拒绝只用 thenApply 就结束：它不处理异常，失败后下游不会触发，链悬空；优先用 handle 或补上 exceptionally
- 避免嵌套 CompletableFuture：比如
thenApply(x -> CompletableFuture.supplyAsync(...))→ 改用 thenCompose 扁平化，否则外层 Future 持有未完成的内层 Future
线程池与执行上下文必须可控
默认的 ForkJoinPool.commonPool() 是全局共享的，多个模块共用容易相互干扰；而 Servlet 容器线程（如 Tomcat 的 worker 线程）不适合执行长时间异步任务，会导致请求线程被占住。
- 生产环境一律使用自定义线程池：
Executors.newFixedThreadPool(n, threadFactory)，并命名线程便于排查 - 禁止在 Controller 方法体、Filter、Interceptor 中直接调用 get() 或 join() —— 这等于把异步变同步，压垮主线程
- 涉及事务、SecurityContext、RequestContextHolder 的场景，记得用 copy 方式透传上下文，否则异步线程拿不到，还可能因强引用拖慢 GC
