为什么没有更换EventListenerList？(或者说:更换它有什么陷阱？)

Question

我们的传统的应用程序被套牢,涉及的荒谬数量可怕的框架(好吧,我会指名道姓,它的挂毯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可以在很久以前被取代.显然,公共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假定:

• 列表中的监听器数量非常少
• ListenerLists的数量可能非常大
• 添加/删除事件非常罕见

考虑到这些假设,添加和删除项目的计算成本可以忽略不计,但是使用这些列表的内存成本可能很高.这就是为什么EventListenerList通过分配一个足够大的数组来容纳监听器,从而具有尽可能小的内存占用量.(正如文档所说,在添加第一个Listener之前,它甚至不会分配任何东西,以确保在没有监听器的情况下不会浪费空间.)这样做的缺点是每次添加新元素时,它会重新分配数组并复制所有旧元素,当你有太多的听众时会给你带来天文成本.

(实际上,它并不像内存效率那么高;列表是{Type,Listener}对,所以如果它是一个数组数组,在某些情况下它会稍微小一些.)

至于你的解决方案:HashMap过度分配内存以确保有效的散列.同样,默认ArrayList构造函数为10个元素分配空间并以块的形式增长.在你的奇怪的代码库中,每个列表上有100k个监听器,这个额外的内存是你用来容纳所有监听器的内存的一个小小的补充.

但是,在较轻的侦听器负载下,对于每个空列表(默认分配HashMap),您的实现需要16个指针,对于EventListenerMap具有一个元素的一个,需要26 个指针,对于具有两个不同类的元素的地图,需要36个指针.(这不计算其余部分HashMap和ArrayList结构大小.)对于同样的情况,分别EventListenerList花费0,2和4个指针.

对于你所拥有的代码来说,这似乎是一个巨大的进步.