completablefuture 更适合佣金计算场景，因其天然支持有依赖的异步链路（如关系查询→规则加载→金额聚合），具备组合、扇出、异常穿透和超时控制能力，而纯线程池易导致卡死、超时和资源泄漏。
为什么 CompletableFuture 比纯线程池更适合佣金计算场景
因为佣金计算不是简单并行，而是「有依赖的异步链路」：必须先查出三级推客关系，再按各自等级查对应佣金规则，最后聚合结果。用 ExecutorService 手动管理线程+阻塞等待，容易卡死、超时、资源泄漏；而 CompletableFuture 天然支持组合（thenCompose）、扇出（allOf）、异常穿透和超时控制，能精准表达“查完 A 再查 B”或“A/B/C 并行查完再汇总”这类逻辑。
关键三步：关系查询 → 规则加载 → 金额聚合，每步都用对方法
避免把所有逻辑塞进一个 supplyAsync 里——那样就失去了异步分层的意义。实际生产中应拆解为：
- 第一步用
supplyAsync查user_relation表获取三级推客 ID 列表（注意加invitee_id索引） - 第二步对每个推客 ID 并发调用
thenApplyAsync去查commission_rule表（需预热缓存，否则 DB 成瓶颈） - 第三步用
CompletableFuture.allOf等待全部规则返回，再用thenApply聚合计算最终佣金（不带 Async，避免无谓线程切换）
示例片段（简化）：
CompletableFuture<list>> inviterIds = CompletableFuture.supplyAsync(() ->
userDao.findInvitersByInviteeId(order.getInviteeId()));
CompletableFuture<list>> details = inviterIds
.thenCompose(ids -> {
List<completablefuture>> futures = ids.stream()
.map(id -> CompletableFuture.supplyAsync(() ->
ruleService.getRuleForInviter(id, order)))
.collect(Collectors.toList());
return CompletableFuture.allOf(futures.toArray(new CompletableFuture[0]))
.thenApply(v -> futures.stream()
.map(CompletableFuture::join)
.collect(Collectors.toList()));
});
</completablefuture></list></list>
容易踩的坑：线程池配置、DB 连接、异常丢失
默认 ForkJoinPool.commonPool() 不适合 IO 密集型任务，会导致线程饥饿。必须自定义线程池：
- 用
new ThreadPoolExecutor(20, 50, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue(1000))，核心线程数 ≈ DB 连接池大小（如 HikariCP 的maximum-pool-size） - 每个
supplyAsync必须传入该线程池，否则 fallback 到 commonPool，高并发下直接拖垮整个应用 - 数据库查询必须设超时（如 MyBatis 的
timeout或 JDBC 的socketTimeout），否则一个慢查询会拖住整条链路 - 别忽略
exceptionally或handle：未处理的异常会让join()抛CompletionException，掩盖原始错误（比如 SQL 语法错被包成 NPE）
它不能解决什么：规则变更、层级越界、微信分账限制
CompletableFuture 只优化执行效率，不改变业务约束。比如《禁止传销条例》要求层级 ≤3，代码里仍要校验 level ；微信支付分账比例上限 30%，就算算得再快，超出部分也得走线下补差；规则动态调整（如黄金推客佣金从 15%→18%）仍需配合配置中心 + 规则热加载，不能只靠异步提速。
