Redisson项目中的LRUCacheMap并发修改问题分析与解决方案

问题背景

在Redisson项目(一个Java实现的Redis客户端)中，RedisExecutor类使用了一个名为CODECS的LRUCacheMap作为编解码器的缓存。这个缓存基于LinkedHashMap实现，采用了最近最少使用(LRU)的淘汰策略。然而在多线程环境下，当多个线程同时操作这个缓存时，会出现ConcurrentModificationException异常。

问题现象

当多个线程并行使用不同的编解码器时，LRUCacheMap缓存会出现并发修改异常。具体表现为：

1. 首先抛出ConcurrentModificationException，发生在LinkedHashMap的迭代器remove操作中
2. 随后由于异常处理流程中的connectionFuture为null，又抛出NullPointerException
3. 原始异常实际上被"吞没"，只能通过调试器才能发现

技术分析

LRUCacheMap实现机制

Redisson中的LRUCacheMap继承自AbstractCacheMap，内部使用LinkedHashMap作为存储结构。LinkedHashMap本身不是线程安全的，而Redisson的实现也没有添加足够的同步控制。

当缓存达到容量限制时，会触发onMapFull方法进行元素淘汰。这个方法会遍历LinkedHashMap并移除最旧的条目，这个过程中如果其他线程同时修改了Map结构，就会导致ConcurrentModificationException。

并发场景下的问题

在多线程环境下，以下操作序列可能导致问题：

1. 线程A开始执行淘汰过程，获取了LinkedHashMap的迭代器
2. 线程B同时插入新条目，修改了Map结构
3. 线程A的迭代器继续执行remove操作，检测到结构变化，抛出异常

解决方案

Redisson项目维护者采用了以下解决方案：

1. 对LRUCacheMap的实现进行了修复，增加了必要的同步控制
2. 拒绝了使用Caffeine缓存库的建议，认为对于这个特定场景来说Caffeine过于重量级

技术选型考量

虽然Caffeine是一个高性能的现代缓存库，但Redisson团队认为：

1. 对于编解码器缓存这种小型任务，Caffeine的库体积过大
2. 维护一个专门优化的简单实现更符合项目需求
3. 在已知使用场景下，定制化实现可以提供足够的性能

最佳实践建议

对于类似场景的开发者，建议考虑：

1. 评估缓存的实际使用模式和并发需求
2. 对于小型、特定用途的缓存，定制实现可能更合适
3. 如果需要全面功能，现代缓存库如Caffeine或Guava Cache是更好的选择
4. 无论选择哪种方案，都要确保在多线程环境下的安全性

总结

Redisson项目通过修复其LRUCacheMap实现解决了并发修改问题，展示了在特定场景下轻量级定制解决方案的价值。这个问题也提醒我们，在使用缓存结构时，必须充分考虑线程安全性，特别是在高并发环境中。