FutureTask作为一次性异步执行容器和结果聚合入口，配合事件监听与correlationId映射实现动态多路复用：发起订阅后立即返回，由独立回调唤醒FutureTask并set结果，通过done()自动清理订阅。
在自研发布订阅框架中，用 FutureTask 实现“带事件返回的方法”的异步调用与动态多路复用，核心不是让 FutureTask 直接处理事件，而是把它作为**一次性的异步执行容器 + 结果聚合入口**，配合事件监听机制完成“发起请求 → 等待任意一个/多个事件触发 → 返回结果”的流程。关键在于解耦“任务提交”和“事件响应”，避免阻塞，同时支持运行时灵活组合多个事件源。
把 FutureTask 当作“结果承诺容器”，不用于直接绑定事件
FutureTask 本质是 Runnable + Future，适合封装**有明确起止、可被 cancel、只执行一次**的逻辑。它不适合长期监听事件（比如一直等某个 topic 的消息），但非常适合：封装一次订阅+等待动作，并把最终结果（无论成功/失败/超时）塞进 get() 可取回的值里。
- 不要在
FutureTask的run()里写 while(true) + poll 事件 —— 这会阻塞线程池，违背异步本意 - 应该在
run()中：发起订阅（如注册 listener）、设置超时计时器、触发初始动作（如发请求），然后立即返回 - 真正响应事件的逻辑，应由独立的事件分发器或 listener 回调完成，回调中负责唤醒对应的
FutureTask
用“事件 ID + Map 缓存”实现动态多路复用
多路复用 ≠ 同时等多个 topic，而是：一次请求可能关联多个事件源（如 “订单创建成功”、“库存扣减完成”、“风控校验通过”），且这些事件到达顺序不确定、部分可能缺失、部分可能重复。需要按需组合、可配置、可取消。
- 为每次调用生成唯一
correlationId（如 UUID），作为该次“多路等待”的标识 - 维护一个
ConcurrentMap<String, FutureTask<Result>>，key 是correlationId，value 是待填充结果的FutureTask - 当收到任意一个相关事件（如 topic = "order.created", header.correlationId = xxx），从 map 查出对应
FutureTask，调用set(result)或setException(e) - 若需“等待全部就绪”，可用
CountDownLatch或CompletableFuture.allOf组合多个FutureTask；若需“任一满足即返回”，则首次set()后立即从 map 移除并清理资源
订阅注册与自动清理必须成对出现
动态意味着：不能全局静态订阅，否则内存泄漏、事件错乱。每次 FutureTask 创建时，应同步注册临时 listener，并确保在结果返回后（无论成功/失败/取消）解除订阅。
- 推荐在
FutureTask构造时，传入一个SubscriptionHandle对象，内部封装了 topic + filter + callback - 在
run()中调用subscribe(handle)；在done()回调（重写FutureTask.done()）中调用unsubscribe(handle) - 也可用 try-with-resources 风格包装 handle，但需确保异常路径也能释放（例如超时后主动 unsubscribe）
示例：下单后等待“支付成功”或“30s 超时”
用户调用 awaitOrderResult(orderId)，框架内部：
- 生成
cid = "ord_abc123"，创建FutureTask<OrderResult> - 向 EventBus 注册临时 listener：
topic="payment.success", filter=match(corrId=cid) - 启动一个延迟任务：30s 后若未
set()，则set(new TimeoutResult())并unsubscribe - 当支付服务发布
payment.success且corrId==cid，listener 捕获，调用future.set(…)，自动触发done()清理 - 调用方只需
future.get()，即可拿到结果或抛出ExecutionException
不复杂但容易忽略：FutureTask 本身不解决事件路由和生命周期管理，它只是“结果契约”。真正的动态性来自 correlationId 的灵活构造、事件过滤器的表达能力、以及订阅/退订的精准控制。
