Redisson提供优秀的并发控制机制
1. JDK集合类
对于JDK的集合类，forEach方法其实并不能完全避免并发修改异常。
forEach本质上还是一个循环遍历，如果在循环体内直接对集合进行修改，仍然会产生ConcurrentModificationException。
例如：
List<String> list = new ArrayList<>();list.add("a");
list.add("b");list.forEach(item -> {if("a".equals(item)){list.remove(item); // 会出错}
});
这段代码在forEach中直接修改了list，仍会抛出并发修改异常。
forEach之所以被认为能够避免并发修改异常，主要有两个原因：
-
使用外部变量暂存修改，forEach只读不改
-
使用严格的函数式编程规范，不修改外部状态
但实际上，如果在forEach中直接修改集合，问题仍然存在。
相比forEach,使用普通for循环甚至更好，因为可以在修改前用实际大小预先拷贝一次集合。
所以forEach本质上不能避免并发修改异常，需要通过保存修改至外部变量等方式进行规避。
更好的实践是：
-
在修改前拷贝一次集合防止影响
-
使用stream流水线处理，避免状态共享
-
外部保存修改，forEach只读不改
2. Redisson
对于Redisson的RMap，其forEach方法可以避免并发修改异常。
RMap的forEach方法使用了乐观锁的机制，可以确保并发修改时的线程安全。
简单来说，它的实现原理是：
-
在forEach遍历时，会获取一个乐观锁
-
如果在遍历过程中，有其他线程修改了RMap,这会导致锁失效
-
一旦锁失效，forEach会自动重新traverse，重新获取新的锁
-
这样可以保证遍历过程中任何修改都不会导致并发异常
例如：
RMap<String, Integer> map = redisson.getMap("test");map.forEach((k, v) -> {// 在foreach时删除或修改mapmap.remove(k);
});
以上代码是安全的，不会产生并发修改异常。
所以RMap的forEach方法通过乐观锁实现了对并发修改的安全遍历，我们可以在forEach里面改变RMap而不用担心线程安全问题。
这是与JDK集合不同的一点，对于Redis数据结构的遍历，Redisson提供了更好的并发控制。
除了RMap，Redisson还在其他数据结构提供了更优秀的并发控制机制：
- RLock - 红锁,基于Redis的分布式锁,确保线程安全
- RReadWriteLock - 读写锁,实现了自动扩展的锁
- RSemaphore - 信号量,基于Redis的语义
- RCountDownLatch - 分布式闭锁
- RSet - 并发Set,基于Redis的Set增强
- RQueue - 阻塞队列,可以监听元素事件
- RBlockingQueue - 带超时的阻塞队列
- RBlockingFairQueue - 公平阻塞队列
- RTopic - 发布订阅,支持集群
- RBatch - 支持异步批量命令
Redisson扩展了很多JDK并发工具类和集合接口，基于Redis提供了分布式下的强一致性语义实现。
所以在分布式环境使用Redisson，可以简化很多并发与同步的难点，比如分布式锁、闭锁、信号量等。