我们的旧版应用程序陷入了一个可怕的框架(好吧，我要命名，它是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 );
}
}
最佳答案
这是优化的问题。 Swing的EventListenerList假定:
在这些假设的基础上，添加和删除项目的计算成本可以忽略不计，但是将这些列表放在身边的内存成本可能是巨大的。这就是
EventListenerList通过分配一个足够大以容纳侦听器的数组来工作的原因，从而使内存占用最小。 (As the docs note，直到添加第一个侦听器，它才分配任何东西，以确保没有侦听器时不会浪费空间。)这样做的缺点是，每次添加新元素时，它都会重新分配数组并复制所有旧元素，如果侦听器过多，则会给您带来天文数字的损失。(实际上，它并没有达到尽可能高的内存效率；该列表是{Type，Listener}对，因此，如果它是一个数组数组，则在某些情况下会稍微小一些。)
至于您的解决方案:
HashMap过度分配内存以确保有效的哈希。同样，默认的ArrayList构造函数为10个元素分配空间并逐块增长。在每个列表中有100k侦听器的奇异代码库中，此额外的内存是用于容纳所有侦听器的内存的微小添加。但是，在较小的侦听器负载下，您的实现会为每个空列表(默认分配
HashMap)花费16个指针，为一个元素包含一个EventListenerMap分配26个指针，为包含两个不同类元素的映射分配36个指针。 (这没有计算HashMap和ArrayList结构大小的其余部分。)对于相同的情况，EventListenerList分别花费0、2和4指针。您所拥有的代码似乎有了巨大的改进。