如何为仅通过接口暴露的两个集合实现线程安全的同步访问？

这个问题确实挺棘手的——既要维护父子集合的双向同步，又得保证线程安全，还受限于接口没法直接操作内部锁，太考验设计了！我来帮你梳理下各个方案的利弊，以及可行的优化方向：

先聊聊你试过的方案 #

1. 锁各自内部集合：死锁的根源 #

你说的没错，这种方式必然会触发死锁。比如A调用addChild(B)，先锁A的children集合，然后调用B的addParent(A)，B又锁自己的parents集合，接着B会回调A的addChild(B)，这时候A已经持有children的锁，B持有parents的锁，双方都在等对方释放锁，直接卡死。这种交叉锁的场景完全是死锁的典型案例，肯定不能用。

2. 按固定顺序锁实例：可行但要规避风险 #

你提到的「先锁父实例，再锁子实例」的思路其实是避免死锁的经典解法——只要所有线程都按照相同的顺序获取锁，就不会出现循环等待的情况。

至于你担心的「锁方法参数危险」的问题，其实要分场景看：

• 通常不建议锁参数，是因为外部代码可能也会拿到这个参数对象，在别的地方随意加锁，导致意外的死锁或阻塞。
• 但如果你的场景满足这两个条件，这个方案就是安全的：
  • 所有修改IEntity关联关系的操作，只能通过addChild/addParent这两个接口方法，外部代码不会直接操作实例的内部集合，也不会随意锁IEntity实例。
  • 所有IEntity的实现都严格遵循「父实例优先锁」的规则，比如：

    addChild(IEntity child) {
        synchronized(this) { // 先锁当前父实例
            synchronized(child) { // 再锁子实例
                if (!getChildren().contains(child)) {
                    // 内部添加子节点逻辑
                    child.addParent(this);
                }
            }
        }
    }
    
    addParent(IEntity parent) {
        synchronized(parent) { // 先锁父实例
            synchronized(this) { // 再锁当前子实例
                if (!getParents().contains(parent)) {
                    // 内部添加父节点逻辑
                    parent.addChild(this);
                }
            }
        }
    }
    

  只要能保证这两点，锁实例的方案就能安全运行，不会有死锁风险。

3. 全局锁：简单但性能拉胯 #

你现在用的全局锁确实能解决问题，但代价是所有关联操作都变成串行执行，高并发场景下吞吐量会极低，只能作为临时方案或者并发量很小的场景用。

更优的替代方案 #

方案一：扩展接口，避免循环调用 #

如果允许修改IEntity接口，最稳妥的方式是添加一个带「跳过反向同步」标记的重载方法，从根源上避免循环调用，同时只锁自己的内部集合：

interface IEntity {
    List<IEntity> getChildren();
    List<IEntity> addChild(IEntity child);
    List<IEntity> getParents();
    List<IEntity> addParent(IEntity parent);
    
    // 新增内部用的重载方法，标记是否跳过反向同步
    default List<IEntity> addChild(IEntity child, boolean skipReciprocal) {
        synchronized(getChildren()) { // 只锁自己的children集合
            if (!getChildren().contains(child)) {
                getChildren().add(child);
                if (!skipReciprocal) {
                    // 调用带标记的addParent，跳过反向回调
                    child.addParent(this, true);
                }
            }
            return new ArrayList<>(getChildren());
        }
    }
    
    default List<IEntity> addParent(IEntity parent, boolean skipReciprocal) {
        synchronized(getParents()) { // 只锁自己的parents集合
            if (!getParents().contains(parent)) {
                getParents().add(parent);
                if (!skipReciprocal) {
                    // 调用带标记的addChild，跳过反向回调
                    parent.addChild(this, true);
                }
            }
            return new ArrayList<>(getParents());
        }
    }
}

对外暴露的addChild/addParent方法可以默认调用带skipReciprocal=false的重载，这样既保证了双向同步，又不会出现循环调用，也没有交叉锁的问题，线程安全和性能都能兼顾。而且接口的默认实现可以让其他实现直接复用，不用重复写逻辑。

方案二：用显式锁替代内置锁（复杂但灵活） #

如果不能修改接口，还可以用ReentrantLock代替synchronized，通过tryLock来避免死锁。比如在addChild中先尝试获取自己的锁，再尝试获取子实例的锁，如果获取失败就释放自己的锁重试：

private final Lock childrenLock = new ReentrantLock();
private final Lock parentsLock = new ReentrantLock();

addChild(IEntity child) {
    boolean acquiredSelf = false;
    boolean acquiredChild = false;
    try {
        // 先尝试获取自己的锁
        acquiredSelf = childrenLock.tryLock(100, TimeUnit.MILLISECONDS);
        if (!acquiredSelf) return getChildren();
        
        // 再尝试获取子实例的锁（需要子实例也用ReentrantLock并暴露锁对象）
        Lock childParentsLock = ((MyEntity)child).getParentsLock();
        acquiredChild = childParentsLock.tryLock(100, TimeUnit.MILLISECONDS);
        if (!acquiredChild) return getChildren();
        
        // 执行添加逻辑
        if (!getChildren().contains(child)) {
            getChildren().add(child);
            child.addParent(this);
        }
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    } finally {
        if (acquiredChild) childParentsLock.unlock();
        if (acquiredSelf) childrenLock.unlock();
    }
    return getChildren();
}

这个方案的缺点是复杂度高，需要各个IEntity实现都配合暴露锁对象，而且重试逻辑可能会影响性能，但好处是能在不修改接口核心方法的前提下避免死锁。

总结建议 #

• 如果能修改接口：优先选择扩展接口添加重载方法的方案，逻辑简单、性能好，还能统一规范所有实现。
• 不能修改接口：选择固定顺序锁实例的方案，同时和所有IEntity实现方约定好锁规则，禁止外部随意锁实例。
• 并发量极低：全局锁可以凑合用，但不推荐长期使用。

备注：内容来源于stack exchange，提问作者user25308907