面试回答 CopyOnWrite 的三重境界，1%的人能答到最后

V-xin：ruyuanhadeng获得600+页原创精品文章汇总PDF

目录

• 1.读多写少的场景下引发的问题？
• 2.引入 CopyOnWrite 思想解决问题！
• 3.CopyOnWrite思想在Kafka源码中的运用

今天聊一个非常硬核的技术知识，给大家分析一下CopyOnWrite思想是什么，以及在Java并发包中的具体体现，包括在Kafka内核源码中是如何运用这个思想来优化并发性能的。

这个CopyOnWrite在面试的时候，很可能成为面试官的一个杀手锏把候选人给一击必杀，也很有可能成为候选人拿下Offer的独门秘籍，是相对高级的一个知识。

---

1、读多写少的场景下引发的问题？

大家可以设想一下现在我们的内存里有一个ArrayList，这个ArrayList默认情况下肯定是线程不安全的，要是多个线程并发读和写这个ArrayList可能会有问题。

好，问题来了，我们应该怎么让这个ArrayList变成线程安全的呢？

有一个非常简单的办法，对这个ArrayList的访问都加上线程同步的控制。

比如说一定要在synchronized代码段来对这个ArrayList进行访问，这样的话，就能同一时间就让一个线程来操作它了，或者是用ReadWriteLock读写锁的方式来控制，都可以。

我们假设就是用ReadWriteLock读写锁的方式来控制对这个ArrayList的访问。

这样多个读请求可以同时执行从ArrayList里读取数据，但是读请求和写请求之间互斥，写请求和写请求也是互斥的。

大家看看，代码大概就是类似下面这样：

public Object read() {
    lock.readLock().lock();
    // 对ArrayList读取
    lock.readLock().unlock();
}

public void write() {
    lock.writeLock().lock();
    // 对ArrayList写
    lock.writeLock().unlock();
}

大家想想，类似上面的代码有什么问题呢？

最大的问题，其实就在于写锁和读锁的互斥。假设写操作频率很低，读操作频率很高，是写少读多的场景。

那么偶尔执行一个写操作的时候，是不是会加上写锁，此时大量的读操作过来是不是就会被阻塞住，无法执行？

<