字节2面真题，你能答对几道？

字节跳动的面试难度，放眼整个互联网都是“遥遥领先”！不能说有多难，就是看了都不会的哪种！当然，这句话是开玩笑的。

咱们先来看下字节二面的所有问题：

前半部分的问题比较简单，相信大部人都能搞定（如果你搞不定，可以偷偷去看磊哥的武林秘籍：https://www.javacn.site）。本文咱们就挑两个比较典型的问题来回答。

1.RDB 持久化会阻塞主线程吗？

注意这个问题有坑，这个问题千万别上来就说：“不会阻塞主线程”，这样回答只能拿到 50 分，压根都没过及格线，为什么呢？

因为 RDB 持久化是有可能会阻塞主线程的，因为 RDB 持久化有以下两种命令：

save：同步持久化 Redis。
bgsave：background save，后台保存的意思，也就是后台持久化 Redis。

默认情况下，如果不是手动执行“bgsave”命令，则会使用“save”命令来持久化 Redis，此时是会阻塞 Redis 主线程的。所以，这是一个不难，但很容易答错的问题。

2.说一下 Copy On Write 技术？

在市面上很少有面试官问 Java 程序员 COW（Copy On Write，写时复制）技术的，当然能回答上来的人也不多，那咱们就来看看什么是 COW？

Copy On Write（写时复制）是一种延迟复制的技术，用于在多个线程（或进程）之间共享资源时减少内存复制成本的。它的基本思想是，在创建拷贝或修改资源之前，不会真正的进行复制操作（懒汉模式），而是共享同一份资源的只读副本，直到某个线程（或进程）试图修改资源时，才会对资源进行复制操作。这种延迟复制的策略可以减少资源复制的开销，一定程度提高了性能和效率。

那它的使用场景有哪些呢？咱们继续来看。

2.1 Redis 中的 Copy On Write

单线程的 Redis 想要解决一边响应主线程的任务，一边持久化数据，依靠的就是 COW 技术，具体来说就是依赖系统的 fork 函数的 COW 实现的。

具体来说，COW 技术的使用过程是这样的：

在执行 RDB 持久化时，Redis 进程会 fork 一个子进程来执行持久化，该过程是阻塞的。
当 fork 过程完成后，父进程会继续接收客户端的命令。
此时子进程与 Redis 主进程共享内存中的数据，但是子进程并不会修改内存中的数据，而是不断的遍历读取并写入数据到磁盘，也就是持久化数据的过程。
然而 Redis 主进程则不一样，它需要响应客户端的命令，如果收到写入数据的操作请求，主进程就会使用 COW 机制将数据先复制再修改。
而此时，子进程使用的数据页并不会发生任何改变，依然是 fork 时的数据，继续进行持久化。

这就是 COW 技术在 Redis 中的使用。

2.2 Java 中的 Copy On Write

Java 中使用 COW 技术实在并发容器中，这种技术的实现容器有两个：CopyOnWriteArrayList 和 CopyOnWriteArraySet。

这两个集合是这样使用 COW 技术的，当有数据写入操作时，会先复制一个新数组进行操作，等写完之后，再将原数组的地址赋值成新数组，以 CopyOnWriteArrayList 的 add 实现为了，它的实现源码如下：

public boolean add(E e) {
    final ReentrantLock lock = this.lock;
    lock.lock();
    try {
        // 获取老数组
        Object[] elements = getArray();
        int len = elements.length;
        
        // 复制出新数组
        Object[] newElements = Arrays.copyOf(elements, len + 1);
        
        // 添加元素到新数组中
        newElements[len] = e;
        
        // 把原数组引用指向新数组
        setArray(newElements);
        return true;
    } finally {
        lock.unlock();
    }
}

从上述代码可以看出，在添加的时候也会使用锁，如果不使用锁的话，在多线程写入时，可能会出现多个副本。

而加锁之后，会先复制一个新数组，进行写入操作，之后再将原数组指向新数组，整个添加操作执行完了。

当然，这两个容器只适合多读少写的场景，因为每次写入操作都要加锁和复制新数组进行操作，这些操作的性能开销都是很大的。