java - 为什么 EventListenerList 没有被替换？ (或 : what are the pitfalls in replacing it? )

Question

我们的遗留应用程序受制于一个可怕的框架(好吧，我会说出名字，它是 Tapestry 4)，该框架涉及荒谬数量的 EventListeners(约 100,000 个)用于最简单的操作。我猜这超出了 javax.swing.event.EventListenerList 原本打算处理的范围，在这个不幸的用例中，它给我们带来了一些令人讨厌的性能问题。

我花了几个小时来完成下面基于 HashMap/ArrayList 的相当幼稚的替换，它几乎在所有方面都快得多:

添加 50,000 个听众:

• EventListenerList > 2 秒
• EventListenerMap ~ 3.5 毫秒

向 50,000 名听众触发事件:

• EventListenerList 0.3-0.5 毫秒
• EventListenerMap 0.4-0.5 毫秒

删除 50,000 个听众(一次一个):

• EventListenerList > 2 秒
• EventListenerMap ~280 毫秒

发射可能只是慢了一点点，但修改速度要快得多。不可否认，这个框架让我们陷入的境地是病态的，但看起来 EventListenerList 早就可以被替换掉了。显然，公共(public) API 存在问题(例如，它公开了其原始内部状态数组)，但肯定不止于此。也许在多线程情况下 EventListenerList 更安全或更高效？

public class EventListenerMap
{

    private final ReadWriteLock lock = new ReentrantReadWriteLock();
    private final Lock readLock = lock.readLock();
    private final Lock writeLock = lock.writeLock();

    private Map<Class, List> llMap = new HashMap<Class, List>();

    public <L extends EventListener> void add ( Class<L> listenerClass, L listener )
    {
        try
        {
            writeLock.lock();
            List<L> list = getListenerList( listenerClass );
            if ( list == null )
            {
                list = new ArrayList<L>();
                llMap.put( listenerClass, list );
            }
            list.add( listener );
        }
        finally
        {
            writeLock.unlock();
        }
    }

    public <L extends EventListener> void remove ( Class<L> listenerClass, L listener )
    {
        try
        {
            writeLock.lock();
            List<L> list = getListenerList( listenerClass );
            if ( list != null )
            {
                list.remove( listener );
            }
        }
        finally
        {
            writeLock.unlock();
        }
    }

    @SuppressWarnings("unchecked")
    public <L extends EventListener> L[] getListeners ( Class<L> listenerClass )
    {
        L[] copy = (L[]) Array.newInstance( listenerClass, 0 );
        try
        {
            readLock.lock();
            List<L> list = getListenerList( listenerClass );
            if ( list != null )
            {
                copy = (L[]) list.toArray( copy );
            }
        }
        finally
        {
            readLock.unlock();
        }
        return copy;
    }

    @SuppressWarnings("unchecked")
    private <L extends EventListener> List<L> getListenerList ( Class<L> listenerClass )
    {
        return (List<L>) llMap.get( listenerClass );
    }
}

Answer 1

这是一个优化问题。 Swing 的 EventListenerList 假定:

• 列表中的 Listener 数量很少
• ListenerList 的数量可能非常大
• 添加/删除事件的频率非常低

鉴于这些假设，添加和删除项目的计算成本可以忽略不计，但保留这些列表的内存成本可能会很大。这就是为什么 EventListenerList 通过分配一个足够大的数组来容纳 Listener 的原因，从而具有尽可能小的内存占用。 ( As the docs note ，在添加第一个 Listener 之前它甚至不分配任何东西，以确保在没有 Listener 的情况下不会浪费空间。)这样做的缺点是每次添加新元素时，它重新分配数组并复制所有旧元素，当您有太多听众时会给您带来天文数字的成本。

(实际上，它并没有尽可能地节省内存；列表是 {Type,Listener} 对，所以如果它是一个数组数组，在某些情况下它会稍微小一些。)

至于您的解决方案:HashMap 过度分配内存以确保有效的散列。同样，默认的 ArrayList 构造函数为 10 个元素分配空间并以 block 的形式增长。在您奇怪的代码库中，每个列表上有 10 万个听众，这个额外的内存只是对您用来容纳所有听众的内存的微小补充。

不过，在较轻的 Listener 负载下，您的实现为每个空列表花费 16 个指针(HashMap 的默认分配)，为具有一个元素的 EventListenerMap 花费 26 个指针，以及 36 个指针，用于具有两个不同类的元素的映射。 (这不计算剩余的 HashMap 和 ArrayList 结构大小。)对于相同的情况，EventListenerList 成本为 0、2 和 4分别指点。

这似乎是对您现有代码的巨大改进。