16

我们的旧版应用程序陷入了一个糟糕的框架（好吧，我会说出名字，它是 Tapestry 4），EventListeners对于最简单的操作，它涉及的数量非常可笑（~100,000）。我猜这超出了我们javax.swing.event.EventListenerList本来可以处理的范围，在这个不幸的用例中，它给我们带来了一些令人讨厌的性能问题。

我花了几个小时在下面掀起了相当幼稚HashMap/ArrayList的替换，它几乎在所有方面都快得多：

添加 50,000 个听众：

  • EventListenerList> 2 秒
  • EventListenerMap~ 3.5 毫秒

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

  • EventListenerList0.3-0.5毫秒
  • EventListenerMap0.4-0.5毫秒

删除 50,000 个听众（一次一个）：

  • EventListenerList> 2 秒
  • EventListenerMap~280 毫秒

射击可能只是慢了一点，但修改速度要快得多。诚然，这个框架给我们带来的情况是病态的，但它似乎仍然EventListenerList可以在很久以前被取代。显然，公共 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 );
    }
}
4

1 回答 1

5

这是一个优化问题。Swing 的 EventListenerList 假设：

  • 列表中的 Listeners 数量非常少
  • ListenerList 的数量可能非常大
  • 添加/删除事件非常罕见

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

（实际上，它的内存效率并不高；列表是 {Type,Listener} 对，所以如果它是一个数组数组，在某些情况下它会稍微小一些。）

至于您的解决方案：HashMaps 过度分配内存以确保高效散列。同样，默认ArrayList构造函数为 10 个元素分配空间并以块的形式增长。在您奇怪的代码库中，每个列表上有 10 万个侦听器，这个额外的内存是您用来容纳所有侦听器的内存的一小部分。

但是，在较轻的 Listener 负载下，您的实现需要为每个空列表（默认分配HashMap）消耗 16 个指针，为具有一个元素的 an 消耗 26 个指针，EventListenerMap为具有不同类的两个元素的映射消耗 36 个指针。（这不包括其余的HashMap和ArrayList结构大小。）对于这些相同的情况，EventListenerList分别花费 0、2 和 4 个指针。

对于您拥有的代码，这似乎是一个巨大的改进。

于 2013-07-05T13:23:33.920 回答