在Reactor Context中使用Map/引用对象是否合法、安全？

先看你给出的示例代码：

Mono.just(1)
        .flatMap(item -> {
            return Mono.deferContextual(ctx -> {
                Map<String, String> temp = ctx.get(CONTEXT_KEY);
                // 向MAP中存入内容。<1>
                temp.put(MAP_KEY, "value");
                return Mono.just(item);
            });
        })
        .flatMap(item -> {
            return Mono.deferContextual(ctx -> {
                Map<String, String> temp = ctx.get(CONTEXT_KEY);
                // 受上方操作符修改的Context影响。<2>
                // 打印`value`
                System.out.println(temp.get(MAP_KEY));
                return Mono.just(item);
            });
        })
        // 将contextWrite置于调用链末端，确保上方操作符能访问到该MAP。
        .contextWrite(ctx -> ctx.put(CONTEXT_KEY, new HashMap<String, String>()))
        .subscribe();

你提到Reactor Context的生效顺序是从后到前，但这里修改Map后影响了后续操作符，看起来像从前到后用ThreadLocal的效果，现在针对你的三个疑问逐一解答：

1. 该操作是否合法？ #

从Reactor的API规则来说，这种写法是合法的——Context允许存放任何引用类型对象，也没有禁止修改存入对象的内部状态。但要注意，Reactor的Context设计初衷是传递不可变的上下文元数据，比如用户ID、请求追踪ID这类不会被修改的值。这种修改存入Context的可变对象的用法，违背了Context的设计范式，很容易引发意料之外的副作用（比如后续操作符误改数据导致业务逻辑混乱），所以不推荐使用。

2. Map体积过大会存在性能问题吗？ #

会有明显的性能影响：

• Reactor的Context是不可变的，每次contextWrite都会创建新的Context实例，但如果存入的Map体积很大，这个大对象会增加内存占用，尤其是在多订阅、高频调用的场景下，会大幅提升GC压力，拖慢整体性能。
• 大Map本身的读写操作效率更低，无论是插入、查询还是遍历，都会比小Map消耗更多CPU资源，进一步影响响应速度。

3. 是否会引发线程安全问题？ #

肯定会，而且风险很高：

• 示例中的HashMap本身不是线程安全的，而Reactor操作符可能在不同线程上执行（比如通过subscribeOn/publishOn切换调度器），如果多个线程同时对这个Map执行读写操作，会出现数据不一致、ConcurrentModificationException等问题。
• 就算换成ConcurrentHashMap这类线程安全的Map，也不能完全消除风险——因为Context的传递逻辑可能导致同一个Map被多个订阅实例共享（如果错误地复用了Map引用），或者在异步流程中出现时序问题，依然可能引发业务逻辑错误。

内容的提问来源于stack exchange，提问作者哦嘞啊嘞