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

Posted 2022-05-18 afin de

文章目录

• 场景
• 一、synchronized 或者lock锁
• 二、从kafka源码获取灵感

---

场景

当我们在多线程的环境下操作一个集合，比如 ArrayList或者Hashmap，这些集合默认情况下肯定是线程不安全的，如果说多个线程同时去读和写这些集合就会有线程安全问题。
好，问题来了，我们应该怎么让一个集合变成线程安全的呢？

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