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之所以被认为能够避免并发修改异常，主要有两个原因：

1. 使用外部变量暂存修改，forEach只读不改

2. 使用严格的函数式编程规范，不修改外部状态

但实际上，如果在forEach中直接修改集合，问题仍然存在。

相比forEach,使用普通for循环甚至更好，因为可以在修改前用实际大小预先拷贝一次集合。

所以forEach本质上不能避免并发修改异常，需要通过保存修改至外部变量等方式进行规避。

更好的实践是：

1. 在修改前拷贝一次集合防止影响

2. 使用stream流水线处理，避免状态共享

3. 外部保存修改，forEach只读不改

2. Redisson

对于Redisson的RMap，其forEach方法可以避免并发修改异常。

RMap的forEach方法使用了乐观锁的机制，可以确保并发修改时的线程安全。

简单来说，它的实现原理是：

1. 在forEach遍历时，会获取一个乐观锁

2. 如果在遍历过程中，有其他线程修改了RMap,这会导致锁失效

3. 一旦锁失效，forEach会自动重新traverse，重新获取新的锁

4. 这样可以保证遍历过程中任何修改都不会导致并发异常

例如：

RMap<String, Integer> map = redisson.getMap("test");map.forEach((k, v) -> {// 在foreach时删除或修改mapmap.remove(k); 
}); 

以上代码是安全的，不会产生并发修改异常。

所以RMap的forEach方法通过乐观锁实现了对并发修改的安全遍历，我们可以在forEach里面改变RMap而不用担心线程安全问题。

这是与JDK集合不同的一点，对于Redis数据结构的遍历，Redisson提供了更好的并发控制。

除了RMap，Redisson还在其他数据结构提供了更优秀的并发控制机制：

1. RLock - 红锁,基于Redis的分布式锁,确保线程安全
2. RReadWriteLock - 读写锁,实现了自动扩展的锁
3. RSemaphore - 信号量,基于Redis的语义
4. RCountDownLatch - 分布式闭锁
5. RSet - 并发Set,基于Redis的Set增强
6. RQueue - 阻塞队列,可以监听元素事件
7. RBlockingQueue - 带超时的阻塞队列
8. RBlockingFairQueue - 公平阻塞队列
9. RTopic - 发布订阅,支持集群
10. RBatch - 支持异步批量命令

Redisson扩展了很多JDK并发工具类和集合接口，基于Redis提供了分布式下的强一致性语义实现。

所以在分布式环境使用Redisson，可以简化很多并发与同步的难点，比如分布式锁、闭锁、信号量等。