spring烂设计之DefaultSubscriptionRegistry DestinationCache

spring也不是万能的

spring实现了STOMP协议，在用simpbroker时，当在线或者说订阅数非常大的时候，DestinationCache getSubscriptions非常慢，几乎所有线程都卡在那了，看了一会源码...发现这个设计真是烂

里面有两个cache，accessCache、updateCache：Map from destination -> <sessionId, subscriptionId>，因为要保证线程安全，所以第二个cache完全是用来加锁同步的，因为不想读取的时候加锁，所以释放第一个cache，只在写入的时候锁第二个cache，可以说是一种用空间换时间的方法。但是...当并发量很大的时候，第一次读取，注意是第一次读取，有这样一段代码：

for (SessionSubscriptionInfo info : subscriptionRegistry.getAllSubscriptions())

居然for循环便利所有在线session，然后找出符合destination条件的session，加入cache，所以你可以想了，当在线session非常多，这时候有一个人上线了，开始聊天，产生查询，缓存中没有，然后就开始便利所有session.......

而且这段代码是在updateCache对象锁中的，你可以想象新上线的用户用起来会多慢！

应该把所有 destination -> <sessionId, subscriptionId>在上线订阅的时候就存储在cache里，不要在读取的时候才放进去，session下线全部清除，这样既简单又高效！