completablefuture 的“栈”是基于链表实现的无锁 treiber 栈，用于存储回调任务，与 jvm 调用栈无关；result 字段统一承载未完成、成功结果、异常、显式 null 四种状态；stack 指向 completion 链表头，每个节点在堆中固化执行上下文，通过 postcomplete 遍历触发 tryfire，完全脱离原始栈帧，确保回调不因方法返回而丢失。
CompletableFuture 的“栈”不是 JVM 调用栈（stack frame），而是它自己维护的、基于链表实现的无锁栈（Treiber Stack），用于存储回调任务，和方法调用时的栈帧无关。理解这一点，是避免常见误解的关键。
result 字段：状态与结果的统一载体
volatile Object result 并非简单存返回值。它承载三种语义：
- null：表示任务尚未完成（初始态）
- 普通对象（非 AltResult）：表示正常完成，该对象即计算结果
- AltResult 实例：封装了异常（ex != null）或显式 null 结果（ex == null 且为 NIL 单例）
这种设计用一个字段区分“未完成”“成功”“失败”“空值”四种逻辑状态，避免额外标志位，也规避了 volatile 写操作的冗余。
stack 字段：依赖回调的无锁栈结构
volatile Completion stack 指向的是 Treiber 栈顶节点，每个节点是一个回调动作（如 UniCompletion），不是函数字节码，也不是栈帧里的局部变量。
- 节点中保存 src（源 CompletableFuture）、dep（下游 CompletableFuture）、fn（转换函数引用）、executor（执行器）等元数据
- 回调函数本身（如 lambda 表达式）作为对象被捕获并持有，存在堆上；stack 只存指向它的引用和执行上下文
- 入栈靠 CAS 原子更新 stack 字段；出栈时逐个 pop 并 tryFire，不依赖 JVM 栈帧生命周期
因此，回调不会因外层方法返回、栈帧销毁而丢失——它们已脱离调用链，成为堆中可被 postComplete 触发的独立任务。
postComplete：回调触发不依赖调用栈
当 result 被写入（通过 complete / completeExceptionally / supplyAsync 完成等），会调用 postComplete 方法：
- 它遍历 stack 中所有 Completion 节点，按后进先出顺序触发 tryFire
- 每个 tryFire 在指定 executor（或当前线程）中异步/同步执行，完全脱离原始调用栈
- 执行过程中若产生新阶段（如 thenApply 返回新 CF），该新 CF 的 stack 是独立管理的，与父节点栈帧无关
也就是说，哪怕发起 thenApply 的方法早已 return、其栈帧早已被回收，回调仍能正确执行——因为所有依赖信息都固化在堆对象里。
为什么不会出现“栈帧消失导致回调失效”？
根本原因在于 CompletableFuture 是面向**对象状态驱动**，而非**调用栈驱动**：
- 没有把回调函数压入 JVM 方法调用栈，不依赖栈帧存活
- 所有上下文（函数、参数、目标 CF、线程池）都作为 Completion 子类的字段保存在堆上
- 整个链式结构是显式的对象图（Object Graph），由 GC 正常管理生命周期
这正是它能安全支持长链编排、跨线程传递、手动完成等高级能力的底层基础。
