Java CompletionStage间共享上下文修改对后续执行线程是否始终可见

你的理解完全正确，上述代码始终会打印Will that always be the case，不存在共享上下文的内存可见性问题，这是Java并发规范明确保障的行为。

核心理论依据：Java内存模型Happens-Before规则 #

Java内存模型中的Happens-Before规则是可见性判断的唯一标准，只要操作A满足Happens-Before操作B，那么A的所有内存修改对B都是完全可见的，不受运行线程、CPU缓存等底层实现影响。和该问题相关的两条规则如下：

• java.util.concurrent.Executor通用规范：提交给线程池的任务，提交动作Happens-Before任务的执行动作
• CompletionStage接口语义规范：链式调用中，前一个阶段的执行完成Happens-Before依赖它的后一个阶段的执行开始

对应代码场景的推导 #

你给出的代码是严格的链式依赖结构，结合Happens-Before的传递性可以直接得到可见性结论：

1. 第一个thenAcceptAsync执行context.data.add("1")完成，Happens-Before第二个thenAcceptAsync的启动，因此第二个lambda一定能看到"1"的写入
2. 第二个thenAcceptAsync执行context.data.add("2")完成，Happens-Before第三个thenAcceptAsync的启动，因此第三个lambda一定能同时看到"1"和"2"的写入
3. 该保障不受线程池线程数量、链式阶段数量、Context嵌套复杂度影响，即使Context的字段没有加volatile修饰、内部嵌套再多自定义对象，只要修改是在链式阶段中按依赖顺序完成的，对后续阶段的线程就完全可见。

关于你同事提到的"复现异常" #

如果实际测试中出现了不符合预期的结果，大概率是测试场景不符合你给出的代码前提，常见的错误场景包括：

• 测试代码没有使用严格的链式依赖，而是创建了多个独立无依赖的CompletableFuture并行执行
• 有不在链式阶段中的其他线程同时修改Context上下文
• 测试时未等待所有链式阶段执行完成就提前读取上下文数据，或者提前关闭了线程池

内容的提问来源于stack exchange，提问作者festiv