我是否应该同步监听器通知？

Question

我总是很犹豫是否要把我的锁公开，公开。我总是尝试将锁限制在我的实现范围内。我相信，不这样做就会导致僵局。

我有以下课程：

class SomeClass {
    protected ArrayList<Listener> mListeners = new ArrayList<Listener>();

    protected void addListener(Listener listener) {
        synchronized (mListeners) {
            mListeners.add(listener);
        }
    }

    protected void removeListener(Listener listener) {
        synchronized (mListeners) {
            mListeners.remove(listener);
        }
    }

    ...
}

当 SomeClass 想要通知他的听众时，你会这样做吗：

    synchronized (mListeners) {
        for (Listener l : mListeners) {
             l.event();
        }
    }

或者

    Listener[] listeners = null;
            
    synchronized (mListeners) {
        listeners = mListeners.toArray();
    }
    for (Listener l : listeners) {
        l.event();
    }

我会选择第二个选项。缺点是监听器可以获取事件，即使它们已经未注册。好处是，等待侦听器回调的线程在想要取消注册侦听器时不会陷入死锁。我相信好处比坏处更重要，这很容易记录下来。

所以这里的问题基本上是：你会暴露你的锁吗？

我的问题不是你是否会选择一个普通的 ArrayList、一个 LinkedList、一个 ConcurrentLinkedQueue、一个 CopyOnWriteArrayList、一个...！这是您是否介意侦听器在未注册时可以获得通知。问题在于你是否愿意把锁打开。这是为了避免僵局，或者不是。

请分享您的想法。谢谢！

Answer 1

对侦听器数组使用CopyOnWriteArrayList。

这非常适合不经常更改的侦听器数组。当您迭代它们时，您正在迭代底层数组。使用CopyOnWriteArrayList，每次修改该数组时都会复制该数组。因此，迭代时无需与其同步，因为每个底层数组都保证是静态的，即使在 CopyOnWriteArrayList 中使用它也是如此。

由于 CopyOnWriteArrayList 也是线程安全的，因此您不需要同步 add & 操作。删除操作。

声明：

private final CopyOnWriteArrayList<Listener> listeners;

事件触发：

for (Listener l: this.listeners) {
  l.event();
}

Answer 2

我想我也会选择第二个选项。就像我认为你说的那样，第二个选项在通知听众时不会保持锁定。因此，如果其中一个侦听器需要很长时间才能完成其操作，其他线程仍然可以调用 addListener 或 removeListener 方法，而无需等待锁被释放。

Answer 3

有几种可用的数据结构允许并发添加、删除和迭代

ConcurrentLinkedQueue 是完全无锁的，并且添加和删除速度很快（禁止 O(n) 遍历来找到它）和添加，但可能存在其他线程的一些干扰（批量删除可能只是部分可见）到迭代器）

copyOnWrite 列表和 set 在 add 和删除，因为它们需要数组分配和复制，但是迭代完全不受干扰，并且与遍历相同大小的 ArrayList 一样快（迭代发生在集合的快照上），

您可以在 ConcurrentHashMap但是除了快速 O(1) 删除以及用于添加和删除的锁之外，它还具有相同的（有用）属性

Answer 4

我会使用 ConcurrentLinkedQueue是为此类问题而设计的：在集合上同时添加、删除和迭代。

精度：此解决方案可防止侦听器从注销的那一刻起就被调用。该解决方案具有最好的准确性、最细的粒度，并且可能是最不易出现死锁的解决方案。

如果您坚持您的两个建议，我会选择第一个，因为它更安全，但它可能会引发更长的锁定并降低整体性能（这取决于您添加或删除侦听器的频率）。第二个解决方案已被破坏，因为当侦听器自行注销时，很可能是因为他无法处理事件。在这种情况下，调用它将是一个非常糟糕的主意，并且无论如何这都会违反监听器契约。