如何解决Arena与Portal之间的循环依赖问题且保留两者的不可变特性

你遇到的是典型的不可变实例循环初始化冲突问题：两个类都要求对方的完整实例作为构造入参，Java的实例化顺序规则天然不支持这种直接的互相注入，你目前用双HashMap维护映射的方案虽然可用，但存在映射维护成本和不同步风险，以下是更优的实现方案：

方案1：引入中间关联上下文类，完全保留两个类的不可变性 #

核心思路是把双向关联的逻辑从Arena和Portal本身抽离，两个类不再持有对方的引用，所有交互都通过上下文类完成，完全不破坏两个类的不可变特性，适合两个类本身不需要强感知对方存在的场景。

// Arena、Portal移除对方的成员变量，保持自身纯不可变
public final class Arena {
    // 原有其他final字段保留
    void start() {
        // 原有启动逻辑
    }
    void closeSelf() {
        // 原有自身关闭逻辑
    }
}

public final class Portal {
    // 原有其他final字段保留
    void closeSelf() {
        // 原有自身关闭逻辑
    }
}

// 新增关联上下文类，统一维护双向关系和交互逻辑
public final class ArenaPortalContext {
    private final Arena arena;
    private final Portal portal;

    private ArenaPortalContext(Arena arena, Portal portal) {
        this.arena = arena;
        this.portal = portal;
    }

    // 工厂方法统一构造，从根源保证关联关系一致性
    public static ArenaPortalContext create() {
        return new ArenaPortalContext(new Arena(), new Portal());
    }

    // 封装需求的交互逻辑
    public void startPortal() {
        // Portal启动后触发Arena启动
        portal.start();
        arena.start();
    }

    public void closeArena() {
        // Arena关闭后触发关联Portal关闭
        arena.closeSelf();
        portal.closeSelf();
    }

    // 仅暴露getter，不提供setter保证上下文本身也不可变
    public Arena getArena() {
        return arena;
    }

    public Portal getPortal() {
        return portal;
    }
}

• 优势：完全符合不可变设计规范，关联逻辑统一收敛，不会出现映射不同步问题，排查维护成本极低。

方案2：懒持有包装，保留对外不可变的使用体验 #

如果业务逻辑确实需要两个类能直接互相调用方法，可以用Supplier做懒注入，只在构造完成后才会解析到对方实例，对外仍然符合不可变的使用约定。

public final class Arena {
    private final Supplier<Portal> portalSupplier;
    // 原有其他final字段保留

    Arena(Supplier<Portal> portalSupplier) {
        this.portalSupplier = portalSupplier;
    }

    // 对外暴露固定的Portal实例，多次调用返回结果一致
    public Portal getPortal() {
        return portalSupplier.get();
    }

    void close() {
        getPortal().close();
        // 自身关闭逻辑
    }

    void start() {
        // 原有启动逻辑
    }
}

public final class Portal {
    private final Supplier<Arena> arenaSupplier;
    // 原有其他final字段保留

    Portal(Supplier<Arena> arenaSupplier) {
        this.arenaSupplier = arenaSupplier;
    }

    // 对外暴露固定的Arena实例，多次调用返回结果一致
    public Arena getArena() {
        return arenaSupplier.get();
    }

    void close() {
        // 自身关闭逻辑
    }

    void start() {
        getArena().start();
    }
}

// 统一构造配对实例的工厂方法
public static void createArenaPortalPair() {
    final AtomicReference<Arena> arenaRef = new AtomicReference<>();
    final AtomicReference<Portal> portalRef = new AtomicReference<>();

    arenaRef.set(new Arena(portalRef::get));
    portalRef.set(new Portal(arenaRef::get));
    
    // 构造完成后两个实例即可正常使用，实例关联关系不会再变更
    Arena arena = arenaRef.get();
    Portal portal = portalRef.get();
}

• 优势：两个类可以直接互相访问，不需要修改原有业务逻辑的调用习惯，仅需保证构造完成前不会调用getArena()/getPortal()方法即可。

方案3：单次赋值的构造后初始化（实现最简单，不可变程度稍低） #

如果你可以接受对象构造后有一次不可修改的赋值操作，可以给两个类的对应引用字段加上仅允许调用一次的setter限制，这种方案破坏了严格的不可变性，除非是旧系统改造的兼容场景否则不推荐使用。

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