多线程环境下的读写分离思想

一、场景

当我们在多线程的环境下操作一个集合，比如 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是确保多线程环境下的可见性问题，那么当我们写操作更新了这个副本，它就会马上更新我们读的那个数据，这样就解决了读写分离最难的同步数据问题！