共计 1361 个字符，预计需要花费 4 分钟才能阅读完成。
一、场景
当咱们在多线程的环境下操作一个汇合，比方 ArrayList 或者 Hashmap，这些汇合默认状况下必定是线程不平安的，如果说多个线程同时去读和写这些汇合就会有线程平安问题。
好，问题来了，咱们应该怎么让一个汇合变成线程平安的呢？
二、synchronized 或者 lock 锁
有一个非常简单的方法，对这些汇合的拜访都加上线程同步的管制，或者说是加锁。
这里能够去另一篇文章看一下 Synchronized 和 lock 锁的原理简述 synchronized 和 lock 锁
最简略的做法就是加一个 Synchronized 或者 Lock 锁。
咱们假如就是用 ReadWriteLock 读写锁的形式来管制对这些汇合的拜访。
这样多个读申请能够同时执行从这些汇合里读取数据，然而读申请和写申请之间互斥，写申请和写申请也是互斥的。
public Object read() {
lock.readLock().lock();
// 对汇合的读操作
lock.readLock().unlock();
}
public void write() {
lock.writeLock().lock();
// 对汇合的写操作
lock.writeLock().unlock();
}
大家想想，相似下面的代码有什么问题呢？
最大的问题，其实就在于写锁和读锁的互斥。假如写操作频率很低，读操作频率很高，是写少读多的场景。
那么偶然执行一个写操作的时候，是不是会加上写锁，此时大量的读操作过去是不是就会被阻塞住，无奈执行？大数据培训
这个就是读写锁可能遇到的最大的问题。
三、从 kafka 源码获取灵感
kafka 实现了一个 CopyOnWriteMap 解决了下面的一系列问题，这个 CopyOnWriteMap 采纳的是 CopyOnWrite 思维，它是一种相似于读写拆散的思维。
咱们来看一下这个 CopyOnWriteMap 的源码实现：
// 典型的 volatile 润饰一般 Map
private volatile Map map;
@Override
public synchronized V put(K k, V v) {
// 更新的时候先创立正本，更新正本，而后对 volatile 变量赋值写回去
Map copy = new HashMap(this.map);
V prev = copy.put(k, v);
this.map = Collections.unmodifiableMap(copy);
return prev;
}
@Override
public V get(Object k) {
// 读取的时候间接读 volatile 变量援用的 map 数据结构，无需锁
return map.get(k);
}
如果你是写操作（put）的话，它会先去创立一个正本，而后对这个正本用 syn 锁，这样就能确保一次只能有一个线程去批改这个正本，而读操作（get），间接不加锁，因为不论多少个线程读，对数据都没有影响，这样就既能保障读写的线程平安，又能极大晋升性能！
而他这里最精妙的中央在于，如何确保你读到的都是最新的数据呢？他这里应用了 volatile 润饰这个 map，volatile 是确保多线程环境下的可见性问题，那么当咱们写操作更新了这个正本，它就会马上更新咱们读的那个数据，这样就解决了读写拆散最难的同步数据问题！
