1_Java 基础

1. String 的特点是什么？它有哪些重要的方法？

JDK 1.8 来说，String 内部实际存储结构为 char 数组

JDK 9 之后 String 的存储就从 char 数组转成了 byte 数组，这样做的好处是存储变的更紧凑，占用的内存更少，操作性能更高了。

 private final char value[];

String 源码中包含下面几个重要的方法。

1. 多构造方法

• String 为参数
• char[] 为参数
• StringBuffer、StringBuilder 为参数

2. equals() 比较两个字符串是否相等

String 类型重写了 Object 中的 equals() 方法，传递一个 Object 类型的参数值

0. 对象引用相同直接返回 true
1. 通过 instanceof 判断是否为 String 类型，如果不是则直接返回 false
2. 把两个字符串都转换为 char 数组循环比对每一个字符

3. compareTo() 比较两个字符串

compareTo() 方法用于比较两个字符串，返回的结果为 int 类型的值

循环对比所有的字符，当两个字符串中有任意一个字符不相同时，则 return char1-char2

比较 compareTo()方法和 equals() 方法

都是用于比较两个字符串的，但它们有两点不同：

• equals() 可以接收一个 Object 类型的参数，而 compareTo() 只能接收一个 String 类型的参数；
• equals() 返回值为 Boolean，而 compareTo() 的返回值则为 int。

4. 其他重要方法

• indexOf()：查询字符串首次出现的下标位置
• lastIndexOf()：查询字符串最后出现的下标位置
• contains()：查询字符串中是否包含另一个字符串
• toLowerCase()：把字符串全部转换成小写
• toUpperCase()：把字符串全部转换成大写
• length()：查询字符串的长度
• trim()：去掉字符串首尾空格
• replace()：替换字符串中的某些字符
• split()：把字符串分割并返回字符串数组
• join("-", strList)：把字符串数组、队列转为一个新[字符串]，用给定的定界符连接所有元素

知识扩展

• 为什么 String 类型要用 final 修饰？
• == 和 equals 的区别是什么？
• String 和 StringBuilder、StringBuffer 有什么区别？
• String 的 intern() 方法有什么含义？
• String 类型在 JVM（Java 虚拟机）中是如何存储的？编译器对 String 做了哪些优化？

0. 因为它能够缓存结果，当你在传参时不需要考虑谁会修改它的值；如果是可变类的话，则有可能需要重新拷贝出来一个新值进行传参，这样在性能上就会有一定的损失。

   当你在调用其他方法时，比如调用一些系统级操作指令之前，可能会有一系列校验，如果是可变类的话，可能在你校验过后，它的内部的值又被改变了，这样有可能会引起严重的系统崩溃问题，这是迫使 String 类设计成不可变类的一个重要原因。

   只有字符串是不可变时，我们才能实现字符串常量池，字符串常量池可以为我们缓存字符串，提高程序的运行效率

   它的 3 重点优势：1、可以利用不可变性实现字符串常量池；2、非常适合做 HashMap 的 key（因为不变）；3、天生线程安全。

   总结来说，使用 final 修饰的第一个好处是安全；第二个好处是高效

1. == 对于基本数据类型来说，是用于比较 “值”是否相等的；而对于引用类型来说，是用于比较引用地址是否相同的。

2. 因为 String 类型是不可变的，所以在字符串拼接的时候如果使用 String 的话性能会很低，StringBuffer，它提供了 append 和 insert 方法可用于字符串的拼接，它使用 synchronized 来保证线程安全,所以在非并发操作的环境下可使用 StringBuilder 来进行字符串拼接。

3. String#intern 是一个 native 方法，注释写的很详细，“如果常量池中存在当前字符串, 就会直接返回当前字符串. 如果常量池中没有此字符串, 会将此字符串放入常量池中后, 再返回”

4. String 常见的创建方式有两种，new String() 的方式 和 直接赋值的方式，直接赋值的方式会先去字符串常量池中查找是否已经有此值，如果有则把引用地址直接指向此值，否则会先在常量池中创建，然后再把引用指向此值；而 new String() 的方式一定会先在堆上创建一个字符串对象，然后再去常量池中查询此字符串的值是否已经存在，如果不存在会先在常量池中创建此字符串，然后把引用的值指向此字符串

   拼接了多个字符串,代码 "Ja"+"va" 被直接编译成了 "Java",这就是编译器对字符串优化的结果。

5. 如果是这样 final 的参数 private static void upString(final String str) 就不能修改了，而非 fianl 是可以修改的。

2. HashMap 底层实现原理是什么？JDK8 做了哪些优化？

JDK 1.7 中 HashMap 是以数组加链表的形式组成的

JDK 1.8 之后新增了红黑树的组成结构，只有当链表长度大于8而且哈希表的长度大于64时,才会进行链表转化为红黑树的操作链表结构会转换成红黑树结构 ,之所以添加红黑树是因为一旦链表过长，会严重影响 HashMap 的性能，而红黑树具有快速增删改查的特点，这样就可以有效的解决链表过长时操作比较慢的问题。

知识扩展

和 HashMap 相关的面试题还有以下几个：

• 计算 Index 下标细节
• JDK 1.8 HashMap 扩容时做了哪些优化？
• 加载因子为什么是 0.75？
• 当有哈希冲突时，HashMap 是如何查找并确认元素的？
• HashMap 源码中有哪些重要的方法？
• HashMap 是如何导致死循环的？

1. HashMap采用链地址法，,HashMap将高16位与低16位进行异或，这样可以保证高位的数据也参与到与运算中来，以增大索引的散列程度，让数据分布得更为均匀,hash & (size - 1),容量设置为2的n次方主要是可以用位运算实现取模运算，位运算采用内存操作，且能解决负数问题；同时hashlength-1时，length-1为奇数的二进制都为1，index的结果就等同与hashcode后几位，只要hashcode均匀，那么hash碰撞就少

2. JDK 1.8 在扩容时并没有像 JDK 1.7 那样，重新计算每个元素的哈希值，而是通过高位运算（e.hash & oldCap）来确定元素是否需要移动，为0放低位，否则高位，低位位置不变，高位位置=原位置+原容量

3. 用来判断什么时候进行扩容的，假如加载因子是 0.5，HashMap 的初始化容量是 16，那么当 HashMap 中有 16*0.5=8 个元素时，HashMap 就会进行扩容。

   加载因子为什么是 0.75 而不是 0.5 或者 1.0 呢？这其实是出于容量和性能之间平衡的结果：

   • 当加载因子设置比较大的时候，扩容的门槛就被提高了，扩容发生的频率比较低，占用的空间会比较小，但此时发生 Hash 冲突的几率就会提升，因此需要更复杂的数据结构来存储元素，这样对元素的操作时间就会增加，运行效率也会因此降低；
   • 而当加载因子值比较小的时候，扩容的门槛会比较低，因此会占用更多的空间，此时元素的存储就比较稀疏，发生哈希冲突的可能性就比较小，因此操作性能会比较高。

   所以综合了以上情况就取了一个 0.5 到 1.0 的平均数 0.75 作为加载因子。

4. 当哈希冲突时我们需要通过判断 key 值是否相等，才能确认此元素是不是我们想要的元素。

5. HashMap 源码中三个重要方法：查询、新增和数据扩容。

6. 发生死循环的原因是 JDK 1.7 链表插入方式为首部倒序插入，这个问题在 JDK 1.8 得到了改善，变成了尾部正序插入。有人曾经把这个问题反馈给了 Sun 公司，但 Sun 公司认为这不是一个问题，因为 HashMap 本身就是非线程安全的，如果要在多线程下，建议使用 ConcurrentHashMap 替代

新增方法的执行流程，如下图所示：

3. 线程的状态有哪些？它是如何工作的？

线程（Thread）是程序执行的最小单元，它依托进程而存在。

一个进程中可以包含多个线程，多线程可以共享一块内存空间和一组系统资源，因此线程之间的切换更加节省资源、更加轻量化，也因此被称为轻量级的进程。

总共包含以下 6 个状态：

• NEW，新建状态，线程被创建出来，但尚未启动时的线程状态；
• RUNNABLE，就绪状态，表示可以运行的线程状态，它可能正在运行，或者是在排队等待操作系统给它分配 CPU 资源；
• BLOCKED，阻塞等待锁的线程状态，表示处于阻塞状态的线程正在等待监视器锁，比如等待执行 synchronized 代码块或者使用 synchronized 标记的方法；
• WAITING，等待状态，一个处于等待状态的线程正在等待另一个线程执行某个特定的动作，比如，一个线程调用了 Object.wait() 方法，那它就在等待另一个线程调用 Object.notify() 或 Object.notifyAll() 方法；
• TIMED_WAITING，计时等待状态，和等待状态（WAITING）类似，它只是多了超时时间，比如调用了有超时时间设置的方法 Object.wait(long timeout) 和 Thread.join(long timeout) 等这些方法时，它才会进入此状态；
• TERMINATED，终止状态，表示线程已经执行完成。

线程的工作模式是，首先先要创建线程并指定线程需要执行的业务方法，然后再调用线程的 start() 方法，此时线程就从 NEW（新建）状态变成了 RUNNABLE（就绪）状态，此时线程会判断要执行的方法中有没有 synchronized 同步代码块，如果有并且其他线程也在使用此锁，那么线程就会变为 BLOCKED（阻塞等待）状态，当其他线程使用完此锁之后，线程会继续执行剩余的方法。

当遇到 Object.wait() 或 Thread.join() 方法时，线程会变为 WAITING（等待状态）状态，如果是带了超时时间的等待方法，那么线程会进入 TIMED_WAITING（计时等待）状态，当有其他线程执行了 notify() 或 notifyAll() 方法之后，线程被唤醒继续执行剩余的业务方法，直到方法执行完成为止，此时整个线程的流程就执行完了

知识扩展

考点分析

线程一般会作为并发编程的起始问题，用于引出更多的关于并发编程的面试问题。当然对于线程的掌握程度也决定了你对并发编程的掌握程度，通常面试官还会问：

• BLOCKED（阻塞等待）和 WAITING（等待）有什么区别？
• start() 方法和 run() 方法有什么区别？
• 线程的优先级有什么用？该如何设置？
• 线程的常用方法有哪些？

接下来我们一起来看这些问题的答案。

1. 首先它们状态形成的调用方法不同，其次 BLOCKED 可以理解为当前线程还处于活跃状态，只是在阻塞等待其他线程使用完某个锁资源；而 WAITING 则是因为自身调用了 Object.wait() 或着是 Thread.join() 又或者是 LockSupport.park() 而进入等待状态，只能等待其他线程执行某个特定的动作才能被继续唤醒，比如当线程因为调用了 Object.wait() 而进入 WAITING 状态之后，则需要等待另一个线程执行 Object.notify() 或 Object.notifyAll() 才能被唤醒。

2. start() 方法属于 Thread 自身的方法，并且使用了 synchronized 来保证线程安全

   run() 方法为 Runnable 的抽象方法，必须由调用类重写此方法，重写的 run() 方法其实就是此线程要执行的业务方法

   从执行的效果来说，start() 方法可以开启多线程，让线程从 NEW 状态转换成 RUNNABLE 状态，而 run() 方法只是一个普通的方法。其次，它们可调用的次数不同，start() 方法不能被多次调用，否则会抛出 java.lang.IllegalStateException;而 run() 方法可以进行多次调用，因为它只是一个普通的方法而已。

3. 线程的优先级可以理解为线程抢占 CPU 时间片的概率，优先级越高的线程优先执行的概率就越大，但并不能保证优先级高的线程一定先执行。

4. 线程的常用方法有以下几个

• join()

  当前线程会让出执行权给 other 线程，直到 other 线程执行完或者过了超时时间之后再继续执行当前线程

• yield()

  表示给线程调度器一个当前线程愿意出让 CPU 使用权的暗示，但是线程调度器可能会忽略这个暗示。 yield() 执行非常不稳定，线程调度器不一定会采纳 yield() 出让 CPU 使用权的建议

4. ThreadPoolExecutor 的参数含义及源码执行流程？

线程池是为了避免线程频繁的创建和销毁带来的性能消耗，而建立的一种池化技术，它是把已创建的线程放入“池”中，当有任务来临时就可以重用已有的线程，无需等待创建的过程，这样就可以有效提高程序的响应速度。

在阿里巴巴的《Java 开发手册》中是这样规定线程池的： 线程池不允许使用 Executors 去创建，而是通过 ThreadPoolExecutor 的方式，这样的处理方式让写的读者更加明确线程池的运行规则，规避资源耗尽的风险。

说明：Executors 返回的线程池对象的弊端如下：

• FixedThreadPool 和 SingleThreadPool：允许的请求队列长度为 Integer.MAX_VALUE，可能会堆积大量的请求，从而导致 OOM。
• CachedThreadPool 和 ScheduledThreadPool：允许的创建线程数量为 Integer.MAX_VALUE，可能会创建大量的线程，从而导致 OOM

public ThreadPoolExecutor( int corePoolSize,
                           int maximumPoolSize,
                           long keepAliveTime,
                           TimeUnit unit,
                           BlockingQueue<Runnable> workQueue,
                           ThreadFactory threadFactory,
                           RejectedExecutionHandler handler ) {}

• 第 1 个参数：corePoolSize 表示线程池的常驻核心线程数。如果设置为 0，则表示在没有任何任务时，销毁线程池；如果大于 0，即使没有任务时也会保证线程池的线程数量等于此值。但需要注意，此值如果设置的比较小，则会频繁的创建和销毁线程（创建和销毁的原因会在本课时的下半部分讲到）；如果设置的比较大，则会浪费系统资源，所以开发者需要根据自己的实际业务来调整此值。
• 第 2 个参数：maximumPoolSize 表示线程池在任务最多时，最大可以创建的线程数。官方规定此值必须大于 0，也必须大于等于 corePoolSize，此值只有在任务比较多，且不能存放在任务队列时，才会用到。
• 第 3 个参数：keepAliveTime 表示线程的存活时间，当线程池空闲时并且超过了此时间，多余的线程就会销毁，直到线程池中的线程数量销毁的等于 corePoolSize 为止，如果 maximumPoolSize 等于 corePoolSize，那么线程池在空闲的时候也不会销毁任何线程。
• 第 4 个参数：unit 表示存活时间的单位，它是配合 keepAliveTime 参数共同使用的。
• 第 5 个参数：workQueue 表示线程池执行的任务队列，当线程池的所有线程都在处理任务时，如果来了新任务就会缓存到此任务队列中排队等待执行。
• 第 6 个参数：threadFactory 表示线程的创建工厂，此参数一般用的比较少，我们通常在创建线程池时不指定此参数，它会使用默认的线程创建工厂的方法来创建线程

    // 创建线程
    public Thread newThread(Runnable r) {
        Thread t = new Thread( group, r, namePrefix + threadNumber.getAndIncrement(), 0);
        return t;
    }

我们也可以自定义一个线程工厂，通过实现 ThreadFactory 接口来完成，这样就可以自定义线程的名称或线程执行的优先级了。

• 第 7 个参数：RejectedExecutionHandler 表示指定线程池的拒绝策略，当线程池的任务已经在缓存队列 workQueue 中存储满了之后，并且不能创建新的线程来执行此任务时，就会用到此拒绝策略，它属于一种限流保护的机制。

线程池的工作流程要从它的执行方法 execute() 说起

public void execute(Runnable command) {
    if (command == null) throw new NullPointerException();
    int c = ctl.get();
    // 当前工作的线程数小于核心线程数
    if (workerCountOf(c) < corePoolSize) {
        // 创建新的线程执行此任务
        if (addWorker(command, true)) return;
        c = ctl.get();
    }
    // 检查线程池是否处于运行状态，如果是则把任务添加到队列
    if (isRunning(c) && workQueue.offer(command)) {
        int recheck = ctl.get();
        // 再出检查线程池是否处于运行状态，防止在第一次校验通过后线程池关闭
        // 如果是非运行状态，则将刚加入队列的任务移除
        if (! isRunning(recheck) && remove(command)) reject(command);
        // 如果线程池的线程数为 0 时（当 corePoolSize 设置为 0 时会发生）
        else if (workerCountOf(recheck) == 0) addWorker(null, false); // 新建线程执行任务
    }
    // 核心线程都在忙且队列都已爆满，尝试新启动一个线程执行失败
    else if (!addWorker(command, false)) reject(command); // 执行拒绝策略
}

线程池任务执行的主要流程，可以参考以下流程图：

知识扩展

与 ThreadPoolExecutor 相关的面试题还有以下几个：

• ThreadPoolExecutor 的执行方法有几种？它们有什么区别？
• 什么是线程的拒绝策略？
• 拒绝策略的分类有哪些？
• 如何自定义拒绝策略？
• ThreadPoolExecutor 能不能实现扩展？如何实现扩展？

1. execute() VS submit()

execute() 和 submit() 都是用来执行线程池任务的，它们最主要的区别是，submit() 方法可以接收线程池执行的返回值，而 execute() 不能接收返回值。 来看两个方法的具体使用： submit() 方法可以配合 Futrue 来接收线程执行的返回值

ExecutorService executor = Executors.newFixedThreadPool(10);
        
// execute 使用
executor.execute(() -> System.out.println("Hello, execute.") );

// submit 使用
Future<String> future = executor.submit(() -> "Success");
System.out.println(future.get());

Future<String> future = executor.submit(new Callable<String>() {
    @Override
    public String call() throws Exception {
        return "Success";
    }
});

2. 线程池的拒绝策略

当线程池中的任务队列已经被存满，再有任务添加时会先判断当前线程池中的线程数是否大于等于线程池的最大值，如果是，则会触发线程池的拒绝策略。 Java 自带的拒绝策略有 4 种：

• AbortPolicy，终止策略，线程池会抛出异常并终止执行，它是默认的拒绝策略；
• CallerRunsPolicy，把任务交给当前线程来执行；
• DiscardPolicy，忽略此任务（最新的任务）；
• DiscardOldestPolicy，忽略最早的任务（最先加入队列的任务）。

ThreadPoolExecutor executor = new ThreadPoolExecutor(1, 3, 10,
        TimeUnit.SECONDS,
        new LinkedBlockingQueue<>(2),
        // 添加 AbortPolicy 拒绝策略
        new ThreadPoolExecutor.AbortPolicy()
);

for (int i = 0; i < 6; i ++) {
    executor.execute(() -> System.out.println(Thread.currentThread().getName()));
}

/*
pool-1-thread-1
pool-1-thread-3
pool-1-thread-2
pool-1-thread-3
pool-1-thread-1
Exception in thread "main" 
java.util.concurrent.RejectedExecutionException: Task JUC.future.OneFuture$$Lambda$1/1149319664@4dd8dc3 
rejected from java.util.concurrent.ThreadPoolExecutor@6d03e736
[Running, pool size = 3, active threads = 3, queued tasks = 2, completed tasks = 0]
*/

3. 自定义拒绝策略

自定义拒绝策略只需要新建一个 RejectedExecutionHandler 对象，然后重写它的 rejectedExecution() 方法即可，如下代码所示：

ThreadPoolExecutor executor = new ThreadPoolExecutor(1, 3, 10,
        TimeUnit.SECONDS, 
        new LinkedBlockingQueue<>(2),
        // 添加自定义拒绝策略
        new RejectedExecutionHandler() {  
            @Override
            public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
                // 业务处理方法
                System.out.println("执行自定义拒绝策略");
            }
        });
        
        // lambda 表达式
        (r, executor1) -> System.out.println("执行自定义拒绝策略"));

        executor.execute(() -> sout(Thread.currentThread().getName()));

4. ThreadPoolExecutor 扩展

ThreadPoolExecutor 的扩展主要是通过重写它的 beforeExecute() 和 afterExecute() 方法实现的，我们可以在扩展方法中添加日志或者实现数据统计，比如统计线程的执行时间，如下代码所示：

public static void main(String[] args) {
        // 线程池扩展调用
        MyThreadPoolExecutor executor = new MyThreadPoolExecutor(2, 4, 10,
                TimeUnit.SECONDS,
                new LinkedBlockingQueue());

        for (int i = 0; i < 3; i++) {
            executor.execute(() -> {
                Thread.currentThread().getName();
            });
        }
    }

    // 线程池扩展
    static class MyThreadPoolExecutor extends ThreadPoolExecutor {
        // 保存线程执行开始时间
        private final ThreadLocal<Long> localTime = new ThreadLocal<>();

        public MyThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime,TimeUnit unit, BlockingQueue<Runnable> workQueue) {
            super(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue);
        }
        // 开始执行之前 t 线程 r 任务
        @Override
        protected void beforeExecute(Thread t, Runnable r) {
            Long sTime = System.nanoTime(); // 开始时间 (单位：纳秒)
            localTime.set(sTime);
            System.out.println(String.format("%s | 开始执行 | time=%s", t.getName(), sTime));
            super.beforeExecute(t, r);
        }
        // 执行完成之后 r 任务 t 抛出的异常
        @Override
        protected void afterExecute(Runnable r, Throwable t) {
            Long eTime = System.nanoTime(); // 结束时间 (单位：纳秒)
            Long totalTime = eTime - localTime.get(); // 执行总时间
            System.out.println(String.format("%s | 结束执行 | time=%s | 耗时：%s 毫秒", Thread.currentThread().getName(), eTime, (totalTime / 1000000.0)));
            super.afterExecute(r, t);
        }
    }
pool-1-thread-1 | 开始执行 | time=64695267609600
pool-1-thread-2 | 开始执行 | time=64695267607500
pool-1-thread-2 | 结束执行 | time=64695281350900 | 耗时：13.7434 毫秒
pool-1-thread-1 | 结束执行 | time=64695281330300 | 耗时：13.7207 毫秒
pool-1-thread-2 | 开始执行 | time=64695283117300
pool-1-thread-2 | 结束执行 | time=64695283205100 | 耗时：0.0878 毫秒

小结

最后我们总结一下：线程池的使用必须要通过 ThreadPoolExecutor 的方式来创建，这样才可以更加明确线程池的运行规则，规避资源耗尽的风险。同时，也介绍了 ThreadPoolExecutor 的七大核心参数，包括核心线程数和最大线程数之间的区别，当线程池的任务队列没有可用空间且线程池的线程数量已经达到了最大线程数时，则会执行拒绝策略，Java 自动的拒绝策略有 4 种，用户也可以通过重写 rejectedExecution() 来自定义拒绝策略，我们还可以通过重写 beforeExecute() 和 afterExecute() 来实现 ThreadPoolExecutor 的扩展功能。

5. synchronized 和 ReentrantLock 的实现原理是什么？它们有什么区别

在 JDK 1.5 之前共享对象的协调机制只有 synchronized 和 volatile，在 JDK 1.5 中增加了新的机制 ReentrantLock，该机制的诞生并不是为了替代 synchronized，而是在 synchronized 不适用的情况下，提供一种可以选择的高级功能。

典型回答

synchronized 属于独占式悲观锁，是通过 JVM 隐式实现的，synchronized 只允许同一时刻只有一个线程操作资源。

在 Java 中每个对象都隐式包含一个 monitor（监视器）对象，加锁的过程其实就是竞争 monitor 的过程，当线程进入字节码 monitorenter 指令之后，线程将持有 monitor 对象，执行 monitorexit 时释放 monitor 对象，当其他线程没有拿到 monitor 对象时，则需要阻塞等待获取该对象。

ReentrantLock 是 Lock 的默认实现方式之一，它是基于 AQS（Abstract Queued Synchronizer，队列同步器）实现的，它默认是通过非公平锁实现的，在它的内部有一个 state 的状态字段用于表示锁是否被占用，如果是 0 则表示锁未被占用，此时线程就可以把 state 改为 1，并成功获得锁，而其他未获得锁的线程只能去排队等待获取锁资源。

synchronized 和 ReentrantLock 都提供了锁的功能，具备互斥性和不可见性。在 JDK 1.5 中 synchronized 的性能远远低于 ReentrantLock，但在 JDK 1.6 之后 synchronized 的性能略低于 ReentrantLock，它的区别如下：

• synchronized 是 JVM 隐式实现的，而 ReentrantLock 是 Java 语言提供的 API；
• ReentrantLock 可设置为公平锁，而 synchronized 却不行；
• ReentrantLock 只能修饰代码块，而 synchronized 可以用于修饰方法、修饰代码块等；
• ReentrantLock 需要手动加锁和释放锁，如果忘记释放锁，则会造成资源被永久占用，而 synchronized 无需手动释放锁；
• ReentrantLock 可以知道是否成功获得了锁，而 synchronized 却不行。

知识扩展

• ReentrantLock 的具体实现细节是什么？
• JDK 1.6 时锁做了哪些优化？

1. ReentrantLock 源码分析

• 公平锁由于有挂起和恢复所以存在一定的开销，因此性能不如非公平锁，所以 ReentrantLock 和 synchronized 默认都是非公平锁的实现方式。

• ReentrantLock 是通过 lock() 来获取锁，并通过 unlock() 释放锁

• ReentrantLock 中的 lock() 是通过 sync.lock() 实现的，但 Sync 类中的 lock() 是一个抽象方法，需要子类 NonfairSync 或 FairSync 去实现，非公平锁比公平锁只是多了一行 compareAndSetState 方法，该方法是尝试将 state 值由 0 置换为 1，如果设置成功的话，则说明当前没有其他线程持有该锁，不用再去排队了，可直接占用该锁，否则，则需要通过 acquire 方法去排队。

JDK 1.6 锁优化

• 自适应自旋锁

JDK 1.5 在升级为 JDK 1.6 时，HotSpot 虚拟机团队在锁的优化上下了很大功夫，比如实现了自适应式自旋锁、锁升级等。

JDK 1.6 引入了自适应式自旋锁意味着自旋的时间不再是固定的时间了，比如在同一个锁对象上，如果通过自旋等待成功获取了锁，那么虚拟机就会认为，它下一次很有可能也会成功 (通过自旋获取到锁)，因此允许自旋等待的时间会相对的比较长，而当某个锁通过自旋很少成功获得过锁，那么以后在获取该锁时，可能会直接忽略掉自旋的过程，以避免浪费 CPU 的资源，这就是自适应自旋锁的功能。

• 锁升级

锁升级其实就是从偏向锁到轻量级锁再到重量级锁升级的过程，这是 JDK 1.6 提供的优化功能，也称之为锁膨胀。 偏向锁是指在无竞争的情况下设置的一种锁状态。偏向锁的意思是它会偏向于第一个获取它的线程，当锁对象第一次被获取到之后，会在此对象头中设置标示为“01”，表示偏向锁的模式，并且在对象头中记录此线程的 ID，这种情况下，如果是持有偏向锁的线程每次在进入的话，不再进行任何同步操作，如 Locking、Unlocking 等，直到另一个线程尝试获取此锁的时候，偏向锁模式才会结束，偏向锁可以提高带有同步但无竞争的程序性能。但如果在多数锁总会被不同的线程访问时，偏向锁模式就比较多余了，此时可以通过 -XX:-UseBiasedLocking 来禁用偏向锁以提高性能。

轻量锁是相对于重量锁而言的，在 JDK 1.6 之前，synchronized 是通过操作系统的互斥量（mutex lock）来实现的，这种实现方式需要在用户态和核心态之间做转换，有很大的性能消耗，这种传统实现锁的方式被称之为重量锁。

而轻量锁是通过比较并交换（CAS，Compare and Swap）来实现的，它对比的是线程和对象的 Mark Word（对象头中的一个区域），如果更新成功则表示当前线程成功拥有此锁；如果失败，虚拟机会先检查对象的 Mark Word 是否指向当前线程的栈帧，如果是，则说明当前线程已经拥有此锁，否则，则说明此锁已经被其他线程占用了。当两个以上的线程争抢此锁时，轻量级锁就膨胀为重量级锁，这就是锁升级的过程，也是 JDK 1.6 锁优化的内容。

小结

本课时首先讲了 synchronized 和 ReentrantLock 的实现过程，然后讲了 synchronized 和 ReentrantLock 的区别，最后通过源码的方式讲了 ReentrantLock 加锁和解锁的执行流程。接着又讲了 JDK 1.6 中的锁优化，包括自适应式自旋锁的实现过程，以及 synchronized 的三种锁状态和锁升级的执行流程。

synchronized 刚开始为偏向锁，随着锁竞争越来越激烈，会升级为轻量级锁和重量级锁。如果大多数锁被不同的线程所争抢就不建议使用偏向锁了。

6. 谈谈你对锁的理解？如何手动模拟一个死锁？

在并发编程中有两个重要的概念：线程和锁，多线程是一把双刃剑，它在提高程序性能的同时，也带来了编码的复杂性，对开发者的要求也提高了一个档次。而锁的出现就是为了保障多线程在同时操作一组资源时的数据一致性，当我们给资源加上锁之后，只有拥有此锁的线程才能操作此资源，而其他线程只能排队等待使用此锁。 死锁的代码演示如下：

public class LockExample {
    public static void main(String[] args) {
        deadLock(); // 死锁
    }

    private static void deadLock() {
        Object lock1 = new Object();
        Object lock2 = new Object();
        
        // 线程一: 拥有 lock1 试图获取 lock2
        new Thread(() -> {
            synchronized (lock1) {
                sout("获取 lock1 成功");
                Thread.sleep(3);
                // 试图获取锁 lock2
                synchronized (lock2) {
                    System.out.println(Thread.currentThread().getName());
                }
            }
        }).start();
        
        // 线程二: 拥有 lock2 试图获取 lock1
        new Thread(() -> {
            synchronized (lock2) {
                sout("获取 lock2 成功");
                Thread.sleep(3);
                // 试图获取锁 lock1
                synchronized (lock1) {
                    System.out.println(Thread.currentThread().getName());
                }
            }
        }).start();
    }
}

知识扩展

和锁相关的面试问题，还有以下几个：

• 什么是乐观锁和悲观锁？它们的应用都有哪些？乐观锁有什么问题？
• 什么是可重入锁？用代码如何实现？它的实现原理是什么？
• 什么是共享锁和独占锁？

1. 悲观锁和乐观锁

• 悲观锁的实现流程，以 synchronized 为例

• 被 synchronized 修饰的代码块，在执行之前先使用 monitorenter 指令加锁，然后在执行结束之后再使用 monitorexit 指令释放锁资源，在整个执行期间此代码都是锁定的状态，这就是典型悲观锁的实现流程。

• Java 中的乐观锁大部分都是通过 CAS（Compare And Swap，比较并交换）操作实现的，CAS 是一个多线程同步的原子指令，CAS 操作包含三个重要的信息，即内存位置、预期原值和新值。如果内存位置的值和预期的原值相等的话，那么就可以把该位置的值更新为新值，否则不做任何修改。CAS 可能会造成 ABA 的问题,ABA 的常见处理方式是添加版本号，每次修改之后更新版本号

• JDK 在 1.5 时提供了 AtomicStampedReference 类也可以解决 ABA 的问题，此类维护了一个“版本号” Stamp，每次在比较时不止比较当前值还比较版本号，这样就解决了 ABA 的问题。

2. 可重入锁

• 可重入锁也叫递归锁，指的是同一个线程，如果外面的函数拥有此锁之后，内层的函数也可以继续获取该锁。在 Java 语言中 ReentrantLock 和 synchronized 都是可重入锁。可重入锁指的就是一个线程可以“重入”
• 可重入锁的实现原理，是在锁内部存储了一个线程标识，用于判断当前的锁属于哪个线程，并且锁的内部维护了一个计数器，当锁空闲时此计数器的值为 0，当被线程占用和重入时分别加 1，当锁被释放时计数器减 1，直到减到 0 时表示此锁为空闲状态。

3. 共享锁和独占锁

• 只能被单线程持有的锁叫独占锁，可以被多线程持有的锁叫共享锁。 独占锁指的是在任何时候最多只能有一个线程持有该锁，比如 synchronized 就是独占锁，而 ReadWriteLock 读写锁允许同一时间内有多个线程进行读操作，它就属于共享锁。
• 独占锁可以理解为悲观锁，当每次访问资源时都要加上互斥锁，而共享锁可以理解为乐观锁，它放宽了加锁的条件，允许多线程同时访问该资源。

7. 深克隆和浅克隆有什么区别？它的实现方式有哪些？

使用克隆可以为我们快速地构建出一个已有对象的副本

典型回答

浅克隆（Shadow Clone）是把原型对象中成员变量为值类型的属性都复制给克隆对象，把原型对象中成员变量为引用类型的引用地址也复制给克隆对象，也就是原型对象中如果有成员变量为引用对象，则此引用对象的地址是共享给原型对象和克隆对象的。

• 浅克隆只会复制原型对象，但不会复制它所引用的对象

• 深克隆（Deep Clone）是将原型对象中的所有类型，无论是值类型还是引用类型，都复制一份给克隆对象，也就是说深克隆会把原型对象和原型对象所引用的对象，都复制一份给克隆对象

• 在 Java 语言中要实现克隆则需要实现 Cloneable 接口，并重写 Object 类中的 clone() 方法

知识扩展

0. 在 java.lang.Object 中对 clone() 方法的约定有哪些？
1. Arrays.copyOf() 是深克隆还是浅克隆？
2. 深克隆的实现方式有几种？
3. Java 中的克隆为什么要设计成，既要实现空接口 Cloneable，还要重写 Object 的 clone() 方法？

Object 对 clone() 方法的约定有三条：

clone() 是使用 native 修饰的本地方法，因此执行的性能会很高，并且它返回的类型为 Object，因此在调用克隆之后要把对象强转为目标类型才行。

• 对于所有对象来说，x.clone() !=x 应当返回 true，因为克隆对象与原对象不是同一个对象；
• 对于所有对象来说，x.clone().getClass() == x.getClass() 应当返回 true，因为克隆对象与原对象的类型是一样的；
• 对于所有对象来说，x.clone().equals(x) 应当返回 true，因为使用 equals 比较时，它们的值都是相同的。

Arrays.copyOf()

• 如果是数组类型，我们可以直接使用 Arrays.copyOf() 来实现克隆
• Arrays.copyOf() 其实是一个浅克隆。 因为数组比较特殊数组本身就是引用类型，因此在使用 Arrays.copyOf() 其实只是把引用地址复制了一份给克隆对象，如果修改了它的引用对象，那么指向它的（引用地址）所有对象都会发生改变

People[] o1 = {new People(1, "Java")};
People[] o2 = Arrays.copyOf(o1, o1.length);
// 修改原型对象的第一个元素的值
o1[0].setName("Jdk");
o1:Jdk
o2:Jdk

深克隆实现方式汇总

Java 中实现克隆需要两个主要的步骤，一是 实现 Cloneable 空接口，二是重写 Object 的 clone() 方法再调用父类的克隆方法 (super.clone())

深克隆的实现方式有很多种，大体可以分为以下几类：

• 所有对象都实现克隆方法；
• 通过构造方法实现深克隆；
• 使用 JDK 自带的字节流实现深克隆；
• 使用第三方工具实现深克隆，比如 Apache Commons Lang；
• 使用 JSON 工具类实现深克隆，比如 Gson、FastJSON 等。

@Override
protected People clone() throws CloneNotSupportedException {
     People people = (People) super.clone();
     people.setAddress(this.address.clone()); // 引用类型克隆赋值
     return people;
}

8. 动态代理是如何实现的？JDK Proxy 和 CGLib 有什么区别？

动态代理是程序在运行期间动态构建代理对象和动态调用代理方法的一种机制。

典型回答

动态代理的常用实现方式是反射。反射机制是指程序在运行期间可以访问、检测和修改其本身状态或行为的一种能力，使用反射我们可以调用任意一个类对象，以及类对象中包含的属性及方法。

但动态代理不止有反射一种实现方式，例如，动态代理可以通过 CGLib 来实现，而 CGLib 是基于 ASM（一个 Java 字节码操作框架）而非反射实现的。简单来说，动态代理是一种行为方式，而反射或 ASM 只是它的一种实现手段而已。

JDK Proxy 和 CGLib 的区别主要体现在以下几个方面：

• JDK Proxy 是 Java 语言自带的功能，无需通过加载第三方类实现；
• JDK Proxy 是通过拦截器加反射的方式实现的, 实现和调用起来比较简单；
• JDK Proxy 只能代理继承接口的类；
• CGLib 是第三方提供的工具，基于 ASM 实现的，性能比较高；
• CGLib 无需通过接口来实现，它是通过实现子类的方式来完成调用的。
• Java 对 JDK Proxy 提供了稳定的支持，并且会持续的升级和更新 JDK Proxy，例如 Java 8 版本中的 JDK Proxy 性能相比于之前版本提升了很多；

知识扩展

• 你对 JDK Proxy 和 CGLib 的掌握程度。
• Lombok 是通过反射实现的吗？
  • Lombok 是在编译期就为我们生成了对应的字节码。
• 动态代理和静态代理有什么区别？
• 动态代理的使用场景有哪些？
• Spring 中的动态代理是通过什么方式实现的？

JDK Proxy 和 CGLib 的使用及代码分析

• JDK Proxy 动态代理实现

JDK Proxy 动态代理的实现无需引用第三方类，只需要实现 InvocationHandler 接口，重写 invoke() 方法即可. 在动态代理中有一个重要的角色也就是代理器，它用于统一管理被代理的对象，显然 InvocationHandler 就是这个代理器，而 invoke() 方法则是触发代理的执行方法，我们通过实现 Invocation 接口来拥有动态代理的能力。

public class test {
    static interface Car { void running();}

    static class Taxi implements Car {
        @Override
        public void running() { System.out.println("The taxi is running.");}
    }

    /**
     * JDK Proxy
     */
    static class JDKProxy implements InvocationHandler {

        // 代理对象
        private Object target;

        // 获取到代理对象
        public Object getInstance(Object target) {
            this.target = target;
            // 取得代理对象
            return Proxy.newProxyInstance(target.getClass().getClassLoader(),
                    target.getClass().getInterfaces(),
                    this);
        }

        /**
         * 执行代理方法
         *
         * @param proxy  代理对象
         * @param method 代理方法
         * @param args   方法的参数
         */
        @Override
        public Object invoke(Object proxy, Method method, Object[] args)
                throws InvocationTargetException, IllegalAccessException {
            System.out.println("befor");
            Object result = method.invoke(target, args); // 执行调用方法（此方法执行前后，可以进行相关业务处理）
            System.out.println("after");
            return result;
        }
    }

    public static void main(String[] args) {
        // 执行 JDK Proxy
        JDKProxy jdkProxy = new JDKProxy();
        Car carInstance = (Car) jdkProxy.getInstance(new Taxi());
        carInstance.running();
    }
}

• CGLib 的实现

在使用 CGLib 之前，我们要先在项目中引入 CGLib 框架

public class test {

    static class Car {
        public void running() {
            System.out.println("The car is running.");
        }
    }

    /**
     * CGLib 代理类
     */
    static class CGLibProxy implements MethodInterceptor {
    
        private Object target; // 代理对象

        public Object getInstance(Object target) {
            this.target = target;
            Enhancer enhancer = new Enhancer();
            // 设置父类为实例类
            enhancer.setSuperclass(this.target.getClass());
            // 回调方法
            enhancer.setCallback(this);
            // 创建代理对象
            return enhancer.create();
        }

        @Override
        public Object intercept(Object o, Method method,
                                Object[] objects, MethodProxy methodProxy) throws Throwable {
            System.out.println("before.");
            Object result = methodProxy.invokeSuper(o, objects); // 执行方法调用
            System.out.println("after.");
            return result;
        }
    }

    // 执行 CGLib 的方法调用
    public static void main(String[] args) {
        // 创建 CGLib 代理类
        CGLibProxy proxy = new CGLibProxy();
        // 初始化代理对象
        Car car = (Car) proxy.getInstance(new Car());
        // 执行方法
        car.running();
    }
}

对比

JDK Proxy 是 Java 语言内置的动态代理，必须要通过实现接口的方式来代理相关的类，而 CGLib 是第三方提供的基于 ASM 的高效动态代理类，它通过实现被代理类的子类来实现动态代理的功能，因此被代理的类不能使用 final 修饰。

CGLib 和 JDK Proxy 的实现代码比较类似，都是通过实现代理器的接口，再调用某一个方法完成动态代理的，唯一不同的是，CGLib 在初始化被代理类时，是通过 Enhancer 对象把代理对象设置为被代理类的子类来实现动态代理的。因此被代理类不能被关键字 final 修饰，如果被 final 修饰，再使用 Enhancer 设置父类时会报错，动态代理的构建会失败。

动态代理知识点扩充

当面试官问动态代理的时候，经常会问到它和静态代理的区别？静态代理其实就是事先写好代理类，可以手工编写也可以使用工具生成，但它的缺点是每个业务类都要对应一个代理类，特别不灵活也不方便，于是就有了动态代理。

动态代理的常见使用场景有 RPC 框架的封装、AOP（面向切面编程）的实现、JDBC 的连接等。

Spring 框架中同时使用了两种动态代理 JDK Proxy 和 CGLib，当 Bean 实现了接口时，Spring 就会使用 JDK Proxy，在没有实现接口时就会使用 CGLib，我们也可以在配置中指定强制使用 CGLib，只需要在 Spring 配置中添加 <aop:aspectj-autoproxy proxy-target-class="true"/> 即可。

9. 如何实现本地缓存和分布式缓存？

典型回答

本地缓存是指程序级别的缓存组件，它的特点是本地缓存和应用程序会运行在同一个进程中，所以本地缓存的操作会非常快，因为在同一个进程内也意味着不会有网络上的延迟和开销。

本地缓存适用于单节点非集群的应用场景，它的优点是快，缺点是多程序无法共享缓存，比如分布式用户 Session 会话信息保存，由于每次用户访问的服务器可能是不同的，如果不能共享缓存，那么就意味着每次的请求操作都有可能被系统阻止，因为会话信息只保存在某一个服务器上，当请求没有被转发到这台存储了用户信息的服务器时，就会被认为是非登录的违规操作。

除此之外，无法共享缓存可能会造成系统资源的浪费，这是因为每个系统都单独维护了一份属于自己的缓存，而同一份缓存有可能被多个系统单独进行存储，从而浪费了系统资源。

分布式缓存是指将应用系统和缓存组件进行分离的缓存机制，这样多个应用系统就可以共享一套缓存数据了，它的特点是共享缓存服务和可集群部署，为缓存系统提供了高可用的运行环境，以及缓存共享的程序运行机制。

本地缓存可以使用 EhCache 和 Google 的 Guava 来实现，而分布式缓存可以使用 Redis 或 Memcached 来实现。

由于 Redis 本身就是独立的缓存系统，因此可以作为第三方来提供共享的数据缓存，而 Redis 的分布式支持主从、哨兵和集群的模式，所以它就可以支持分布式的缓存，而 Memcached 的情况也是类似的。

• LRU 和 LFU 的区别

LRU 算法有一个缺点，比如说很久没有使用的一个键值，如果最近被访问了一次，那么即使它是使用次数最少的缓存，它也不会被淘汰；而 LFU 算法解决了偶尔被访问一次之后，数据就不会被淘汰的问题，它是根据总访问次数来淘汰数据的，其核心思想是“如果数据过去被访问多次，那么将来它被访问次数也会比较多”。因此 LFU 可以理解为比 LRU 更加合理的淘汰算法。

手动实现一个缓存系统

要自定义一个缓存，首先要考虑的是数据类型，我们可以使用 Map 集合中的 HashMap、Hashtable 或 ConcurrentHashMap 来实现，非并发情况下我们可以使用 HashMap，并发情况下可以使用 Hashtable 或 ConcurrentHashMap，由于 ConcurrentHashMap 的性能比 Hashtable 的高，因此在高并发环境下我们可以倾向于选择 ConcurrentHashMap，不过它们对元素的操作都是类似的。

选定了数据类型之后，我们还需要考虑缓存过期和缓存淘汰等问题，在这里我们可以借鉴 Redis 对待过期键的处理策略。

目前比较常见的过期策略有以下三种：

• 定时删除
• 惰性删除
• 定期删除

定时删除是指在设置键值的过期时间时，创建一个定时事件，当到达过期时间后，事件处理器会执行删除过期键的操作。它的优点是可以及时的释放内存空间，缺点是需要开启多个延迟执行事件来处理清除任务，这样就会造成大量任务事件堆积，占用了很多系统资源。 惰性删除不会主动删除过期键，而是在每次请求时才会判断此值是否过期，如果过期则删除键值，否则就返回 null。它的优点是只会占用少量的系统资源，缺点是清除不够及时，会造成一定的空间浪费。

定期删除是指每隔一段时间检查一次数据库，随机删除一些过期键值。

Redis 使用的是定期删除和惰性删除这两种策略，我们本课时也会参照这两种策略。

先来说一下自定义缓存的实现思路，首先需要定义一个存放缓存值的实体类，这个类里包含了缓存的相关信息，比如缓存的 key 和 value，缓存的存入时间、最后使用时间和命中次数（预留字段，用于支持 LFU 缓存淘汰），再使用 ConcurrentHashMap 保存缓存的 key 和 value 对象（缓存值的实体类），然后再新增一个缓存操作的工具类，用于添加和删除缓存，最后再缓存启动时，开启一个无限循环的线程用于检测并删除过期的缓存，实现代码如下。

• 首先，定义一个缓存值实体类，代码如下：

public class MyCache implements Comparable<MyCache> {
    // 缓存键
    private Object key;
    // 缓存值
    private Object value;
    // 最后访问时间
    private long lastTime;
    // 创建时间
    private long createTime;
    // 存活时间
    private long expireTime;
    // 命中次数
    private Integer hitCount;

    @Override
    public int compareTo(MyCache o) {
        return hitCount.compareTo(o.hitCount);
    }
}

• 然后定义一个全局缓存对象，代码如下：

public class CacheGlobal {
    // 全局缓存对象
    public static ConcurrentMap<String, MyCache> concurrentMap = new ConcurrentHashMap();
}

• 定义过期缓存检测类的代码如下：

/**
 * 过期缓存检测线程
 */
public class ExpireThread implements Runnable {
    @Override
    public void run() {
        while (true) {
            // 每十秒检测一次
            TimeUnit.SECONDS.sleep(10);
            expireCache();
        }
    }

    /**
     * 缓存检测和清除的方法
     */
    private void expireCache() {
        sout("检测缓存是否过期缓存");
        for (String key : CacheGlobal.concurrentMap.keySet()) {
            MyCache cache = CacheGlobal.concurrentMap.get(key);
            // 当前时间 - 创建时间
            long timoutTime = System.currentTimeMillis() - cache.getCreateTime();
            if (cache.getExpireTime() > timoutTime) {  // 没过期
                continue;
            }
            // 清除过期缓存
            CacheGlobal.concurrentMap.remove(key);
        }
    }
}

• 接着，我们要新增一个缓存操作的工具类，用于查询和存入缓存，实现代码如下：

/**
 * 缓存操作工具类
 */
public class CacheUtils {

    /**
     * 添加缓存
     * @param key
     * @param value
     * @param expire
     */
    public void put(String key, Object value, long expire) {
        // 非空判断
        if (StringUtils.isBlank(key)) return;

        // 当缓存存在时，更新缓存
        if (CacheGlobal.concurrentMap.containsKey(key)) {
            MyCache cache = CacheGlobal.concurrentMap.get(key);
            cache.setHitCount(cache.getHitCount() + 1);
            cache.setLastTime(System.currentTimeMillis());
            cache.setExpireTime(expire);
            cache.setValue(value);
            return;
        }
        // 创建缓存
        MyCache cache = new MyCache();
        cache.setKey(key);
        cache.setValue(value);
        cache.setCreateTime(System.currentTimeMillis());
        cache.setLastTime(System.currentTimeMillis());
        cache.setHitCount(1);
        cache.setExpireTime(expire);
        CacheGlobal.concurrentMap.put(key, cache);
    }

    /**
     * 获取缓存
     * @param key
     * @return
     */
    public Object get(String key) {
        // 非空判断
        if (StringUtils.isBlank(key)) return null;
        // 字典中不存在
        if (CacheGlobal.concurrentMap.isEmpty()) return null;
        if (!CacheGlobal.concurrentMap.containsKey(key)) return null;

        MyCache cache = CacheGlobal.concurrentMap.get(key);
        if (cache == null) return null;
        // 惰性删除，判断缓存是否过期
        long timoutTime = System.currentTimeMillis() - cache.getCreateTime();
        // 缓存过期
        if (cache.getExpireTime() <= timoutTime) {
            // 清除过期缓存
            CacheGlobal.concurrentMap.remove(key);
            return null;
        }
        cache.setHitCount(cache.getHitCount() + 1);
        cache.setLastTime(System.currentTimeMillis());
        return cache.getValue();
    }
}

• 最后是调用缓存的测试代码：

public class MyCacheTest {
    public static void main(String[] args) throws InterruptedException {
        CacheUtils cache = new CacheUtils();
        // 存入缓存
        cache.put("key", "老王", 1);
        // 查询缓存
        String val = (String) cache.get("key");
        // 查询不存在的缓存
        String noval = (String) cache.get("noval");
    }
}

10. 如何手写一个消息队列和延迟消息队列？

1. 常用消息中间件 RabbitMQ

RabbitMQ 中有 3 个重要的概念：生产者、消费者和代理。

• 生产者：消息的创建者，负责创建和推送数据到消息服务器。
• 消费者：消息的接收方，用于处理数据和确认消息。
• 代理：也就是 RabbitMQ 服务本身，它用于扮演“快递”的角色，因为它本身并不生产消息，只是扮演了“快递”的角色，把消息进行暂存和传递。

RabbitMQ 具备以下几个优点：

• 支持持久化，RabbitMQ 支持磁盘持久化功能，保证了消息不会丢失；
• 高并发，RabbitMQ 使用了 Erlang 开发语言，Erlang 是为电话交换机开发的语言，天生自带高并发光环和高可用特性；
• 支持分布式集群，正是因为 Erlang 语言实现的，因此 RabbitMQ 集群部署也非常简单，只需要启动每个节点并使用 --link 把节点加入到集群中即可，并且 RabbitMQ 支持自动选主和自动容灾；
• 支持多种语言，比如 Java、.NET、PHP、Python、JavaScript、Ruby、Go 等；
• 支持消息确认，支持消息消费确认（ack）保证了每条消息可以被正常消费；
• 它支持很多插件，比如网页控制台消息管理插件、消息延迟插件等，RabbitMQ 的插件很多并且使用都很方便。

RabbitMQ 的消息类型，分为以下四种：

• direct（默认类型）模式，此模式为一对一的发送方式，也就是一条消息只会发送给一个消费者；
• headers 模式，允许你匹配消息的 header 而非路由键（RoutingKey），除此之外 headers 和 direct 的使用完全一致，但因为 headers 匹配的性能很差，几乎不会被用到；
• fanout 模式，为多播的方式，会把一个消息分发给所有的订阅者；
• topic 模式，为主题订阅模式，允许使用通配符（#、*）匹配一个或者多个消息，我可以使用"cn.mq.#"匹配到多个前缀是"cn.mq.xxx"”的消息，比如可以匹配到“cn.mq.rabbit”、“cn.mq.kafka”等消息。

2. 自定义消息队列

• 双端队列（Deque） 是 Queue 的子类也是 Queue 的补充类，头部和尾部都支持元素插入和获取；
• 阻塞队列指的是在元素操作时（添加或删除），如果没有成功，会阻塞等待执行，比如当添加元素时，如果队列元素已满，队列则会阻塞等待直到有空位时再插入；
• 非阻塞队列，和阻塞队列相反，它会直接返回操作的结果，而非阻塞等待操作，双端队列也属于非阻塞队列。

2_热门框架

底层源码分析 Spring 的核心功能和执行流程？（上）

典型回答

在 Spring 容器中管理一个或多个 Bean，这些 Bean 的定义表示为 BeanDefinition 对象，这些对象包含以下重要信息：

• Bean 的实际实现类
• Bean 的作用范围
• Bean 的引用或者依赖项

Bean 的注册方式有三种：

• XML 配置文件的注册方式
• Java 注解的注册方式
  • 可以使用 @Component 注解方式来注册 Bean
  • 可以使用 @Bean 注解方式来注册 Bean
• Java API 的注册方式
  • 使用 BeanDefinitionRegistry.registerBeanDefinition() 方法的方式注册 Bean

Bean 的作用域一共有 5 个

• singleton
• prototype
• request
• session
• application

知识扩展

在 Spring 中最核心的概念是 AOP（面向切面编程）、IoC（控制反转）、DI（依赖注入）等（此内容将会在下一课时中讲到），而最实用的功能则是 Bean，他们是概念和具体实现的关系。和 Bean 相关的面试题，还有以下几个：

• 什么是同名 Bean？它是如何产生的？应该如何避免？
• 聊一聊 Bean 的生命周期。

1.同名 Bean 问题

每个 Bean 拥有一个或多个标识符，在基于 XML 的配置中，我们可以使用 id 或者 name 来作为 Bean 的标识符。通常 Bean 的标识符由字母组成，允许使用特殊字符。

同一个 Spring 配置文件中 Bean 的 id 和 name 是不能够重复的，否则 Spring 容器启动时会报错。但如果 Spring 加载了多个配置文件的话，可能会出现同名 Bean 的问题。同名 Bean 指的是多个 Bean 有相同的 name 或者 id。

Spring 对待同名 Bean 的处理规则是使用最后面的 Bean 覆盖前面的 Bean，所以我们在定义 Bean 时，尽量使用长命名非重复的方式来定义，避免产生同名 Bean 的问题。

Bean 的 id 或 name 属性并非必须指定，如果留空的话，容器会为 Bean 自动生成一个唯一的名称，这样也不会出现同名 Bean 的问题。

2.Bean 生命周期

对于 Spring Bean 来说，并不是启动阶段就会触发 Bean 的实例化，只有当客户端通过显式或者隐式的方式调用 BeanFactory 的 getBean() 方法时，它才会触发该类的实例化方法。当然对于 BeanFactory 来说，也不是所有的 getBean() 方法都会实例化 Bean 对象，例如作用域为 singleton 时，只会在第一次，实例化该 Bean 对象，之后会直接返回该对象。但如果使用的是 ApplicationContext 容器，则会在该容器启动的时候，立即调用注册到该容器所有 Bean 的实例化方法。

getBean() 既然是 Bean 对象的入口，我们就先从这个方法说起，getBean() 方法是属于 BeanFactory 接口的，它的真正实现是 AbstractAutowireCapableBeanFactory 的 createBean() 方法，而 createBean() 是通过 doCreateBean() 来实现的

在 doCreateBean() 方法中，首先对 Bean 进行了实例化工作，它是通过调用 createBeanInstance() 方法来实现的，该方法返回一个 BeanWrapper 对象。BeanWrapper 对象是 Spring 中一个基础的 Bean 结构接口，说它是基础接口是因为它连基本的属性都没有。

BeanWrapper 接口有一个默认实现类 BeanWrapperImpl，其主要作用是对 Bean 进行填充，比如填充和注入 Bean 的属性等。

当 Spring 完成 Bean 对象实例化并且设置完相关属性和依赖后，则会调用 Bean 的初始化方法 initializeBean()，初始化第一个阶段是检查当前 Bean 对象是否实现了 BeanNameAware、BeanClassLoaderAware、BeanFactoryAware 等接口

其中，BeanNameAware 是把 Bean 对象定义的 beanName 设置到当前对象实例中；BeanClassLoaderAware 是将当前 Bean 对象相应的 ClassLoader 注入到当前对象实例中；BeanFactoryAware 是 BeanFactory 容器会将自身注入到当前对象实例中，这样当前对象就会拥有一个 BeanFactory 容器的引用。

初始化第二个阶段则是 BeanPostProcessor 增强处理，它主要是对 Spring 容器提供的 Bean 实例对象进行有效的扩展，允许 Spring 在初始化 Bean 阶段对其进行定制化修改，比如处理标记接口或者为其提供代理实现。

在初始化的前置处理完成之后就会检查和执行 InitializingBean 和 init-method 方法。

InitializingBean 是一个接口，它有一个 afterPropertiesSet() 方法，在 Bean 初始化时会判断当前 Bean 是否实现了 InitializingBean，如果实现了则调用 afterPropertiesSet() 方法，进行初始化工作；然后再检查是否也指定了 init-method，如果指定了则通过反射机制调用指定的 init-method 方法

初始化完成之后就可以正常的使用 Bean 对象了，在 Spring 容器关闭时会执行销毁方法，但是 Spring 容器不会自动去调用销毁方法，而是需要我们主动的调用。

如果是 BeanFactory 容器，那么我们需要主动调用 destroySingletons() 方法，通知 BeanFactory 容器去执行相应的销毁方法；如果是 ApplicationContext 容器，那么我们需要主动调用 registerShutdownHook() 方法，告知 ApplicationContext 容器执行相应的销毁方法。

底层源码分析 Spring 的核心功能和执行流程？（下）

我们本课时的面试题是，谈一谈你对 IoC 和 DI 的理解。

典型回答

IoC（Inversion of Control，翻译为“控制反转”）不是一个具体的技术，而是一种设计思想。与传统控制流相比，IoC 会颠倒控制流，在传统的编程中需要开发者自行创建并销毁对象，而在 IoC 中会把这些操作交给框架来处理，这样开发者就不用关注具体的实现细节了，拿来直接用就可以了，这就是控制反转。

IoC 很好的体现出了面向对象的设计法则之一——好莱坞法则：“别找我们，我们找你”。即由 IoC 容器帮对象找到相应的依赖对象并注入，而不是由对象主动去找。

举个例子，比如说传统找对象，先要设定好你的要求，如身高、体重、长相等，然后再一个一个的主动去找符合要求的对象，而 IoC 相当于，你把这些要求直接告诉婚介中心，由他们直接给你匹配到符合要求的对象，理想情况下是直接会帮你找到合适的对象，这就是传统编程模式和 IoC 的区别。

DI（Dependency Injection，翻译为“依赖注入”）表示组件间的依赖关系交由容器在运行期自动生成，也就是说，由容器动态的将某个依赖关系注入到组件之中，这样就能提升组件的重用频率。通过依赖注入机制，我们只需要通过简单的配置，就可指定目标需要的资源，完成自身的业务逻辑，而不需要关心资源来自哪里、由谁实现等问题。

IoC 和 DI 其实是同一个概念从不同角度的描述的，由于控制反转这个概念比较含糊（可能只理解成了容器控制对象这一个层面，很难让人想到谁来维护对象关系），所以 2004 年被开发者尊称为“教父”的 Martin Fowler（世界顶级专家，敏捷开发方法的创始人之一）又给出了一个新的名字“依赖注入”，相对 IoC 而言，“依赖注入”明确描述了“被注入对象依赖 IoC 容器配置依赖对象”。

知识扩展

IoC 和 DI 为 Spring 框架设计的精髓所在，也是面试中必问的考点之一，这个优秀的设计思想对于初学者来说可能理解起来比较困难，但对于 Spring 的使用者来说可以很快的看懂。因此如果对于此概念还有疑问的话，建议先上手使用 Spring 实现几个小功能再回头来看这些概念，相信你会豁然开朗。

Spring 相关的高频面试题，还有以下这些：

• Spring IoC 有哪些优势？

• IoC 的注入方式有哪些？

• 谈一谈你对 AOP 的理解。

• 1.Spring IoC 的优点

IoC 的优点有以下几个：

• 使用更方便，拿来即用，无需显式的创建和销毁的过程；
• 可以很容易提供众多服务，比如事务管理、消息服务等；
• 提供了单例模式的支持；
• 提供了 AOP 抽象，利用它很容易实现权限拦截、运行期监控等功能；
• 更符合面向对象的设计法则；
• 低侵入式设计，代码的污染极低，降低了业务对象替换的复杂性。

Spring IoC 注入方式汇总

IoC 的注入方式有三种：构造方法注入、Setter 注入和接口注入。

public class Person {
    private int id;
    private String name;
    public Person() {}
    public Person(int id, String name) {
	this.id = id;
	this.name = name;
    }
}

① 构造方法注入

<bean id="person" class="org.springframework.beans.Person">
    <constructor-arg value="1" type="int"></constructor-arg>
    <constructor-arg value="Java" type="java.lang.String"></constructor-arg>
</bean>

② Setter 注入

<bean id="person" class="org.springframework.beans.Person">
    <property name="id" value="1"/>
    <property name="name" value="Java"/>
</bean>

③ 接口注入

接口注入方式是比较古老的注入方式，因为它需要被依赖的对象实现不必要的接口，带有侵入性，因此现在已经被完全舍弃了，所以本文也不打算做过多的描述，大家只要知道有这回事就行了

Spring AOP

AOP（Aspect-OrientedProgramming，面向切面编程）可以说是 OOP（Object-Oriented Programing，面向对象编程）的补充和完善，OOP 引入封装、继承和多态性等概念来建立一种公共对象处理的能力，当我们需要处理公共行为的时候，OOP 就会显得无能为力，而 AOP 的出现正好解决了这个问题。比如统一的日志处理模块、授权验证模块等都可以使用 AOP 很轻松的处理。

Spring AOP 目前提供了三种配置方式：

• 基于 Java API 的方式；
• 基于 @AspectJ（Java）注解的方式；
• 基于 XML <aop /> 标签的方式。

Spring AOP 的原理其实很简单，它其实就是一个动态代理，我们在调用 getBean() 方法的时候返回的其实是代理类的实例，而这个代理类在 Spring 中使用的是 JDK Proxy 或 CgLib 实现的，它的核心代码在 DefaultAopProxyFactory#createAopProxy(...) 中

public class DefaultAopProxyFactory implements AopProxyFactory, Serializable {

	@Override
	public AopProxy createAopProxy(AdvisedSupport config) throws AopConfigException {
		if (config.isOptimize() || config.isProxyTargetClass() || hasNoUserSuppliedProxyInterfaces(config)) {
			Class<?> targetClass = config.getTargetClass();
			if (targetClass == null) {
				throw new AopConfigException("TargetSource cannot determine target class: " +
						"Either an interface or a target is required for proxy creation.");
			}
                        // 判断目标类是否为接口
			if (targetClass.isInterface() || Proxy.isProxyClass(targetClass)) {
                                // 是接口使用 jdk 的代理
				return new JdkDynamicAopProxy(config);
			}
                        // 其他情况使用 CgLib 代理
			return new ObjenesisCglibAopProxy(config);
		}
		else {
			return new JdkDynamicAopProxy(config);
		}
	}
    // 忽略其他代码
}

Spring 事务失效

要求

• 掌握事务失效的八种场景

1. 抛出检查异常导致事务不能正确回滚
2. 业务方法内自己 try-catch 异常导致事务不能正确回滚
3. aop 切面顺序导致导致事务不能正确回滚
4. 非 public 方法导致的事务失效
5. 父子容器导致的事务失效
6. 调用本类方法导致传播行为失效
7. @Transactional 没有保证原子行为
8. @Transactional 方法导致的 synchronized 失效

1. 抛出 [检查异常] 导致事务不能正确回滚

 @Service
 public class Service1 {
     @Autowired
     private AccountMapper accountMapper;
     
     @Transactional
     public void transfer(int from, int to, int amount) throws FileNotFoundException {
         int fromBalance = accountMapper.findBalanceBy(from);
         if (fromBalance - amount >= 0) {
             accountMapper.update(from, -1 * amount);
             new FileInputStream("aaa");
             accountMapper.update(to, amount);
         }
     }
 }

• 原因：Spring 默认只会回滚非检查异常

• 解法：配置 rollbackFor 属性

  • @Transactional(rollbackFor = Exception.class)

2. 业务方法内自己 try-catch 异常导致事务不能正确回滚

 @Service
 public class Service2 {

     @Autowired
     private AccountMapper accountMapper;

     @Transactional(rollbackFor = Exception.class)
     public void transfer(int from, int to, int amount)  {
         try {
             int fromBalance = accountMapper.findBalanceBy(from);
             if (fromBalance - amount >= 0) {
                 accountMapper.update(from, -1 * amount);
                 new FileInputStream("aaa");
                 accountMapper.update(to, amount);
             }
         } catch (FileNotFoundException e) {
             e.printStackTrace();
         }
     }
 }

• 原因：事务通知只有捉到了目标抛出的异常，才能进行后续的回滚处理，如果目标自己处理掉异常，事务通知无法知悉

• 解法1：异常原样抛出

  • 在 catch 块添加 throw new RuntimeException(e);

• 解法2：手动设置 TransactionStatus.setRollbackOnly()

  • 在 catch 块添加 TransactionInterceptor.currentTransactionStatus().setRollbackOnly();

3. aop 切面顺序导致导致事务不能正确回滚

 @Service
 public class Service3 {
 ​
     @Autowired
     private AccountMapper accountMapper;
 ​
     @Transactional(rollbackFor = Exception.class)
     public void transfer(int from, int to, int amount) throws FileNotFoundException {
         int fromBalance = accountMapper.findBalanceBy(from);
         if (fromBalance - amount >= 0) {
             accountMapper.update(from, -1 * amount);
             new FileInputStream("aaa");
             accountMapper.update(to, amount);
         }
     }
 }

 @Aspect
 public class MyAspect {
     @Around("execution(* transfer(..))")
     public Object around(ProceedingJoinPoint pjp) throws Throwable {
         LoggerUtils.get().debug("log:{}", pjp.getTarget());
         try {
             return pjp.proceed();
         } catch (Throwable e) {
             e.printStackTrace();
             return null;
         }
     }
 }

• 原因：事务切面优先级最低，但如果自定义的切面优先级和他一样，则还是自定义切面在内层，这时若自定义切面没有正确抛出异常…
• 解法1、2：同情况2 中的解法:1、2
• 解法3：调整切面顺序，在 MyAspect 上添加 @Order(Ordered.LOWEST_PRECEDENCE - 1) （不推荐）

4. 非 public 方法导致的事务失效

 @Service
 public class Service4 {
 ​
     @Autowired
     private AccountMapper accountMapper;
 ​
     @Transactional
     void transfer(int from, int to, int amount) throws FileNotFoundException {
         int fromBalance = accountMapper.findBalanceBy(from);
         if (fromBalance - amount >= 0) {
             accountMapper.update(from, -1 * amount);
             accountMapper.update(to, amount);
         }
     }
 }

• 原因：Spring 为方法创建代理、添加事务通知、前提条件都是该方法是 public 的
• 解法1：改为 public 方法
• 解法2：添加 bean 配置如下（不推荐）

 @Bean
 public TransactionAttributeSource transactionAttributeSource() {
     return new AnnotationTransactionAttributeSource(false);
 }

5. 父子容器导致的事务失效

 package day04.tx.app.service;
 ​
 // ...
 ​
 @Service
 public class Service5 {
 ​
     @Autowired
     private AccountMapper accountMapper;
 ​
     @Transactional(rollbackFor = Exception.class)
     public void transfer(int from, int to, int amount) throws FileNotFoundException {
         int fromBalance = accountMapper.findBalanceBy(from);
         if (fromBalance - amount >= 0) {
             accountMapper.update(from, -1 * amount);
             accountMapper.update(to, amount);
         }
     }
 }

控制器类

 package day04.tx.app.controller;
 ​
 // ...
 ​
 @Controller
 public class AccountController {
 ​
     @Autowired
     public Service5 service;
 ​
     public void transfer(int from, int to, int amount) throws FileNotFoundException {
         service.transfer(from, to, amount);
     }
 }

App 配置类

 @Configuration
 @ComponentScan("day04.tx.app.service")
 @EnableTransactionManagement
 // ...
 public class AppConfig {
     // ... 有事务相关配置
 }

Web 配置类

 @Configuration
 @ComponentScan("day04.tx.app")
 // ...
 public class WebConfig {
     // ... 无事务配置
 }

现在配置了父子容器，WebConfig 对应子容器，AppConfig 对应父容器，发现事务依然失效

• 原因：子容器扫描范围过大，把未加事务配置的 service 扫描进来
• 解法1：各扫描各的，不要图简便
• 解法2：不要用父子容器，所有 bean 放在同一容器

6. 调用本类方法导致传播行为失效

 @Service
 public class Service6 {
 ​
     @Transactional(propagation = Propagation.REQUIRED, rollbackFor = Exception.class)
     public void foo() throws FileNotFoundException {
         LoggerUtils.get().debug("foo");
         bar();
     }
 ​
     @Transactional(propagation = Propagation.REQUIRES_NEW, rollbackFor = Exception.class)
     public void bar() throws FileNotFoundException {
         LoggerUtils.get().debug("bar");
     }
 }

• 原因：本类方法调用不经过代理，因此无法增强
• 解法1：依赖注入自己（代理）来调用
• 解法2：通过 AopContext 拿到代理对象，来调用
• 解法3：通过 CTW，LTW 实现功能增强

解法1

 @Service
 public class Service6 {
 ​
     @Autowired
     private Service6 proxy; // 本质上是一种循环依赖
 ​
     @Transactional(propagation = Propagation.REQUIRED, rollbackFor = Exception.class)
     public void foo() throws FileNotFoundException {
         LoggerUtils.get().debug("foo");
         System.out.println(proxy.getClass());
         proxy.bar();
     }
 ​
     @Transactional(propagation = Propagation.REQUIRES_NEW, rollbackFor = Exception.class)
     public void bar() throws FileNotFoundException {
         LoggerUtils.get().debug("bar");
     }
 }

解法2，还需要在 AppConfig 上添加 @EnableAspectJAutoProxy(exposeProxy = true)

 @Service
 public class Service6 {
     
     @Transactional(propagation = Propagation.REQUIRED, rollbackFor = Exception.class)
     public void foo() throws FileNotFoundException {
         LoggerUtils.get().debug("foo");
         ((Service6) AopContext.currentProxy()).bar();
     }
 ​
     @Transactional(propagation = Propagation.REQUIRES_NEW, rollbackFor = Exception.class)
     public void bar() throws FileNotFoundException {
         LoggerUtils.get().debug("bar");
     }
 }

7. @Transactional 没有保证原子行为

 @Service
 public class Service7 {
 ​
     private static final Logger logger = LoggerFactory.getLogger(Service7.class);
 ​
     @Autowired
     private AccountMapper accountMapper;
 ​
     @Transactional(rollbackFor = Exception.class)
     public void transfer(int from, int to, int amount) {
         int fromBalance = accountMapper.findBalanceBy(from);
         logger.debug("更新前查询余额为: {}", fromBalance);
         if (fromBalance - amount >= 0) {
             accountMapper.update(from, -1 * amount);
             accountMapper.update(to, amount);
         }
     }
 ​
     public int findBalance(int accountNo) {
         return accountMapper.findBalanceBy(accountNo);
     }
 }

上面的代码实际上是有 bug 的，假设 from 余额为 1000，两个线程都来转账 1000，可能会出现扣减为负数的情况

• 原因：事务的原子性仅涵盖 insert、update、delete、select … for update 语句，select 方法并不阻塞

• 如上图所示，红色线程和蓝色线程的查询都发生在扣减之前，都以为自己有足够的余额做扣减

8. @Transactional 方法导致的 synchronized 失效

针对上面的问题，能否在方法上加 synchronized 锁来解决呢？

 @Service
 public class Service7 {
 ​
     private static final Logger logger = LoggerFactory.getLogger(Service7.class);
 ​
     @Autowired
     private AccountMapper accountMapper;
 ​
     @Transactional(rollbackFor = Exception.class)
     public synchronized void transfer(int from, int to, int amount) {
         int fromBalance = accountMapper.findBalanceBy(from);
         logger.debug("更新前查询余额为: {}", fromBalance);
         if (fromBalance - amount >= 0) {
             accountMapper.update(from, -1 * amount);
             accountMapper.update(to, amount);
         }
     }
 ​
     public int findBalance(int accountNo) {
         return accountMapper.findBalanceBy(accountNo);
     }
 }

答案是不行，原因如下：

• synchronized 保证的仅是目标方法的原子性，环绕目标方法的还有 commit 等操作，它们并未处于 sync 块内
• 可以参考下图发现，蓝色线程的查询只要在红色线程提交之前执行，那么依然会查询到有 1000 足够余额来转账

• 解法1：synchronized 范围应扩大至代理方法调用
• 解法2：使用 select … for update 替换 select

Spring MVC 执行流程

要求

• 掌握 Spring MVC 的执行流程
• 了解 Spring MVC 的重要组件的作用

概要

我把整个流程分成三个阶段

• 准备阶段
• 匹配阶段
• 执行阶段

准备阶段

0. 在 Web 容器第一次用到 DispatcherServlet 的时候，会创建其对象并执行 init 方法
1. init 方法内会创建 Spring Web 容器，并调用容器 refresh 方法
2. refresh 过程中会创建并初始化 SpringMVC 中的重要组件， 例如 MultipartResolver，HandlerMapping，HandlerAdapter，HandlerExceptionResolver、ViewResolver 等
3. 容器初始化后，会将上一步初始化好的重要组件，赋值给 DispatcherServlet 的成员变量，留待后用

匹配阶段

0. 用户发送的请求统一到达前端控制器 DispatcherServlet

1. DispatcherServlet 遍历所有 HandlerMapping ，找到与路径匹配的处理器

   ① HandlerMapping 有多个，每个 HandlerMapping 会返回不同的处理器对象，谁先匹配，返回谁的处理器。其中能识别 @RequestMapping 的优先级最高

   ② 对应 @RequestMapping 的处理器是 HandlerMethod，它包含了控制器对象和控制器方法信息

   ③ 其中路径与处理器的映射关系在 HandlerMapping 初始化时就会建立好

3. 将 HandlerMethod 连同匹配到的拦截器，生成调用链对象 HandlerExecutionChain 返回

4. 遍历 HandlerAdapter 处理器适配器，找到能处理 HandlerMethod 的适配器对象，开始调用

调用阶段

1. 执行拦截器 preHandle

2. 由 HandlerAdapter 调用 HandlerMethod

   ① 调用前处理不同类型的参数

   ② 调用后处理不同类型的返回值

3. 第 2 步没有异常

   ① 返回 ModelAndView

   ② 执行拦截器 postHandle 方法

   ③ 解析视图，得到 View 对象，进行视图渲染

4. 第 2 步有异常，进入 HandlerExceptionResolver 异常处理流程

5. 最后都会执行拦截器的 afterCompletion 方法
6. 如果控制器方法标注了 @ResponseBody 注解，则在第 2 步，就会生成 json 结果，并标记 ModelAndView 已处理，这样就不会执行第 3 步的视图渲染

SpringBoot 自动配置原理

要求

• 掌握 SpringBoot 自动配置原理

自动配置原理

@SpringBootApplication 是一个组合注解，由 @ComponentScan、@EnableAutoConfiguration 和 @SpringBootConfiguration 组成

0. @SpringBootConfiguration 与普通 @Configuration 相比，唯一区别是前者要求整个 app 中只出现一次

1. @ComponentScan

   • excludeFilters - 用来在组件扫描时进行排除，也会排除自动配置类

2. @EnableAutoConfiguration 也是一个组合注解，由下面注解组成

   • @AutoConfigurationPackage – 用来记住扫描的起始包
   • @Import(AutoConfigurationImportSelector.class) 用来加载 META-INF/spring.factories 中的自动配置类

为什么不使用 @Import 直接引入自动配置类

有两个原因：

0. 让主配置类和自动配置类变成了强耦合，主配置类不应该知道有哪些从属配置
1. 直接用 @Import(自动配置类.class)，引入的配置解析优先级较高，自动配置类的解析应该在主配置没提供时作为默认配置

因此，采用了 @Import(AutoConfigurationImportSelector.class)

• 由 AutoConfigurationImportSelector.class 去读取 META-INF/spring.factories 中的自动配置类，实现了弱耦合。
• 另外 AutoConfigurationImportSelector.class 实现了 DeferredImportSelector 接口，让自动配置的解析晚于主配置的解析

Spring 中的设计模式

要求

• 掌握 Spring 中常见的设计模式

1. 单例模式
2. 工厂方法
3. 适配器
4. 代理模式
5. 责任链
6. 模板方法

1. Spring 中的 Singleton

请大家区分 singleton pattern 与 Spring 中的 singleton bean

• 根据单例模式的目的 Ensure a class only has one instance, and provide a global point of access to it

• 显然 Spring 中的 singleton bean 并非实现了单例模式，singleton bean 只能保证每个容器内，相同 id 的 bean 单实例

• 当然 Spring 中也用到了单例模式，例如

  • org.springframework.transaction.TransactionDefinition#withDefaults
  • org.springframework.aop.TruePointcut#INSTANCE
  • org.springframework.aop.interceptor.ExposeInvocationInterceptor#ADVISOR
  • org.springframework.core.annotation.AnnotationAwareOrderComparator#INSTANCE
  • org.springframework.core.OrderComparator#INSTANCE

2. Spring 中的 Builder

定义 Separate the construction of a complex object from its representation so that the same construction process can create different representations

它的主要亮点有三处：

0. 较为灵活的构建产品对象
1. 在不执行最后 build 方法前，产品对象都不可用
2. 构建过程采用链式调用，看起来比较爽

Spring 中体现 Builder 模式的地方：

• org.springframework.beans.factory.support.BeanDefinitionBuilder
• org.springframework.web.util.UriComponentsBuilder
• org.springframework.http.ResponseEntity.HeadersBuilder
• org.springframework.http.ResponseEntity.BodyBuilder

3. Spring 中的 Factory Method

定义 Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses

根据上面的定义，Spring 中的 ApplicationContext 与 BeanFactory 中的 getBean 都可以视为工厂方法，它隐藏了 bean （产品）的创建过程和具体实现

Spring 中其它工厂：

• org.springframework.beans.factory.FactoryBean
• @Bean 标注的静态方法及实例方法
• ObjectFactory 及 ObjectProvider

前两种工厂主要封装第三方的 bean 的创建过程，后两种工厂可以推迟 bean 创建，解决循环依赖及单例注入多例等问题

4. Spring 中的 Adapter

定义 Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces

典型的实现有两处：

• org.springframework.web.servlet.HandlerAdapter – 因为控制器实现有各种各样，比如有

  • 大家熟悉的 @RequestMapping 标注的控制器实现
  • 传统的基于 Controller 接口（不是 @Controller注解啊）的实现
  • 较新的基于 RouterFunction 接口的实现
  • 它们的处理方法都不一样，为了统一调用，必须适配为 HandlerAdapter 接口

• org.springframework.beans.factory.support.DisposableBeanAdapter – 因为销毁方法多种多样，因此都要适配为 DisposableBean 来统一调用销毁方法

5. Spring 中的 Composite

定义 Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly

典型实现有：

• org.springframework.web.method.support.HandlerMethodArgumentResolverComposite
• org.springframework.web.method.support.HandlerMethodReturnValueHandlerComposite
• org.springframework.web.servlet.handler.HandlerExceptionResolverComposite
• org.springframework.web.servlet.view.ViewResolverComposite

composite 对象的作用是，将分散的调用集中起来，统一调用入口，它的特征是，与具体干活的实现实现同一个接口，当调用 composite 对象的接口方法时，其实是委托具体干活的实现来完成

6. Spring 中的 Decorator

定义 Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality

典型实现：

• org.springframework.web.util.ContentCachingRequestWrapper

7. Spring 中的 Proxy

定义 Provide a surrogate or placeholder for another object to control access to it

装饰器模式注重的是功能增强，避免子类继承方式进行功能扩展，而代理模式更注重控制目标的访问

典型实现：

• org.springframework.aop.framework.JdkDynamicAopProxy
• org.springframework.aop.framework.ObjenesisCglibAopProxy

8. Spring 中的 Chain of Responsibility

定义 Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it

典型实现：

• org.springframework.web.servlet.HandlerInterceptor

9. Spring 中的 Observer

定义 Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically

典型实现：

• org.springframework.context.ApplicationListener
• org.springframework.context.event.ApplicationEventMulticaster
• org.springframework.context.ApplicationEvent

10. Spring 中的 Strategy

定义 Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it

典型实现：

• org.springframework.beans.factory.support.InstantiationStrategy
• org.springframework.core.annotation.MergedAnnotations.SearchStrategy
• org.springframework.boot.autoconfigure.condition.SearchStrategy

11. Spring 中的 Template Method

定义 Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure

典型实现：

• 大部分以 Template 命名的类，如 JdbcTemplate，TransactionTemplate
• 很多以 Abstract 命名的类，如 AbstractApplicationContext

MyBatis 使用了哪些设计模式？在源码中是如何体现的？

它是一款优秀的持久层框架，支持自定义 SQL、存储过程及高级映射。MyBatis 免除了几乎所有的 JDBC 代码以及设置参数和获取结果集的工作，还可以通过简单的 XML 或注解来配置和映射原始类型、接口和 Java POJO（Plain Ordinary Java Object，普通 Java 对象）为数据库中的记录。

典型回答

1.工厂模式

工厂模式想必都比较熟悉，它是 Java 中最常用的设计模式之一。工厂模式就是提供一个工厂类，当有客户端需要调用的时候，只调用这个工厂类就可以得到自己想要的结果，从而无需关注某类的具体实现过程。这就好比你去餐馆吃饭，可以直接点菜，而不用考虑厨师是怎么做的。

工厂模式在 MyBatis 中的典型代表是 SqlSessionFactory。

SqlSession 是 MyBatis 中的重要 Java 接口，可以通过该接口来执行 SQL 命令、获取映射器示例和管理事务，而 SqlSessionFactory 正是用来产生 SqlSession 对象的，所以它在 MyBatis 中是比较核心的接口之一。

工厂模式应用解析：SqlSessionFactory 是一个接口类，它的子类 DefaultSqlSessionFactorys 有一个 openSession(ExecutorType execType) 的方法，其中使用了工厂模式,它会根据传递 ExecutorType 值生成相应的对象然后进行返回。

2.建造者模式（Builder）

建造者模式指的是将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。也就是说建造者模式是通过多个模块一步步实现了对象的构建，相同的构建过程可以创建不同的产品。

例如，组装电脑，最终的产品就是一台主机，然而不同的人对它的要求是不同的，比如设计人员需要显卡配置高的；而影片爱好者则需要硬盘足够大的（能把视频都保存起来），但对于显卡却没有太大的要求，我们的装机人员根据每个人不同的要求，组装相应电脑的过程就是建造者模式。

建造者模式在 MyBatis 中的典型代表是 SqlSessionFactoryBuilder。

普通的对象都是通过 new 关键字直接创建的，但是如果创建对象需要的构造参数很多，且不能保证每个参数都是正确的或者不能一次性得到构建所需的所有参数，那么就需要将构建逻辑从对象本身抽离出来，让对象只关注功能，把构建交给构建类，这样可以简化对象的构建，也可以达到分步构建对象的目的，而 SqlSessionFactoryBuilder 的构建过程正是如此。

在 SqlSessionFactoryBuilder 中构建 SqlSessionFactory 对象的过程是这样的，首先需要通过 XMLConfigBuilder 对象读取并解析 XML 的配置文件，然后再将读取到的配置信息存入到 Configuration 类中，然后再通过 build 方法生成我们需要的 DefaultSqlSessionFactory 对象

SqlSessionFactoryBuilder 类相当于一个建造工厂，先读取文件或者配置信息、再解析配置、然后通过反射生成对象，最后再把结果存入缓存，这样就一步步构建造出一个 SqlSessionFactory 对象。

3.单例模式

单例模式（Singleton Pattern）是 Java 中最简单的设计模式之一，此模式保证某个类在运行期间，只有一个实例对外提供服务，而这个类被称为单例类。 单例模式也比较好理解，比如一个人一生当中只能有一个真实的身份证号，每个收费站的窗口都只能一辆车子一辆车子的经过，类似的场景都是属于单例模式。 单例模式在 MyBatis 中的典型代表是 ErrorContext。 ErrorContext 是线程级别的的单例，每个线程中有一个此对象的单例，用于记录该线程的执行环境的错误信息。

4.适配器模式

适配器模式是指将一个不兼容的接口转换成另一个可以兼容的接口，这样就可以使那些不兼容的类可以一起工作。 例如，最早之前我们用的耳机都是圆形的，而现在大多数的耳机和电源都统一成了方形的 typec 接口，那之前的圆形耳机就不能使用了，只能买一个适配器把圆形接口转化成方形的

而这个转换头就相当于程序中的适配器模式，适配器模式在 MyBatis 中的典型代表是 Log。 MyBatis 中的日志模块适配了以下多种日志类型：

• SLF4J
• Apache Commons Logging
• Log4j 2
• Log4j
• JDK logging

首先 MyBatis 定义了一个 Log 的接口，用于统一和规范接口的行为

SpringBoot 有哪些优点？它和 Spring 有什么区别？

典型回答

小结

本课时首先讲了 Spring 和 Spring Boot 的区别，Spring Boot 本质上是 Spring 的延伸，它是基于 Spring 的，它为快速构建和开发 Spring 提供了有力的支撑；接着介绍了 Spring Boot 的四大特性：更快速的构建能力、起步依赖、内嵌容器支持、Actuator 监控支持等，最后 还介绍了 Spring Boot 启动的 18 个步骤。

作为 Java 开发人员对 Spring 框架都很熟悉，Spring 为 Java 程序提供了全面的基础架构支持，包含了很多非常实用的功能，如 Spring JDBC、Spring AOP、Spring ORM、Spring Test 等，这些模块的出现，大大的缩短了应用程序的开发时间，同时提高了应用开发的效率。

Spring Boot 本质上是 Spring 框架的延伸和扩展，它的诞生是为了简化 Spring 框架初始搭建以及开发的过程，使用它可以不再依赖 Spring 应用程序中的 XML 配置，为更快、更高效的开发 Spring 提供更加有力的支持。Spring Boot 具体的特性如下。

Spring Boot 特性一：更快速的构建能力

Spring Boot 提供了更多的 Starters 用于快速构建业务框架，Starters 可以理解为启动器，它包含了一系列可以集成到应用里面的依赖包，你可以一站式集成 Spring 及其他技术，而不需要到处找依赖包。

Spring Boot 只需要一个依赖项就可以来启动和运行 Web 应用程序，如下所示：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

当我们添加了 Starter 模块支持之后，在项目的构建期，它就会把所有其他依赖项将自动添加到项目中。

这样的例子还有很多，比如测试库，如果是 Spring 项目我们通常要添加 Spring Test、JUnit、Hamcrest 和 Mockito 库；而如果是 Spring Boot 项目的话，只需要添加 spring-boot-starter-test 即可，它会自动帮我们把其他的依赖项添加到项目中。

常见的 Starters 有以下几个：

 spring-boot-starter-test
 spring-boot-starter-web
 spring-boot-starter-data-jpa
 spring-boot-starter-thymeleaf

Spring Boot 特性二：起步依赖

Spring Boot 提供了起步依赖，也就是在创建 Spring Boot 时可以直接勾选依赖模块，这样在项目初始化时就会把相关依赖直接添加到项目中，大大缩短了查询并添加依赖的时间

Spring Boot 特性三：内嵌容器支持

Spring Boot 内嵌了 Tomcat、Jetty、Undertow 三种容器，其默认嵌入的容器是 Tomcat，这个在我们启动 Spring Boot 项目的时候，在控制台上就能看到，具体信息如下：

tomcat.TomcatWebServer :Tomcat started on port(s): 8080 (http) with context path ''

可以看出 Spring Boot 默认使用的是 Tomcat 容器启动的。 我们可以通过修改 pom.xml 来移除内嵌的 Tomcat 更换为其他的容器，比如更换为 Jetty 容器，配置如下：

 <dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-web</artifactId>
     <!-- 移处 Tomcat -->
     <exclusions>
         <exclusion>
             <groupId>org.springframework.boot</groupId>
             <artifactId>spring-boot-starter-tomcat</artifactId>
         </exclusion>
     </exclusions>
 </dependency>
 <!-- 移处 jetty 容器 -->
 <dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-jetty</artifactId>
 </dependency>

当我们添加完成之后，再重新生成 pom.xml 文件，然后再启动 Spring Boot 项目容器信息就变了，如下所示：

 o.e.jetty.server.AbstractConnector: Started ServerConnector@53f9009d{HTTP/1.1, (http/1.1)}{0.0.0.0:8080}
 o.s.b.web.embedded.jetty.JettyWebServer

可以看出 Spring Boot 使用了我们指定的 Jetty 容器启动了。

Spring Boot 特性四：Actuator 监控

Spring Boot 自带了 Actuator 监控功能，主要用于提供对应用程序监控，以及控制的能力，比如监控应用程序的运行状况，或者内存、线程池、Http 请求统计等，同时还提供了关闭应用程序等功能。

Actuator 提供了 19 个接口

数据库相关

MySQL 的运行机制是什么？它有哪些引擎？

典型回答

MySQL 数据库运行流程的几个阶段，先从连接器授权，再到分析器进行语法分析。如果是 MySQL 8.0 之前的 select 语句可能会先查询缓存，如果有缓存则会直接返回结果给客户端，否则会从分析器进入优化器生成 SQL 的执行计划，然后交给执行器调用操作引擎执行相关的 SQL，再把结果返回给客户端。

MySQL 的执行流程是这样的，首先客户端先要发送用户信息去服务器端进行授权认证

当连接服务器端成功之后就可以正常的执行 SQL 命令了，MySQL 服务器拿到 SQL 命令之后，会使用 MySQL 的分析器解析 SQL 指令，同时会根据语法分析器验证 SQL 指令，查询 SQL 指令是否满足 MySQL 的语法规则。如果不支持此语法，则会提示“SQL syntax”语法错误信息。

当分析器验证并解析 SQL 命令之后，会进入优化器阶段，执行生成计划，并设置相应的索引；当上面的这些步骤都执行完之后，就进入了执行器阶段，并开始正式执行 SQL 命令。同样在执行命令之前，它会先对你的执行命令进行权限查询，看看是否有操作某个表的权限，如果有相应的权限，执行器就去调用 MySQL 数据库引擎提供的接口，执行相应的命令；如果是非查询操作会记录对应的操作日志，再命令执行完成之后返回结果给客户端，这就是整个 MySQL 操作的完整流程。

需要注意的是，如果执行的是 select 语句并且是 MySQL 8.0 之前的版本的话，则会去 MySQL 的查询缓存中查看之前是否有执行过这条 SQL；如果缓存中可以查到，则会直接返回查询结果，这样查询性能就会提升很高。

常用的数据库引擎有 InnoDB、MyISAM、MEMORY 等，其中 InnoDB 支持事务功能，而 MyISAM 不支持事务，但 MyISAM 拥有较高的插入和查询的速度。而 MEMORY 是内存型的数据库引擎，它会将表中的数据存储到内存中，因为它是内存级的数据引擎，因此具备最快速的查询效率，但它的缺点是，重启数据库之后，所有数据都会丢失，因为这些数据是存放在内存中的。

知识扩展

• 查询缓存在什么问题？
• 如何选择数据库的引擎？
• InnoDB 自增索引的持久化问题。

1.查询缓存在什么问题？

查询缓存的功能要根据实际的情况进行使用，建议设置为按需缓存（DEMAND）模式，因为查询缓存的功能并不是那么好用。比如我们设置了 query_cache_type = ON，当我们好不容易缓存了很多查询语句之后，任何一条对此表的更新操作都会把和这个表关联的所有查询缓存全部清空，那么在更新频率相对较高的业务中，查询缓存功能完全是一个鸡肋。因此，在 MySQL 8.0 的版本中已经完全移除了此功能，也就是说在 MySQL 8.0 之后就完全没有查询缓存这个概念和功能了

2.如何选择数据库的引擎？

选择数据库引擎要从实际的业务情况入手，比如是否需要支持事务？是否需要支持外键？是否需要支持持久化？以及是否支持地理位置存储以及索引等方面进行综合考量。

我们最常用的数据库引擎是 InnoDB，它是 MySQL 5.5.5 之后的默认引擎，其优点是支持事务，且支持 4 种隔离级别。

• 读未提交：也就是一个事务还没有提交时，它做的变更就能被其他事务看到。
• 读已提交：指的是一个事务只有提交了之后，其他事务才能看得到它的变更。
• 可重复读：此方式为默认的隔离级别，它是指一个事务在执行过程中（从开始到结束）看到的数据都是一致的，在这个过程中未提交的变更对其他事务也是不可见的。
• 串行化：是指对同一行记录的读、写都会添加读锁和写锁，后面访问的事务必须等前一个事务执行完成之后才能继续执行，所以这种事务的执行效率很低。

InnoDB 还支持外键、崩溃后的快速恢复、支持全文检索（需要 5.6.4+ 版本）、集群索引，以及地理位置类型的存储和索引等功能。

MyISAM 引擎是 MySQL 原生的引擎，但它并不支持事务功能，这也是后来被 InnoDB 替代为默认引擎的主要原因。MyISAM 有独立的索引文件，因此在读取数据方面的性能很高，它也支持全文索引、地理位置存储和索引等功能，但不支持外键。

InnoDB 和 MyISAM 都支持持久化，但 MEMORY 引擎是将数据直接存储在内存中了，因此在重启服务之后数据就会丢失，但它带来的优点是执行速度很快，可以作为临时表来使用。

3.InnoDB 自增主键

在面试的过程中我们经常看到这样一道面试题：

例子： 在一个自增表里面一共有 5 条数据，id 从 1 到 5，删除了最后两条数据，也就是 id 为 4 和 5 的数据，之后重启的 MySQL 服务器，又新增了一条数据，请问新增的数据 id 为几？

我们通常的答案是如果表为 MyISAM 引擎，那么 id 就是 6，如果是 InnoDB 那么 id 就是 4。

但是这个情况在高版本的 InnoDB 中，也就是 MySQL 8.0 之后就不准确了，它的 id 就不是 4 了，而是 6 了。因为在 MySQL 8.0 之后 InnoDB 会把索引持久化到日志中，重启服务之后自增索引是不会丢失的，因此答案是 6，这个需要面试者注意一下。

MySQL 的优化方案有哪些？

典型回答

MySQL 数据库常见的优化手段分为三个层面：SQL 和索引优化、数据库结构优化、系统硬件优化等，然而每个大的方向中又包含多个小的优化点，下面我们具体来看看。

1.SQL 和索引优化

此优化方案指的是通过优化 SQL 语句以及索引来提高 MySQL 数据库的运行效率，具体内容如下。

• ① 使用正确的索引

索引是数据库中最重要的概念之一，也是提高数据库性能最有效的手段之一，它的诞生本身就是为了提高数据查询效率的，就像字典的目录一样，通过目录可以很快找到相关的内容

假如我们没有添加索引，那么在查询时就会触发全表扫描，因此查询的数据就会很多，并且查询效率会很低，为了提高查询的性能，我们就需要给最常使用的查询字段上，添加相应的索引，这样才能提高查询的性能。

小贴士： 我们应该尽可能的使用主键查询，而非其他索引查询，因为主键查询不会触发回表查询，因此节省了一部分时间，变相的提高了查询的性能。

在 MySQL 5.0 之前的版本要尽量避免使用 or 查询，可以使用 union 或者子查询来替代，因为早期的 MySQL 版本使用 or 查询可能会导致索引失效，在 MySQL 5.0 之后的版本中引入了索引合并，简单来说就是把多条件查询，比如 or 或 and 查询的结果集进行合并交集或并集的功能，因此就不会导致索引失效的问题了。

避免在 where 查询条件中使用 != 或者 <> 操作符，因为这些操作符会导致查询引擎放弃索引而进行全表扫描。

适当使用前缀索引，MySQL 是支持前缀索引的，也就是说我们可以定义字符串的一部分来作为索引。我们知道索引越长占用的磁盘空间就越大，那么在相同数据页中能放下的索引值也就越少，这就意味着搜索索引需要的查询时间也就越长，进而查询的效率就会降低，所以我们可以适当的选择使用前缀索引，以减少空间的占用和提高查询效率。比如，邮箱的后缀都是固定的“@xxx.com”，那么类似这种后面几位为固定值的字段就非常适合定义为前缀索引。

• ② 查询具体的字段而非全部字段

要尽量避免使用 select *，而是查询需要的字段，这样可以提升速度，以及减少网络传输的带宽压力。

• ③ 优化子查询

尽量使用 Join 语句来替代子查询，因为子查询是嵌套查询，而嵌套查询会新创建一张临时表，而临时表的创建与销毁会占用一定的系统资源以及花费一定的时间，但 Join 语句并不会创建临时表，因此性能会更高。

• ④ 注意查询结果集

我们要尽量使用小表驱动大表的方式进行查询，也就是如果 B 表的数据小于 A 表的数据，那执行的顺序就是先查 B 表再查 A 表，具体查询语句如下：

 select name from A where id in (select id from B);

• ⑤ 不要在列上进行运算操作

不要在列字段上进行算术运算或其他表达式运算，否则可能会导致查询引擎无法正确使用索引，从而影响了查询的效率。

• ⑥ 适当增加冗余字段

增加冗余字段可以减少大量的连表查询，因为多张表的连表查询性能很低，所有可以适当的增加冗余字段，以减少多张表的关联查询，这是以空间换时间的优化策略。

2.数据库结构优化

• ① 最小数据长度

一般说来数据库的表越小，那么它的查询速度就越快，因此为了提高表的效率，应该将表的字段设置的尽可能小，比如身份证号，可以设置为 char(18) 就不要设置为 varchar(18)。

• ② 使用最简单数据类型

能使用 int 类型就不要使用 varchar 类型，因为 int 类型比 varchar 类型的查询效率更高。

• ③ 尽量少定义 text 类型

text 类型的查询效率很低，如果必须要使用 text 定义字段，可以把此字段分离成子表，需要查询此字段时使用联合查询，这样可以提高主表的查询效率。

• ④ 适当分表、分库策略

分表和分库方案也是我们经常说的垂直分隔（分表）和水平分隔（分库）。 分表是指当一张表中的字段更多时，可以尝试将一张大表拆分为多张子表，把使用比较高频的主信息放入主表中，其他的放入子表，这样我们大部分查询只需要查询字段更少的主表就可以完成了，从而有效的提高了查询的效率。

分库是指将一个数据库分为多个数据库。比如我们把一个数据库拆分为了多个数据库，一个主数据库用于写入和修改数据，其他的用于同步主数据并提供给客户端查询，这样就把一个库的读和写的压力，分摊给了多个库，从而提高了数据库整体的运行效率。

3.硬件优化

MySQL 对硬件的要求主要体现在三个方面：磁盘、网络和内存。

• ① 磁盘

磁盘应该尽量使用有高性能读写能力的磁盘，比如固态硬盘，这样就可以减少 I/O 运行的时间，从而提高了 MySQL 整体的运行效率。

磁盘也可以尽量使用多个小磁盘而不是一个大磁盘，因为磁盘的转速是固定的，有多个小磁盘就相当于拥有多个并行运行的磁盘一样。

• ② 网络

保证网络带宽的通畅（低延迟）以及够大的网络带宽是 MySQL 正常运行的基本条件，如果条件允许的话也可以设置多个网卡，以提高网络高峰期 MySQL 服务器的运行效率。

• ③ 内存

MySQL 服务器的内存越大，那么存储和缓存的信息也就越多，而内存的性能是非常高的，从而提高了整个 MySQL 的运行效率。

知识扩展

• 联合索引需要注意什么问题？
• 如何排查慢查询？

1.正确使用联合索引

使用了 B+ 树的 MySQL 数据库引擎，比如 InnoDB 引擎，在每次查询复合字段时是从左往右匹配数据的，因此在创建联合索引的时候需要注意索引创建的顺序。例如，我们创建了一个联合索引是 idx(name,age,sex)，那么当我们使用，姓名+年龄+性别、姓名+年龄、姓名等这种最左前缀查询条件时，就会触发联合索引进行查询；然而如果非最左匹配的查询条件，例如，性别+姓名这种查询条件就不会触发联合索引。 当然，当我们已经有了（name,age）这个联合索引之后，一般情况下就不需要在 name 字段单独创建索引了，这样就可以少维护一个索引。

2.慢查询

慢查询通常的排查手段是先使用慢查询日志功能，查询出比较慢的 SQL 语句，然后再通过 explain 来查询 SQL 语句的执行计划，最后分析并定位出问题的根源，再进行处理。

慢查询日志指的是在 MySQL 中可以通过配置来开启慢查询日志的记录功能，超过 long_query_time 值的 SQL 将会被记录在日志中。我们可以通过设置“slow_query_log=1”来开启慢查询

需要注意的是，在开启慢日志功能之后，会对 MySQL 的性能造成一定的影响，因此在生产环境中要慎用此功能。

当 type 为 all 时，则表示全表扫描，因此效率会比较低，此时需要查看一下为什么会造成此种原因，是没有创建索引还是索引创建的有问题？以此来优化整个 MySQL 运行的速度。

explain 执行计划的使用示例 SQL 如下：

 explain select * from person where uname = 'Java';

它的执行结果如下图所示：

以上字段中最重要的就是 type 字段，它的所有值如下所示：

Redis 的过期策略和内存淘汰机制有什么区别？

典型回答

我们在新增 Redis 缓存时可以设置缓存的过期时间，该时间保证了数据在规定的时间内失效，可以借助这个特性来实现很多功能。比如，存储一定天数的用户（登录）会话信息，这样在一定范围内用户不用重复登录了，但为了安全性，需要在一定时间之后重新验证用户的信息。因此，我们可以使用 Redis 设置过期时间来存储用户的会话信息。

对于已经过期的数据，Redis 将使用两种策略来删除这些过期键，它们分别是惰性删除和定期删除。

惰性删除是指 Redis 服务器不主动删除过期的键值，而是当访问键值时，再检查当前的键值是否过期，如果过期则执行删除并返回 null 给客户端；如果没过期则正常返回值信息给客户端。

它的优点是不会浪费太多的系统资源，只是在每次访问时才检查键值是否过期。缺点是删除过期键不及时，造成了一定的空间浪费。

除了惰性删除之外，Redis 还提供了定期删除功能以弥补惰性删除的不足。

定期删除是指 Redis 服务器每隔一段时间会检查一下数据库，看看是否有过期键可以被清除。

默认情况下 Redis 定期检查的频率是每秒扫描 10 次，用于定期清除过期键。

小贴士： 定期删除的扫描并不是遍历所有的键值对，这样的话比较费时且太消耗系统资源。Redis 服务器采用的是随机抽取形式，每次从过期字典中，取出 20 个键进行过期检测，过期字典中存储的是所有设置了过期时间的键值对。如果这批随机检查的数据中有 25% 的比例过期，那么会再抽取 20 个随机键值进行检测和删除，并且会循环执行这个流程，直到抽取的这批数据中过期键值小于 25%，此次检测才算完成。

以上是 Redis 服务器对待过期键的处理方案，当 Redis 的内存超过最大允许的内存之后，Redis 会触发内存淘汰策略，这和过期策略是完全不同的两个概念，经常有人把二者搞混，这两者一个是在正常情况下清除过期键，一个是在非正常情况下为了保证 Redis 顺利运行的保护策略。

当 Redis 内存不够用时，Redis 服务器会根据服务器设置的淘汰策略，删除一些不常用的数据，以保证 Redis 服务器的顺利运行。

Redis 内存淘汰策略

在 4.0 版本之前 Redis 的内存淘汰策略有以下 6 种。

• noeviction：不淘汰任何数据，当内存不足时，执行缓存新增操作会报错，它是 Redis 默认内存淘汰策略。
• allkeys-lru：淘汰整个键值中最久未使用的键值。
• allkeys-random：随机淘汰任意键值。
• volatile-lru：淘汰所有设置了过期时间的键值中最久未使用的键值。
• volatile-random：随机淘汰设置了过期时间的任意键值。
• volatile-ttl：优先淘汰更早过期的键值。

可以看出我们上面示例使用的是 Redis 默认的内存淘汰策略“noeviction”。 而在 Redis 4.0 版本中又新增了 2 种淘汰策略：

• volatile-lfu，淘汰所有设置了过期时间的键值中最少使用的键值；
• allkeys-lfu，淘汰整个键值中最少使用的键值。

小贴士： 从以上内存淘汰策略中可以看出，allkeys-xxx 表示从所有的键值中淘汰数据，而 volatile-xxx 表示从设置了过期键的键值中淘汰数据。

Redis 内存淘汰算法

内存淘汰算法主要包含两种：LRU 淘汰算法和 LFU 淘汰算法。

LRU（ Least Recently Used，最近最少使用）淘汰算法：是一种常用的页面置换算法，也就是说最久没有使用的缓存将会被淘汰。

LRU 是基于链表结构实现的，链表中的元素按照操作顺序从前往后排列，最新操作的键会被移动到表头，当需要进行内存淘汰时，只需要删除链表尾部的元素即可。

Redis 使用的是一种近似 LRU 算法，目的是为了更好的节约内存，它的实现方式是给现有的数据结构添加一个额外的字段，用于记录此键值的最后一次访问时间。Redis 内存淘汰时，会使用随机采样的方式来淘汰数据，它是随机取 5 个值 (此值可配置) ，然后淘汰最久没有使用的数据。

LFU（Least Frequently Used，最不常用的）淘汰算法：最不常用的算法是根据总访问次数来淘汰数据的，它的核心思想是“如果数据过去被访问多次，那么将来被访问的频率也更高”。

LFU 相对来说比 LRU 更“智能”，因为它解决了使用频率很低的缓存，只是最近被访问了一次就不会被删除的问题。如果是使用 LRU 类似这种情况数据是不会被删除的，而使用 LFU 的话，这个数据就会被删除。

小结

本课时我们讲了 Redis 的过期删除策略：惰性删除 + 定期删除；还讲了 Redis 的内存淘汰策略，它和过期策略是完全不同的两个概念，内存淘汰策略是当内存不够用时才会触发的一种机制，它在 Redis 4.0 之后提供了 8 种内存淘汰策略，这些淘汰策略主要使用了近 LRU 淘汰算法和 LFU 淘汰算法。

Redis 怎样实现的分布式锁？

分布式锁是控制分布式系统之间同步访问共享资源的一种方式。是为了解决分布式系统中，不同的系统或是同一个系统的不同主机共享同一个资源的问题，它通常会采用互斥来保证程序的一致性，这就是分布式锁的用途以及执行原理。

分布式锁的常见实现方式有四种：

• 基于 MySQL 的悲观锁来实现分布式锁，这种方式使用的最少，因为这种实现方式的性能不好，且容易造成死锁；
• 基于 Memcached 实现分布式锁，可使用 add 方法来实现，如果添加成功了则表示分布式锁创建成功；
• 基于 Redis 实现分布式锁，这也是本课时要介绍的重点，可以使用 setnx 方法来实现；
• 基于 ZooKeeper 实现分布式锁，利用 ZooKeeper 顺序临时节点来实现。

由于 MySQL 的执行效率问题和死锁问题，所以这种实现方式会被我们先排除掉，而 Memcached 和 Redis 的实现方式比较类似，但因为 Redis 技术比较普及，所以会优先使用 Redis 来实现分布式锁，而 ZooKeeper 确实可以很好的实现分布式锁。但此技术在中小型公司的普及率不高，尤其是非 Java 技术栈的公司使用的较少，如果只是为了实现分布式锁而重新搭建一套 ZooKeeper 集群，显然实现成本和维护成本太高，所以综合以上因素，我们本文会采用 Redis 来实现分布式锁。

知识扩展

• 单机锁有哪些？它为什么不能在分布式环境下使用？
• Redis 是如何实现分布式锁的？可能会遇到什么问题？
• 分布式锁超时的话会有什么问题？如何解决？

单机锁

程序中使用的锁叫单机锁，我们日常中所说的“锁”都泛指单机锁，其分类有很多，大体可分为以下几类：

• 悲观锁，是数据对外界的修改采取保守策略，它认为线程很容易把数据修改掉，因此在整个数据被修改的过程中都会采取锁定状态，直到一个线程使用完，其他线程才可以继续使用，典型应用是 synchronized；
• 乐观锁，和悲观锁的概念恰好相反，乐观锁认为一般情况下数据在修改时不会出现冲突，所以在数据访问之前不会加锁，只是在数据提交更改时，才会对数据进行检测，典型应用是 ReadWriteLock 读写锁；
• 可重入锁，也叫递归锁，指的是同一个线程在外面的函数获取了锁之后，那么内层的函数也可以继续获得此锁，在 Java 语言中 ReentrantLock 和 synchronized 都是可重入锁；
• 独占锁和共享锁，只能被单线程持有的锁叫做独占锁，可以被多线程持有的锁叫共享锁，独占锁指的是在任何时候最多只能有一个线程持有该锁，比如 ReentrantLock 就是独占锁；而 ReadWriteLock 读写锁允许同一时间内有多个线程进行读操作，它就属于共享锁。

单机锁之所以不能应用在分布式系统中是因为，在分布式系统中，每次请求可能会被分配在不同的服务器上，而单机锁是在单台服务器上生效的。如果是多台服务器就会导致请求分发到不同的服务器，从而导致锁代码不能生效，因此会造成很多异常的问题，那么单机锁就不能应用在分布式系统中了。

使用 Redis 实现分布式锁

使用 Redis 实现分布式锁主要需要使用 setnx 方法，也就是 set if not exists（不存在则创建）

在 Redis 2.6.12 中我们可以使用一条 set 命令来执行键值存储，并且可以判断键是否存在以及设置超时时间了，如下代码所示：

 127.0.0.1:6379> set lock true ex 30 nx
 OK #创建锁成功

其中，ex 是用来设置超时时间的，而 nx 是 not exists 的意思，用来判断键是否存在。如果返回的结果为“OK”则表示创建锁成功，否则表示此锁有人在使用。

锁超时

从上面的内容可以看出，使用 set 命令之后好像一切问题都解决了，但在这里我要告诉你，其实并没有。例如，我们给锁设置了超时时间为 10s，但程序的执行需要使用 15s，那么在第 10s 时此锁因为超时就会被释放，这时候线程二在执行 set 命令时正常获取到了锁，于是在很短的时间内 2s 之后删除了此锁，这就造成了锁被误删的情况

锁被误删的解决方案是在使用 set 命令创建锁时，给 value 值设置一个归属标识。例如，在 value 中插入一个 UUID，每次在删除之前先要判断 UUID 是不是属于当前的线程，如果属于再删除，这样就避免了锁被误删的问题。

**注意：**在锁的归属判断和删除的过程中，不能先判断锁再删除锁，如下代码所示：

 if(uuid.equals(uuid)){ // 判断是否是自己的锁
     del(luck); // 删除锁
 }

应该把判断和删除放到一个原子单元中去执行，因此需要借助 Lua 脚本来执行，在 Redis 中执行 Lua 脚本可以保证这批命令的原子性

锁超时可以通过两种方案来解决：

• 把执行耗时的方法从锁中剔除，减少锁中代码的执行时间，保证锁在超时之前，代码一定可以执行完；
• 把锁的超时时间设置的长一些，正常情况下我们在使用完锁之后，会调用删除的方法手动删除锁，因此可以把超时时间设置的稍微长一些。

Redis 中如何实现的消息队列？实现的方式有几种？

Redis 实现消息队列的四种方式，他们分别是：

• 使用 List 实现消息队列；
• 使用 ZSet 实现消息队列；
• 使用发布订阅者模式实现消息队列；
• 使用 Stream 实现消息队列。

其中发布订阅者模式不支持消息持久化、而其他三种方式支持持久化，并且 Stream 方式支持消费者确认。我们还使用 Jedis 框架完成了 List 和 Stream 的消息队列功能，需要注意的是在 List 中需要使用 brpop 来读取消息，而不是 rpop，这样可以解决没有任务时 ，while 一直循环浪费系统资源的问题。

Redis 是如何实现高可用的？

Redis 高可用的手段主要有以下四种：

• 数据持久化
• 主从数据同步（主从复制）
• Redis 哨兵模式（Sentinel）
• Redis 集群（Cluster）

其中数据持久化保证了系统在发生宕机或者重启之后数据不会丢失，增加了系统的可靠性和减少了系统不可用的时间（省去了手动恢复数据的过程）；而主从数据同步可以将数据存储至多台服务器，这样当遇到一台服务器宕机之后，可以很快地切换至另一台服务器以继续提供服务；哨兵模式用于发生故障之后自动切换服务器；而 Redis 集群提供了多主多从的 Redis 分布式集群环境，用于提供性能更好的 Redis 服务，并且它自身拥有故障自动切换的能力。

1.数据持久化

持久化功能是 Redis 和 Memcached 的主要区别之一，因为只有 Redis 提供了此功能。 在 Redis 4.0 之前数据持久化方式有两种：AOF 方式和 RDB 方式。

• RDB（Redis DataBase，快照方式）是将某一个时刻的内存数据，以二进制的方式写入磁盘。
• AOF（Append Only File，文件追加方式）是指将所有的操作命令，以文本的形式追加到文件中。

RDB 默认的保存文件为 dump.rdb，优点是以二进制存储的，因此占用的空间更小、数据存储更紧凑，并且与 AOF 相比，RDB 具备更快的重启恢复能力。

AOF 默认的保存文件为 appendonly.aof，它的优点是存储频率更高，因此丢失数据的风险就越低，并且 AOF 并不是以二进制存储的，所以它的存储信息更易懂。缺点是占用空间大，重启之后的数据恢复速度比较慢。

可以看出 RDB 和 AOF 各有利弊，RDB 具备更快速的数据重启恢复能力，并且占用更小的磁盘空间，但有数据丢失的风险；而 AOF 文件的可读性更高，但却占用了更大的空间，且重启之后的恢复速度更慢，于是在 Redis 4.0 就推出了混合持久化的功能。

混合持久化的功能指的是 Redis 可以使用 RDB + AOF 两种格式来进行数据持久化，这样就可以做到扬长避短物尽其用了

2.Redis 主从同步

主从同步是 Redis 多机运行中最基础的功能，它是把多个 Redis 节点组成一个 Redis 集群，在这个集群当中有一个主节点用来进行数据的操作，其他从节点用于同步主节点的内容，并且提供给客户端进行数据查询。

Redis 主从同步分为：主从模式和从从模式。主从模式就是一个主节点和多个一级从节点

3.Redis 哨兵模式

Redis 主从复制模式有那么多的优点，但是有一个致命的缺点，就是当 Redis 的主节点宕机之后，必须人工介入手动恢复，那么到特殊时间段，比如公司组织全体团建或者半夜突然发生主节点宕机的问题，此时如果等待人工去处理就会很慢，这个时间是我们不允许的，并且我们还需要招聘专职的人来负责数据恢复的事，同时招聘的人还需要懂得相关的技术才能胜任这份工作。既然如此的麻烦，那有没有简单一点的解决方案，这个时候我们就需要用到 Redis 的哨兵模式了。

Redis 哨兵模式就是用来监视 Redis 主从服务器的，当 Redis 的主从服务器发生故障之后，Redis 哨兵提供了自动容灾修复的功能

有了哨兵功能之后，就再也不怕 Redis 主从服务器宕机了。哨兵的工作原理是每个哨兵会以每秒钟 1 次的频率，向已知的主服务器和从服务器，发送一个 PING 命令。如果最后一次有效回复 PING 命令的时间，超过了配置的最大下线时间（Down-After-Milliseconds）时，默认是 30s，那么这个实例会被哨兵标记为主观下线。

如果一个主服务器被标记为主观下线，那么正在监视这个主服务器的所有哨兵节点，要以每秒 1 次的频率确认主服务器是否进入了主观下线的状态。如果有足够数量（quorum 配置值）的哨兵证实该主服务器为主观下线，那么这个主服务器被标记为客观下线。此时所有的哨兵会按照规则（协商）自动选出新的主节点服务器，并自动完成主服务器的自动切换功能，而整个过程都是无须人工干预的。

4.Redis 集群

Redis 集群也就是 Redis Cluster，它是 Redis 3.0 版本推出的 Redis 集群方案，将数据分布在不同的主服务器上，以此来降低系统对单主节点的依赖，并且可以大大提高 Redis 服务的读写性能。Redis 集群除了拥有主从模式 + 哨兵模式的所有功能之外，还提供了多个主从节点的集群功能，实现了真正意义上的分布式集群服务

edis 集群可以实现数据分片服务，也就是说在 Redis 集群中有 16384 个槽位用来存储所有的数据，当我们有 N 个主节点时，可以把 16384 个槽位平均分配到 N 台主服务器上。当有键值存储时，Redis 会使用 crc16 算法进行 hash 得到一个整数值，然后用这个整数值对 16384 进行取模来得到具体槽位，再把此键值存储在对应的服务器上，读取操作也是同样的道理，这样我们就实现了数据分片的功能。

小结

本课时我们讲了保障 Redis 高可用的 4 种手段：数据持久化保证了数据不丢失；Redis 主从让 Redis 从单机变成了多机。它有两种模式：主从模式和从从模式，但当主节点出现问题时，需要人工手动恢复系统；Redis 哨兵模式用来监控 Redis 主从模式，并提供了自动容灾恢复的功能。最后是 Redis 集群，除了可以提供主从和哨兵的功能之外，还提供了多个主从节点的集群功能，这样就可以把数据均匀的存储各个主机主节点上，实现了系统的横向扩展，大大提高了 Redis 的并发处理能力。

Java 进阶

JVM 的内存布局和运行原理？

实际的工作是将编译的 class 代码（字节码）翻译成底层操作系统可以运行的机器码并且进行调用执行，这也是 Java 程序能够“一次编写，到处运行”的原因（因为它会根据特定的操作系统生成对应的操作指令）。JVM 的功能很强大，像 Java 对象的创建、使用和销毁，还有垃圾回收以及某些高级的性能优化，例如，热点代码检测等功能都是在 JVM 中进行的。

典型回答

堆

堆（Java Heap） 也叫 Java 堆或者是 GC 堆，它是一个线程共享的内存区域，也是 JVM 中占用内存最大的一块区域，Java 中所有的对象都存储在这里。 《Java虚拟机规范》对 Java 堆的描述是：“所有的对象实例以及数组都应当在堆上分配”。但这在技术日益发展的今天已经有点不那么“准确”了，比如 JIT（Just In Time Compilation，即时编译 ）优化中的逃逸分析，使得变量可以直接在栈上被分配。 当对象或者是变量在方法中被创建之后，其指针可能被线程所引用，而这个对象就被称作指针逃逸或者是引用逃逸。 比如以下代码中的 sb 对象的逃逸：

 public static StringBuffer createString() {
     StringBuffer sb = new StringBuffer();
     sb.append("Java");
     return sb;
 }

sb 虽然是一个局部变量，但上述代码可以看出，它被直接 return 出去了，因此可能被赋值给了其他变量，并且被完全修改，于是此 sb 就逃逸到了方法外部。 想要 sb 变量不逃逸也很简单，可以改为如下代码：

 public static String createString() {
     StringBuffer sb = new StringBuffer();
     sb.append("Java");
     return sb.toString();
 }

小贴士：通过逃逸分析可以让变量或者是对象直接在栈上分配，从而极大地降低了垃圾回收的次数，以及堆分配对象的压力，进而提高了程序的整体运行效率。

回到主题，堆大小的值可通过 -Xms 和 -Xmx 来设置（设置初始化的时候内存栈的大小和最大内存数），当堆超过最大值时就会抛出 OOM（OutOfMemoryError）异常。

方法区

方法区（Method Area） 也被称为非堆区，用于和“Java 堆”的概念进行区分，它也是线程共享的内存区域，用于存储已经被 JVM 加载的类型信息、常量、静态变量、代码缓存等数据。

说到方法区有人可能会联想到“永久代”，但对于《Java虚拟机规范》来说并没有规定这样一个区域，同样它也只是 HotSpot 中特有的一个概念。这是因为 HotSpot 技术团队把垃圾收集器的分代设计扩展到方法区之后才有的一个概念，可以理解为 HotSpot 技术团队只是用永久代来实现方法区而已，但这会导致一个致命的问题，这样设计更容易造成内存溢出。因为永久代有 -XX：MaxPermSize（方法区分配的最大内存）的上限，即使不设置也会有默认的大小。例如，32 位操作系统中的 4GB 内存限制等，并且这样设计导致了部分的方法在不同类型的 Java 虚拟机下的表现也不同，比如 String::intern() 方法。所以在 JDK 1.7 时 HotSpot 虚拟机已经把原本放在永久代的字符串常量池和静态变量等移出了方法区，并且在 JDK 1.8 中完全废弃了永久代的概念。

程序计数器

程序计数器（Program Counter Register） 线程独有一块很小的内存区域，保存当前线程所执行字节码的位置，包括正在执行的指令、跳转、分支、循环、异常处理等。

虚拟机栈

虚拟机栈也叫 Java 虚拟机栈（Java Virtual Machine Stack），和程序计数器相同它也是线程独享的，用来描述 Java 方法的执行，在每个方法被执行时就会同步创建一个栈帧，用来存储局部变量表、操作栈、动态链接、方法出口等信息。当调用方法时执行入栈，而方法返回时执行出栈。

本地方法栈

本地方法栈（Native Method Stacks）与虚拟机栈类似，它是线程独享的，并且作用也和虚拟机栈类似。只不过虚拟机栈是为虚拟机中执行的 Java 方法服务的，而本地方法栈则是为虚拟机使用到的本地（Native）方法服务。

JVM 的执行流程是，首先先把 Java 代码（.java）转化成字节码（.class），然后通过类加载器将字节码加载到内存中，所谓的内存也就是我们上面介绍的运行时数据区，但字节码并不是可以直接交给操作系统执行的机器码，而是一套 JVM 的指令集。这个时候需要使用特定的命令解析器也就是我们俗称的执行引擎（Execution Engine） 将字节码翻译成可以被底层操作系统执行的指令再去执行，这样就实现了整个 Java 程序的运行，这也是 JVM 的整体执行流程。

考点分析

和此知识点相关的面试题还有这些：类的加载分为几个阶段？每个阶段代表什么含义？加载了什么内容？

知识扩展——类加载

类的生命周期会经历以下 7 个阶段：

• 加载阶段（Loading）
• 验证阶段（Verification）
• 准备阶段（Preparation）
• 解析阶段（Resolution）
• 初始化阶段（Initialization）
• 使用阶段（Using）
• 卸载阶段（Unloading）

其中验证、准备、解析 3 个阶段统称为连接（Linking），如下图所示：

我们平常所说的 JVM 类加载通常指的就是前五个阶段：加载、验证、准备、解析、初始化等，接下来我们分别来看看。

0. 加载阶段

此阶段用于查到相应的类（通过类名进行查找）并将此类的字节流转换为方法区运行时的数据结构，然后再在内存中生成一个能代表此类的 java.lang.Class 对象，作为其他数据访问的入口。

小贴士：需要注意的是加载阶段和连接阶段的部分动作有可能是交叉执行的，比如一部分字节码文件格式的验证，在加载阶段还未完成时就已经开始验证了。

1. 验证阶段

此步骤主要是为了验证字节码的安全性，如果不做安全校验的话可能会载入非安全或有错误的字节码，从而导致系统崩溃，它是 JVM 自我保护的一项重要举措。

验证的主要动作大概有以下几个：

• 文件格式校验包括常量池中的常量类型、Class 文件的各个部分是否被删除或被追加了其他信息等；
• 元数据校验包括父类正确性校验（检查父类是否有被 final 修饰）、抽象类校验等；
• 字节码校验，此步骤最为关键和复杂，主要用于校验程序中的语义是否合法且符合逻辑；
• 符号引用校验，对类自身以外比如常量池中的各种符号引用的信息进行匹配性校验。

2. 准备阶段

此阶段是用来初始化并为类中定义的静态变量分配内存的，这些静态变量会被分配到方法区上。 HotSpot 虚拟机在 JDK 1.7 之前都在方法区，而 JDK 1.8 之后此变量会随着类对象一起存放到 Java 堆中。

3. 解析阶段

此阶段主要是用来解析类、接口、字段及方法的，解析时会把符号引用替换成直接引用。

所谓的符号引用是指以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可；而直接引用是可以直接指向目标的指针、相对偏移量或者是一个能间接定位到目标的句柄。

符号引用和直接引用有一个重要的区别：使用符号引用时被引用的目标不一定已经加载到内存中；而使用直接引用时，引用的目标必定已经存在虚拟机的内存中了。

4. 初始化

初始化阶段 JVM 就正式开始执行类中编写的 Java 业务代码了。到这一步骤之后，类的加载过程就算正式完成了。

小结

本课时讲了 JVM 的内存布局主要分为：堆、方法区、程序计数器、虚拟机栈和本地方法栈，并讲了 JVM 的执行流程，先把 Java 代码编译成字节码，再把字节码加载到运行时数据区；然后交给 JVM 引擎把字节码翻译为操作系统可以执行的指令进行执行；最后还讲了类加载的 5 个阶段：加载、验证、准备、解析和初始化。

垃圾回收算法有哪些？

垃圾回收器首先要做的就是，判断一个对象是存活状态还是死亡状态，死亡的对象将会被标识为垃圾数据并等待收集器进行清除。

判断一个对象是否为死亡状态的常用算法有两个：引用计数器算法和可达性分析算法。 引用计数算法（Reference Counting） 属于垃圾收集器最早的实现算法了，它是指在创建对象时关联一个与之相对应的计数器，当此对象被使用时加 1，相反销毁时 -1。当此计数器为 0 时，则表示此对象未使用，可以被垃圾收集器回收。

引用计数算法的优缺点很明显，其优点是垃圾回收比较及时，实时性比较高，只要对象计数器为 0，则可以直接进行回收操作；而缺点是无法解决循环引用的问题

可达性分析算法（Reachability Analysis） 是目前商业系统中所采用的判断对象死亡的常用算法，它是指从对象的起点（GC Roots）开始向下搜索，如果对象到 GC Roots 没有任何引用链相连时，也就是说此对象到 GC Roots 不可达时，则表示此对象可以被垃圾回收器所回收

当确定了对象的状态之后（存活还是死亡）接下来就是进行垃圾回收了，垃圾回收的常见算法有以下几个：

• 标记-清除算法
• 标记-复制算法
• 标记-整理算法

标记-清除算法有一个最大的问题就是会产生内存空间的碎片化问题，也就是说标记-清除算法执行完成之后会产生大量的不连续内存，这样当程序需要分配一个大对象时，因为没有足够的连续内存而导致需要提前触发一次垃圾回收动作

标记-复制算法是标记-清除算法的一个升级，使用它可以有效地解决内存碎片化的问题。它是指将内存分为大小相同的两块区域，每次只使用其中的一块区域，这样在进行垃圾回收时就可以直接将存活的东西复制到新的内存上，然后再把另一块内存全部清理掉。标记-复制的算法虽然可以解决内存碎片的问题，但同时也带来了新的问题。因为需要将内存分为大小相同的两块内存，那么内存的实际可用量其实只有原来的一半，这样此算法导致了内存的可用率大幅降低了。

标记-整理算法的诞生晚于标记-清除算法和标记-复制算法，它也是由两个阶段组成的：标记阶段和整理阶段。其中标记阶段和标记-清除算法的标记阶段一样，不同的是后面的一个阶段，标记-整理算法的后一个阶段不是直接对内存进行清除，而是把所有存活的对象移动到内存的一端，然后把另一端的所有死亡对象全部清除

知识扩展

本题目考察的是关于垃圾收集的一些理论算法问题，都属于概念性的问题，只要深入理解之后还是挺容易记忆的。和此知识点相关的面试题还有这些：

• Java 中可作为 GC Roots 的对象有哪些？
• 说一下死亡对象的判断细节？

GC Roots

在 Java 中可以作为 GC Roots 的对象，主要包含以下几个：

• 所有被同步锁持有的对象，比如被 synchronize 持有的对象；
• 字符串常量池里的引用（String Table）；
• 类型为引用类型的静态变量；
• 虚拟机栈中引用对象；
• 本地方法栈中的引用对象。
• 死亡对象判断

当使用可达性分析判断一个对象不可达时，并不会直接标识这个对象为死亡状态，而是先将它标记为“待死亡”状态再进行一次校验。校验的内容就是此对象是否重写了 finalize() 方法，如果该对象重写了 finalize() 方法，那么这个对象将会被存入到 F-Queue 队列中，等待 JVM 的 Finalizer 线程去执行重写的 finalize() 方法，在这个方法中如果此对象将自己赋值给某个类变量时，则表示此对象已经被引用了。因此不能被标识为死亡状态，其他情况则会被标识为死亡状态。

卸载了两次对象，第一次执行了 finalize() 方法，成功地把自己从待死亡状态拉了回来；而第二次同样的代码却没有执行 finalize() 方法，从而被确认为了死亡状态，这是因为任何对象的 finalize() 方法都只会被系统调用一次。

虽然可以从 finalize() 方法中把自己从死亡状态“拯救”出来，但是不建议这样做，因为所有对象的 finalize() 方法只会执行一次。因此同样的代码可能产生的结果是不同的，这样就给程序的执行带来了很大的不确定性。

小结

本课时讲了对象状态判断的两种算法：引用计数算法和可达性分析算法。其中引用计数算法无法解决循环引用的问题，因此对于绝大多数的商业系统来说使用的都是可达性分析算法；同时还讲了垃圾回收的三种算法：标记-清除算法、标记-复制算法、标记-整理算法，其中，标记-清除算法会带来内存碎片的问题，而标记-复制算法会降低内存的利用率。所以，标记-整理算法算是一个不错的方案。

你用过哪些垃圾回收器？它们有什么区别？

HotSpot 中使用的垃圾收集器主要包括 7 个：Serial、ParNew、Parallel Scavenge、Serial Old、Parallel Old、CMS 和 G1（Garbage First）收集器。

Serial 收集器属于最早期的垃圾收集器，也是 JDK 1.3 版本之前唯一的垃圾收集器。它是单线程运行的垃圾收集器，其单线程是指在进行垃圾回收时所有的工作线程必须暂停，直到垃圾回收结束为止 Serial 收集器的特点是简单和高效，并且本身的运行对内存要求不高，因此它在客户端模式下使用的比较多。

ParNew 收集器实际上是 Serial 收集器的多线程并行版本

Parallel Scavenge 收集器和 ParNew 收集器类似，它也是一个并行运行的垃圾回收器；不同的是，该收集器关注的侧重点是实现一个可以控制的吞吐量。而这个吞吐量计算的也很奇怪，它的计算公式是：用户运行代码的时间 / （用户运行代码的时间 + 垃圾回收执行的时间）。比如用户运行的时间是 8 分钟，垃圾回收运行的时间是 2 分钟，那么吞吐量就是 80%。

Serial Old 收集器为 Serial 收集器的老年代版本，而 Parallel Old 收集器是 Parallel Scavenge 收集器的老年代版本。

CMS（Concurrent Mark Sweep）收集器与以吞吐量为目标的 Parallel Scavenge 收集器不同，它强调的是提供最短的停顿时间，因此可能会牺牲一定的吞吐量。它主要应用在 Java Web 项目中，它满足了系统需要短时间停顿的要求，以此来提高用户的交互体验。

Garbage First（简称 G1） 收集器是历史发展的产物，也是一款更先进的垃圾收集器，主要面向服务端应用的垃圾收集器。它将内存划分为多个 Region 分区，回收时则以分区为单位进行回收，这样它就可以用相对较少的时间优先回收包含垃圾最多区块。从 JDK 9 之后也成了官方默认的垃圾收集器，官方也推荐使用 G1 来代替选择 CMS 收集器。

知识扩展

• 讲一下分代收集理论？
• CMS 收集器的具体执行流程是什么？
• 讲一下 JDK 11 中的 ZGC 收集器？

分代收集

说到垃圾收集器不得不提的一个理论就是“分代收集”，因为目前商用虚拟机的垃圾收集器都是基于分代收集的理论进行设计的，它是指将不同“年龄”的数据分配到不同的内存区域中进行存储，所谓的“年龄”指的是经历过垃圾收集的次数。这样我们就可以把那些朝生暮死的对象集中分配到一起，把不容易消亡的对象分配到一起，对于不容易死亡的对象我们就可以设置较短的垃圾收集频率，这样就能消耗更少的资源来实现更理想的功能了。

通常情况下分代收集算法会分为两个区域：新生代（Young Generation）和老年代（OldGeneration），其中新生代用于存储刚刚创建的对象，这个区域内的对象存活率不高，而对于经过了一定次数的 GC 之后还存活下来的对象，就可以成功晋级到老生代了。

对于上面介绍的 7 个垃圾收集器来说，新生代垃圾收集器有：Serial、ParNew、Parallel Scavenge，老生代的垃圾收集器有：Serial Old、Parallel Old、CMS，而 G1 属于混合型的垃圾收集器，如下图所示：

CMS 收集器的具体执行流程

CMS 收集器是基于标记-清除算法实现的，我们之前有讲过关于标记-清除的算法，这里简单地回顾一下。标记-清除的算法是由标记阶段和清除阶段构成的，标记阶段会给所有的存活对象做上标记；而清除阶段会把被标记为死亡的对象进行回收，而死亡对象的判断是通过引用计数法或者是目前主流的可达性分析算法实现的。但是 CMS 的实现稍微复杂一些，它的整个过程可以分为四个阶段：

• 初始标记（CMS initial mark）
• 并发标记（CMS concurrent mark）
• 重新标记（CMS remark）
• 并发清除（CMS concurrent sweep）

首先，初始标记阶段的执行时间很短，它只是标记一下 GC Roots 的关联对象；并发阶段是从 GC Roots 关联的对象进行遍历判断并标识死亡对象，这个过程比较慢，但不需要停止用户线程，用户的线程可以和垃圾收集线程并发执行；而重新标记阶段则是为了判断并标记，刚刚并发阶段用户继续运行的那一部分对象，所以此阶段的执行时间也比较短；最后是并发清除阶段，也就是清除上面标记的死亡对象，由于 CMS 使用的是标记-清除算法，而非标记-整理算法，因此无须移动存活的对象，这个阶段垃圾收集线程也可以和用户线程并发执行。

CMS 的整个执行过程中只有执行时间很短的初始标记和重新标记需要 Stop The World（全局停顿）的，执行过程如下图所示：

因为 CMS 是一款基于标记清除算法实现的垃圾收集器，因此会在收集时产生大量的空间碎片，为了解决这个问题，CMS 收集器提供了一个 -XX:+UseCMS-CompactAtFullCollection 的参数（默认是开启的，此参数从 JDK9 开始废弃），用于在 CMS 收集器进行 Full GC 时开启内存碎片的合并和整理。

但又因为碎片整理的过程必须移动存活的对象，所以它和用户线程是无法并发执行的，为了解决这个问题 CMS 收集器又提供了另外一个参数 -XX:CMSFullGCsBefore-Compaction，用于规定多少次（根据此参数的值决定）之后再进行一次碎片整理。

ZGC

ZGC 收集器是 JDK 11 中新增的垃圾收集器，它是由 Oracle 官方开发的，并且支持 TB 级别的堆内存管理，而且 ZGC 收集器也非常高效，可以做到 10ms 以内完成垃圾收集。

在 ZGC 收集器中没有新生代和老生代的概念，它只有一代。ZGC 收集器采用的着色指针技术，利用指针中多余的信息位来实现着色标记，并且 ZGC 使用了读屏障来解决 GC 线程和应用线程可能存在的并发（修改对象状态的）问题，从而避免了Stop The World（全局停顿），因此使得 GC 的性能大幅提升。

ZGC 的执行流程和 CMS 比较相似，首先是进行 GC Roots 标记，然后再通过指针进行并发着色标记，之后便是对标记为死亡的对象进行回收（被标记为橘色的对象），最后是重定位，将 GC 之后存活的对象进行移动，以解决内存碎片的问题。

小结

本课时我们介绍了 JDK 11 之前的 7 种垃圾收集器：Serial、Serial Old、ParNew、Parallel Scavenge、Parallel Old、CMS、G1，其中 CMS 收集器是 JDK 8 之前的主流收集器，而 JDK 9 之后的默认收集器为 G1，并且在文章的最后，介绍了性能更加强悍、综合表现更好的 ZGC 收集器

生产环境如何排除和优化 JVM？

如果是在生产环境中直接排查 JVM 的话，最简单的做法就是使用 JDK 自带的 6 个非常实用的命令行工具来排查。它们分别是：jps、jstat、jinfo、jmap、jhat 和 jstack，它们都位于 JDK 的 bin 目录下，可以使用命令行工具直接运行

和此知识点相关的面试题还有以下这些：

• 除了比较实用的命令行工具之外，有没有方便一点的排查工具？
• JVM 常见的调优手段有哪些？

可视化排查工具

JVM 除了上面的 6 个基础命令行工具之外，还有两个重要的视图调试工具，即 JConsole 和 JVisualVM，它们相比于命令行工具使用更方便、操作更简单、结果展现也更直观。 JConsole 和 JVisualVM 都位于 JDK 的 bin 目录下，JConsole（Java Monitoring and Management Console）是最早期的视图调试工具

JVM 调优

JVM 调优主要是根据实际的硬件配置信息重新设置 JVM 参数来进行调优的，例如，硬件的内存配置很高，但 JVM 因为是默认参数，所以最大内存和初始化堆内存很小，这样就不能更好地利用本地的硬件优势了。因此，需要调整这些参数，让 JVM 在固定的配置下发挥最大的价值。

JVM 常见调优参数包含以下这些：

• -Xmx 设置最大堆内存大小；
• -Xms 设置初始堆内存大小；
• -XX:MaxNewSize 设置新生代的最大内存；
• -XX:MaxTenuringThreshold 设置新生代对象经过一定的次数晋升到老生代；
• -XX:PretrnureSizeThreshold 设置大对象的值，超过这个值的对象会直接进入老生代；
• -XX:NewRatio 设置分代垃圾回收器新生代和老生代内存占比；
• -XX:SurvivorRatio 设置新生代 Eden、Form Survivor、To Survivor 占比。

我们要根据自己的业务场景和硬件配置来设置这些值。例如，当我们的业务场景会有很多大的临时对象产生时，因为这些大对象只有很短的生命周期，因此需要把“-XX:MaxNewSize”的值设置的尽量大一些，否则就会造成大量短生命周期的大对象进入老生代，从而很快消耗掉了老生代的内存，这样就会频繁地触发 full gc，从而影响了业务的正常运行。

young gc，old gc,full gc 都会触发 stop the world

单例的实现方式有几种？它们有什么优缺点？

单例的实现分为饿汉模式和懒汉模式。

顾名思义，饿汉模式就好比他是一个饿汉，而且有一定的危机意识，他会提前把食物囤积好，以备饿了之后直接能吃到食物。对应到程序中指的是，在类加载时就会进行单例的初始化，以后访问时直接使用单例对象即可。

它的优点是线程安全，因为单例对象在类加载的时候就已经被初始化了，当调用单例对象时只是把早已经创建好的对象赋值给变量；它的缺点是可能会造成资源浪费，如果类加载了单例对象（对象被创建了），但是一直没有使用，这样就造成了资源的浪费。

public class Singleton {
    // 声明私有对象
    private static Singleton instance = new Singleton();  
    
    private Singleton() {}
    
    // 获取实例（单例对象）
    public static Singleton getInstance() {
        return instance;
    } 
}

懒汉模式的实现代码如下：

它的优点是不会造成资源的浪费，因为在调用的时候才会创建被实例化对象；它的缺点在多线程环境下是非线程是安全的，比如多个线程同时执行到 if 判断处，此时判断结果都是未被初始化，那么这些线程就会同时创建 n 个实例，这样就会导致意外的情况发生。

public class Singleton {
    // 声明私有对象
    private static Singleton instance;
    
    private Singleton() {}
    
    // 获取实例（单例对象）
    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

知识扩展

和此知识点相关的面试题还有以下这些：

• 什么是双重检测锁？它是线程安全的吗？
• 单例的还有其他实现方式吗？

双重检测锁

为了保证懒汉模式的线程安全我们最简单的做法就是给获取实例的方法上加上 synchronized（同步锁）修饰，如下代码所示：

public class Singleton {
    // 声明私有对象
    private static Singleton instance;
    
    private Singleton() {}
    
    // 获取实例（单例对象）
    public synchronized static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

这样虽然能让懒汉模式变成线程安全的，但由于整个方法都被 synchronized 所包围，因此增加了同步开销，降低了程序的执行效率。

于是为了改进程序的执行效率，我们将 synchronized 放入到方法中，以此来减少被同步锁所修饰的代码范围，实现代码如下：

public class Singleton {
    // 声明私有对象
    private static Singleton instance;
    
    private Singleton() {}
    
    // 获取实例（单例对象）
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                instance = new Singleton();
            }
        }
        return instance;
    }
}

细心的你可能会发现以上的代码也存在着非线程安全的问题。例如，当两个线程同时执行到「if (instance == null) { 」判断时，判断的结果都为 true，于是他们就排队都创建了新的对象，这显然不符合我们的预期。于是就诞生了大名鼎鼎的双重检测锁（Double Checked Lock，DCL），实现代码如下：

public class Singleton {
    // 声明私有对象
    private static Singleton instance;
    
     private Singleton() {}
     
    // 获取实例（单例对象）
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

上述代码看似完美，其实隐藏着一个不容易被人发现的小问题，该问题就出在 new 对象这行代码上，也就是 instance = new Singleton() 这行代码。这行代码看似是一个原子操作，然而并不是，这行代码最终会被编译成多条汇编指令，它大致的执行流程为以下三个步骤：

• 给对象实例分配内存空间；
• 调用对象的构造方法、初始化成员字段；
• 将 instance 对象指向分配的内存空间。

但由于 CPU 的优化会对执行指令进行重排序，也就说上面的执行流程的执行顺序有可能是 1-2-3，也有可能是 1-3-2。假如执行的顺序是 1-3-2，那么当 A 线程执行到步骤 3 时，切换至 B 线程了，而此时 B 线程判断 instance 对象已经指向了对应的内存空间，并非为 null 时就会直接进行返回，而此时因为没有执行步骤 2，因此得到的是一个未初始化完成的对象，这样就导致了问题的诞生。

时间点	线程	执行操作
t1	A	instance = new Singleton() 的 1-3 步骤，待执行步骤2
t2	B	if (instance == null) { 判断结果为 false
t3	B	返回半初始的 instance 对象

为了解决此问题，我们可以使用关键字 volatile 来修饰 instance 对象，这样就可以防止 CPU 指令重排，从而完美地运行懒汉模式，实现代码如下：

静态成员变量，静态方法 static

volatile synchronized

public class Singleton {
    // 声明私有对象
    private volatile static Singleton instance;
    
    private Singleton() {}
    
    // 获取实例（单例对象）
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

单例其他实现方式

除了以上的 6 种方式可以实现单例模式外，还可以使用静态内部类和枚举类来实现单例。静态内部类的实现代码如下：

private static final Singleton

public class Singleton {
    private Singleton() {}
    
    // 静态内部类
    private static class SingletonInstance {
        private static final Singleton instance = new Singleton();
    }
    
    // 获取实例（单例对象）
    public static Singleton getInstance() {
        return SingletonInstance.instance;
    }
}

从上述代码可以看出，静态内部类和饿汉方式有异曲同工之妙，它们都采用了类装载的机制来保证，当初始化实例时只有一个线程执行，从而保证了多线程下的安全操作。JVM 会在类初始化阶段（也就是类装载阶段）创建一个锁，该锁可以保证多个线程同步执行类初始化的工作，因此在多线程环境下，类加载机制依然是线程安全的。

但静态内部类和饿汉方式也有着细微的差别，饿汉方式是在程序启动时就会进行加载，因此可能造成资源的浪费；而静态内部类只有在调用 getInstance() 方法时，才会装载内部类从而完成实例的初始化工作，因此不会造成资源浪费的问题。由此可知，此方式也是较为推荐的单例实现方式。

单例的另一种实现方式为枚举，它也是《Effective Java》作者极力推荐地单例实现方式，因为枚举的实现方式不仅是线程安全的，而且只会装载一次，无论是序列化、反序列化、反射还是克隆都不会新创建对象。它的实现代码如下：

public class Singleton {

    // 枚举类型是线程安全的，并且只会装载一次
    private enum SingletonEnum {
        INSTANCE;
        
        // 声明单例对象
        private final Singleton instance;
        
        // 实例化
        SingletonEnum() {
            instance = new Singleton();
        }
        
        private Singleton getInstance() {
            return instance;
        }
    }
    
    // 获取实例（单例对象）
    public static Singleton getInstance() {
        return SingletonEnum.INSTANCE.getInstance();
    }
    
    private Singleton() {}
}

class SingletonTest {
    public static void main(String[] args) {
        Singleton singleton = Singleton.getInstance();
    }
}

小结

本课时我们讲了 8 种实现单例的方式，包括线程安全但可能会造成系统资源浪费的饿汉模式，以及懒汉模式和懒汉模式变种的 5 种实现方式。其中包含了两种双重检测锁的懒汉变种模式，还有最后两种线程安全且可以实现延迟加载的静态内部类的实现方式和枚举类的实现方式，其中比较推荐使用的是后两种单例模式的实现方式。

你知道哪些设计模式？分别对应的应用场景有哪些？

设计模式从大的维度来说，可以分为三大类：创建型模式、结构型模式及行为型模式，这三大类下又有很多小分类。

创建型模式是指提供了一种对象创建的功能，并把对象创建的过程进行封装隐藏，让使用者只关注具体的使用而并非对象的创建过程。它包含的设计模式有单例模式、工厂模式、抽象工厂模式、建造者模式及原型模式。

结构型模式关注的是对象的结构，它是使用组合的方式将类结合起来，从而可以用它来实现新的功能。它包含的设计模式是代理模式、组合模式、装饰模式及外观模式。

行为型模式关注的是对象的行为，它是把对象之间的关系进行梳理划分和归类。它包含的设计模式有模板方法模式、命令模式、策略模式和责任链模式。

下面我们来看看那些比较常见的设计模式的定义和具体的应用场景。

单例模式

单例模式是指一个类在运行期间始终只有一个实例，我们把它称之为单例模式。

单例模式的典型应用场景是 Spring 中 Bean 实例，它默认就是 singleton 单例模式。

单例模式的优点很明显，可以有效地节约内存，并提高对象的访问速度，同时避免重复创建和销毁对象所带来的性能消耗，尤其是对频繁创建和销毁对象的业务场景来说优势更明显。然而单例模式一般不会实现接口，因此它的扩展性不是很好，并且单例模式违背了单一职责原则，因为单例类在一个方法中既创建了类又提供类对象的复合操作，这样就违背了单一职责原则，这也是单例模式的缺点所在。

原型模式

原型模式属于创建型模式，它是指通过“克隆”来产生一个新的对象。所以它的核心方法是 clone()，我们通过该方法就可以复制出一个新的对象。

在 Java 语言中我们只需要实现 Cloneable 接口，并重写 clone() 方法就可以实现克隆了

原型模式的典型使用场景是 Java 语言中的 Object.clone() 方法，它的优点是性能比较高，因为它是通过直接拷贝内存中的二进制流实现的复制，因此具备很好的性能。它的缺点是在对象层级嵌套比较深时，复制的代码实现难度比较大。

命令模式

命令模式属于行为模式的一种，它是指将一个请求封装成一个对象，并且提供命令的撤销和恢复功能。说得简单一点就是将发送者、接收者和调用命令封装成独立的对象，以供客户端来调用

Spring 框架中的 JdbcTemplate 使用的就是命令模式，它的优点是降低了系统的耦合度，新增的命令可以很容易地添加到系统中；其缺点是如果命令很多就会造成命令类的代码很长，增加了维护的复杂性。

知识扩展：六大设计原则

六大设计原则包括：单一职责原则、里氏替换原则、依赖倒置原则、接口隔离原则、迪米特法则、开闭原则，接下来我们一一来看看它们分别是什么。

单一职责原则

单一职责是指一个类只负责一个职责。比如现在比较流行的微服务，就是将之前很复杂耦合性很高的业务，分成多个独立的功能单一的简单接口，然后通过服务编排组装的方式实现不同的业务需求，而这种细粒度的独立接口就是符合单一职责原则的具体实践。

开闭原则

开闭原则指的是对拓展开放、对修改关闭。它是说我们在实现一个新功能时，首先应该想到的是扩展原来的功能，而不是修改之前的功能。

这个设计思想非常重要，也是一名优秀工程师所必备的设计思想。至于为什么要这样做？其实非常简单，我们团队在开发后端接口时遵循的也是这个理念。

随着软件越做越大，对应的客户端版本也越来越多，而这些客户端都是安装在用户的手机上。因此我们不能保证所有用户手中的 App（客户端）都一直是最新版本的，并且也不能每次都强制用户进行升级或者是协助用户去升级，那么我们在开发新功能时，就强制要求团队人员不允许直接修改原来的老接口，而是要在原有的接口上进行扩展升级。

因为直接修改老接口带来的隐患是老版本的 App 将不能使用，这显然不符合我们的要求。那么此时在老接口上进行扩展无疑是最好的解决方案，因为这样我们既可以满足新业务也不用担心新加的代码会影响到老版本的使用。

里氏替换原则

里氏替换原则是面向对象（OOP）编程的实现基础，它指的是所有引用了父类的地方都能被子类所替代，并且使用子类替代不会引发任何异常或者是错误的出现。

比如，如果把鸵鸟归为了“鸟”类，那么鸵鸟就是“鸟”的子类，但是鸟类会飞，而鸵鸟不会飞，那么鸵鸟就违背了里氏替换原则。

依赖倒置原则

依赖倒置原则指的是要针对接口编程，而不是面向具体的实现编程。也就说高层模块不应该依赖底层模块，因为底层模块的职责通常更单一，不足以应对高层模块的变动，因此我们在实现时，应该依赖高层模块而非底层模块。

比如我们要从 A 地点去往 B 地点，此时应该掏出手机预约一个“车”，而这个“车”就是一个顶级的接口，它的实现类可以是各种各样的车，不同厂商的车甚至是不同颜色的车，而不应该依赖于某一个具体的车。例如，我们依赖某个车牌为 XXX 的车，那么一旦这辆车发生了故障或者这辆车正拉着其他乘客，就会对我的出行带来不便。所以我们应该依赖是“车”这一个顶级接口，而不是具体的某一辆车。

接口隔离原则

接口隔离原则是指使用多个专门的接口比使用单一的总接口要好，即接口应该是相互隔离的小接口，而不是一个臃肿且庞杂的大接口。

使用接口隔离原则的好处是避免接口的污染，提高了程序的灵活性。

可以看出，接口隔离原则和单一职责原则的概念很像，单一职责原则要求接口的职责要单一，而接口隔离原则要求接口要尽量细化，二者虽然有异曲同工之妙，但可以看出单一职责原则要求的粒度更细。

迪米特法则

迪米特法则又叫最少知识原则，它是指一个类对于其他类知道的越少越好。

迪米特法则设计的初衷是降低类之间的耦合，让每个类对其他类都不了解，因此每个类都在做自己的事情，这样就能降低类之间的耦合性。

这就好比我们在一些电视中看到的有些人在遇到强盗时，会选择闭着眼睛不看强盗，因为知道的信息越少反而对自己就越安全，这就是迪米特法则的基本思想。

小结

本课时我们讲了 3 种设计模式：单例模式、原型模式和命令模式，结合 MyBatis 那一课时（第 13 课时）介绍的 7 种设计模式，足以应对日常的工作和一般性的面试了。最后我们还介绍了设计模式中的 6 大设计原则：单一职责原则、开闭原则、里氏替换原则、依赖倒置原则、接口隔离原则和迪米特法则，我们应该结合这些概念对照日常项目中的代码，看看还有哪些代码可以进行优化和改进。

红黑树和平衡二叉树有什么区别？

二叉查找树，平衡二叉树，红黑树

一棵空树或者满足以下性质的二叉树被称之为二叉查找树：

• 若任意节点的左子树不为空，则左子树上所有节点的值均小于它的根节点的值；
• 若任意节点的右子树不为空，则右子树上所有节点的值均大于或等于它的根节点的值；
• 任意节点的左、右子树分别为二叉查找树。

平衡二叉树可以有效的减少二叉树的深度，从而提高了查询的效率。

红黑树除了具备二叉查找树的基本特性之外，还具备以下特性：

• 节点是红色或黑色；
• 根节点是黑色；
• 所有叶子都是黑色的空节点（NIL 节点）；
• 每个红色节点必须有两个黑色的子节点，也就是说从每个叶子到根的所有路径上，不能有两个连续的红色节点；
• 从一个节点到该节点的子孙节点的所有路径上包含相同数目的黑色节点。

红黑树结构如下图所示：

我们本课时介绍了二叉树、二叉查找树及红黑树的概念，还有红黑树的五个特性。普通二叉查找树在特殊情况下会退化成链表的数据结构，因此操作和查询的时间复杂度变成了 O(n)，而红黑树可以实现自平衡，因此它的操作（插入、删除）和查找的时间复杂度都是 O(logn)，效率更高更稳定，红黑树保证平衡的手段有三个：变色、左旋和右旋。

你知道哪些算法？讲一下它的内部实现过程？

四种算法：冒泡排序算法、二分法、插入排序算法、选择排序算法等，并且还讲了冒泡排序算法的优化。