[TOC]

面试

JAVA SE

1、自增变量

面试

面试代码：

1
2
3
4
5
6
7
8
9

public static void main(String[] args) {
    int i = 1;
    i = i++;
    int j = i++;
    int k = i + ++i * i++;
    System.out.println("i=" + i);
    System.out.println("j=" + j);
    System.out.println("k=" + k);
}

运行结果：

1
2
3

4
1
11

解析

代码相关字节码

对应的操作数栈与局部变量表执行顺序

小结

• 赋值=，最后计算
• =右边的从左到右加载值依次压入操作数栈
• 实际先算哪个，看运算符优先级
• 自增、自减操作都是直接修改局部变量表当中变量的值，不经过操作数栈
• 最后的赋值之前，临时结果也是存储在操作数栈中

2、单例模式——Singleton

面试

编程题：写一个Singleton示例

解析

1、什么是Singleton？

• Singleton：在Java中即指单例设计模式，它是软件开发中最常用的设计模式之一。
  • 单：唯一
  • 例：实例
• 单例设计模式，即某个类在整个系统中只能有一个实例对象可被获取和使用的代码模式。
  • 例如：代表JVM运行环境的Runtime类

2、要点

1. 一是某个类只能有一个实例；
   • 构造器私有化
2. 二是它必须自行创建这个实例；
   • 含有一个该类的静态变量来保存这个唯一的实例
3. 三是它必须自行向整个系统提供这个实例;
   • 对外提供获取该实例对象的方式：
     1. 直接暴露
     2. 用静态变量的get方法获取

3、几种常见形式

• 饿汉式：直接创建对象，不存在线程安全问题
  • 直接实例化饿汉式（简洁直观）
  • 枚举式（最简洁、最安全）
  • 静态代码块饿汉式（适合复杂实例化）
• 懒汉式：延迟创建对象
  • 线程不安全（适用于单线程）
  • 线程安全（加锁，适用于多线程）
  • 双重检查（适用于多线程，效率比加锁高）
  • 静态内部类形式（适用于多线程）

4、实现

1、饿汉式——直接实例化饿汉式（简洁直观）

1
2
3
4
5
6
7
8
9
10
11
12
13

/*
 * 饿汉式：
 * 	在类初始化时直接创建实例对象，不管你是否需要这个对象都会创建
 * 
 * （1）构造器私有化
 * （2）自行创建，并且用静态变量保存
 * （3）向外提供这个实例
 * （4）强调这是一个单例，我们可以用final修改
 */
public class Singleton {
    pubilc static final Singleton INSTANCE = new Singleton();
    private Singleton() {}   
}

2、饿汉式——枚举式（最简洁、最安全）

1
2
3
4
5
6
7

/*
 * 枚举类型：表示该类型的对象是有限的几个
 * 我们可以限定为一个，就成了单例
 */
public enum Singleton {
    INSTANCE
}

3、饿汉式——静态代码块饿汉式（适合复杂实例化）（可以使用配置文件来解耦合）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

public class Singleton {
    public static final Singleton IASTANCE;
    static {
        try {
			Properties pro = new Properties();
            pro.load(Singleton.class.getClassLoader().getResourceAsStream("single.properties"));
	        INSTANCE = new Singleton(pro.getProperty("info"));            
        } catch (IOException e) {
            throw new RuntimeException(e);
        }
    }
    private Singleton(String info){
		this.info = info;
	}
	public String getInfo() {
		return info;
	}
	public void setInfo(String info) {
		this.info = info;
	}
	@Override
	public String toString() {
		return "Singleton [info=" + info + "]";
	}
}

对应的配置文件single.properties：

1

info=xxx

注：该配置文件要放在src目录下面，否则Properties加载不到

4、懒汉式——线程不安全（适用于单线程）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

/*
 * 懒汉式：
 * 	延迟创建这个实例对象
 * 
 * (1)构造器私有化
 * (2)用一个静态变量保存这个唯一的实例
 * (3)提供一个静态方法，获取这个实例对象
 */
public class Singleton {
    private static final Singleton INSTANCE;
    private Singleton() {}
    public static Singleton getInstance() {
        if (INSTANCE == null) {
	        INSTANCE = new Singleton();            
        }
		return INSTANCE;
    }
}

5、懒汉式——线程安全（加锁，适用于多线程）

1
2
3
4
5
6
7
8
9
10
11
12

public class Singleton {
    private volatile static final Singleton INSTANCE;
    private Singleton() {}
    public static Singleton getInstance() {
        Synchronized(Singleton.class) {
            if (INSTANCE == null) {
		        INSTANCE = new Singleton();            
    	    }
			return INSTANCE;
        }
    }
}

6、懒汉式——双重检查（适用于多线程，效率比加锁高）

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class Singleton {
    private volatile static final Singleton INSTANCE;
    private Singleton() {}
    public static Singleton getInstance() {
        if (INSTANCE == null) {
            Synchronized(Singleton.class) {
                if (INSTANCE == null) {
                    INSTANCE = new Singleton();            
                }              
            }
        }
        return INSTANCE;
    }
}

7、懒汉式——静态内部类形式（适用于多线程）

1
2
3
4
5
6
7
8
9
10
11
12
13
14

/*
 * 在内部类被加载和初始化时，才创建INSTANCE实例对象
 * 静态内部类不会自动随着外部类的加载和初始化而初始化，它是要单独去加载和初始化的。
 * 因为是在内部类加载和初始化时，创建的，因此是线程安全的
 */
public class Singleton {
    private Singleton() {}
    private static class Inner {
        private static final volatile Singleton INSTANCE = new Singleton();
    }
    public static Singleton getInstance() {
        return Inner.INSTANCE;
    }
}

小结

• 如果是饿汉式，枚举形式最简单
• 如果是懒汉式，静态内部类形式最简单

3、类初始化与实例初始化

面试

运行结果：

1
2

(5)(1)(10)(6)(9)(3)(2)(9)(8)(7)
(9)(3)(2)(9)(8)(7)

解析

1、类初始化过程

1. 一个类要创建实例需要先加载并初始化该类
   • main方法所在的类需要先加载和初始化
2. 一个子类要初始化需要先初始化父类
3. 一个类初始化就是执行()方法
   • ()方法由静态类变量显示赋值代码和静态代码块组成
   • 类变量显示赋值代码和静态代码块代码从上到下顺序执行
   • ()方法只执行一次

2、实例初始化过程

实例初始化就是执行()方法

• ()方法可能重载有多个，有几个构造器就有几个方法
• ()方法由非静态实例变量显示赋值代码和非静态代码块、对应构造器代码组成
• 非静态实例变量显示赋值代码和非静态代码块代码从上到下顺序执行，而对应构造器的代码最后执行
• 每次创建实例对象，调用对应构造器，执行的就是对应的方法
• 方法的首行是super()或super(实参列表)，即对应父类的方法

3、方法的重写

• 哪些方法不可以被重写
  • final方法
  • 静态方法
  • private等子类中不可见方法
• 对象的多态性
  • 子类如果重写了父类的方法，通过子类对象调用的一定是子类重写过的代码
  • 非静态方法默认的调用对象是this
  • this对象在构造器或者说**方法中就是正在创建的对象**
• 方法的重写与重载的区别
  • 方法重写（Override）：
    • 是子类对父类的允许访问的方法的实现过程进行重新编写，返回值和形参都不能改变。即外壳不变，核心重写！
    • 好处在于子类可以根据需要，定义特定于自己的行为。 也就是说子类能够根据需要实现父类的方法。
    • 方法的重写规则：
      • 参数列表与被重写方法的参数列表必须完全相同。
      • 返回类型与被重写方法的返回类型可以不相同，但是必须是父类返回值的派生类（java5 及更早版本返回类型要一样，java7 及更高版本可以不同）。
      • 访问权限不能比父类中被重写的方法的访问权限更低。例如：如果父类的一个方法被声明为 public，那么在子类中重写该方法就不能声明为 protected。
      • 父类的成员方法只能被它的子类重写。
      • 声明为 final 的方法不能被重写。
      • 声明为 static 的方法不能被重写，但是能够被再次声明。
      • 子类和父类在同一个包中，那么子类可以重写父类所有方法，除了声明为 private 和 final 的方法。
      • 子类和父类不在同一个包中，那么子类只能够重写父类的声明为 public 和 protected 的非 final 方法。
      • 重写的方法能够抛出任何非强制异常，无论被重写的方法是否抛出异常。但是，重写的方法不能抛出新的强制性异常，或者比被重写方法声明的更广泛的强制性异常，反之则可以。
      • 构造方法不能被重写。
      • 如果不能继承一个类，则不能重写该类的方法。
  • 方法重载(Overload)：
    • 重载(overloading) 是在一个类里面，方法名字相同，而参数不同。返回类型可以相同也可以不同。
    • 每个重载的方法（或者构造函数）都必须有一个独一无二的参数类型列表。
    • 最常用的地方就是构造器的重载。
    • 方法重载规则：
      • 被重载的方法必须改变参数列表(参数个数或类型不一样)；
      • 被重载的方法可以改变返回类型；
      • 被重载的方法可以改变访问修饰符；
      • 被重载的方法可以声明新的或更广的检查异常；
      • 方法能够在同一个类中或者在一个子类中被重载。
      • 无法以返回值类型作为重载函数的区分标准。

4、方法参数传递机制

面试

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

import java.util.Arrays;

public class Exam4 {
	public static void main(String[] args) {
		int i = 1;
		String str = "hello";
		Integer num = 200;
		int[] arr = {1,2,3,4,5};
		MyData my = new MyData();
		
		change(i,str,num,arr,my);
		
		System.out.println("i = " + i);
		System.out.println("str = " + str);
		System.out.println("num = " + num);
		System.out.println("arr = " + Arrays.toString(arr));
		System.out.println("my.a = " + my.a);
	}
	public static void change(int j, String s, Integer n, int[] a,MyData m){
		j += 1;
		s += "world";
		n += 1;
		a[0] += 1;
		m.a += 1;
	}
}
class MyData{
	int a = 10;
}

运行结果

1
2
3
4
5

i = 1
str = hello
num = 200
arr = [2,3,4,5,6]
my.a = 11

解析

以上代码的方法参数传递机制

小结

方法的参数传递机制：

• 形参是基本数据类型
  • 传递数据值
• 实参是引用数据类型
  • 传递地址值
• 特殊的类型：String、包装类等对象不可变性

5、递归与迭代

面试

编程题：有n步台阶，一次只能上1步或2步，共有多少种走法？

1. 递归
2. 迭代

解析

1、递归

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

import org.junit.Test;

public class TestStep{
	@Test
	public void test(){
		long start = System.currentTimeMillis();
		System.out.println(f(100));//165580141
		long end = System.currentTimeMillis();
		System.out.println(end-start);//586ms
	}
	
	//实现f(n)：求n步台阶，一共有几种走法
	public int f(int n){
		if(n<1){
			throw new IllegalArgumentException(n + "不能小于1");
		}
		if(n==1 || n==2){
			return n;
		}
		return f(n-2) + f(n-1);
	}
}

2、循环迭代

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

import org.junit.Test;

public class TestStep2 {
	@Test
	public void test(){
		long start = System.currentTimeMillis();
		System.out.println(loop(100));//165580141
		long end = System.currentTimeMillis();
		System.out.println(end-start);//<1ms
	}
	
	public int loop(int n){
		if(n<1){
			throw new IllegalArgumentException(n + "不能小于1");
		}
		if(n==1 || n==2){
			return n;
		}
		
		int one = 2;//初始化为走到第二级台阶的走法
		int two = 1;//初始化为走到第一级台阶的走法
		int sum = 0;
		
		for(int i=3; i<=n; i++){
			//最后跨2步 + 最后跨1步的走法
			sum = two + one;
			two = one;
			one = sum;
		}
		return sum;
	}
}

小结

• 方法调用自身称为递归，利用变量的原值推出新值称为迭代。
• 递归
  • 优点：大问题转化为小问题，可以减少代码量，同时代码精简，可读性好；
  • 缺点：递归调用浪费了空间，而且递归太深容易造成堆栈的溢出。
• 迭代
  • 优点：代码运行效率好，因为时间只因循环次数增加而增加，而且没有额外的空间开销；
  • 缺点：代码不如递归简洁，可读性好

6、成员变量与局部变量

面试

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

public class Exam5 {
	static int s;//成员变量，类变量
	int i;//成员变量，实例变量
	int j;//成员变量，实例变量
	{
		int i = 1;//非静态代码块中的局部变量 i
		i++;
		j++;
		s++;
	}
	public void test(int j){//形参，局部变量,j
		j++;
		i++;
		s++;
	}
	public static void main(String[] args) {//形参，局部变量，args
		Exam5 obj1 = new Exam5();//局部变量，obj1
		Exam5 obj2 = new Exam5();//局部变量，obj1
		obj1.test(10);
		obj1.test(20);
		obj2.test(30);
		System.out.println(obj1.i + "," + obj1.j + "," + obj1.s);
		System.out.println(obj2.i + "," + obj2.j + "," + obj2.s);
	}
}

运行结果

1
2

2,1,5
1,1,5

解析

• 就近原则
  • 如果变量同名而且前面没有加this的话，采用的就是就近原则
• 变量的分类
  • 成员变量：类变量、实例变量
  • 局部变量
• 非静态代码块的执行：每次创建实例对象都会执行
• 方法的调用规则：调用一次执行一次

小结

局部变量与成员变量的区别：

1. 声明的位置
   • 局部变量：方法体{}中，形参，代码块{}中
   • 成员变量：类中方法外
     • 类变量：有static修饰
     • 实例变量：没有static修饰
2. 修饰符
   • 局部变量：final
   • 成员变量：public、protected、private、final、static、volatile、transient
3. 值存储的位置
   • 局部变量：栈
   • 实例变量：堆
   • 类变量：方法区
4. 作用域
   • 局部变量：从声明处开始，到所属的}结束
   • 实例变量：在当前类中“this.”(有时this.可以缺省)，在其他类中“对象名.”访问
   • 类变量：在当前类中“类名.”(有时类名.可以省略)，在其他类中“类名.”或“对象名.”访问
5. 生命周期
   • 局部变量：每一个线程，每一次调用执行都是新的生命周期
   • 实例变量：随着对象的创建而初始化，随着对象的被回收而消亡，每一个对象的实例变量是独立的
   • 类变量：随着类的初始化而初始化，随着类的卸载而消亡，该类的所有对象的类变量是共享的

当局部变量与xx变量重名时，如何区分：

1. 局部变量与实例变量重名
   • 在实例变量前面加“this.”
2. 局部变量与类变量重名
   • 在类变量前面加“类名.”

7、字符串常量java内部加载

面试——《深入理解Java虚拟机第三版》2.4.3

1
2
3
4
5
6
7
8
9
10
11
12
13

public static void main(String[] args) {
    String str1 = new StringBuilder("58").append("tongcheng").toString();
    System.out.println(str1);
    System.out.println(str1.intern());
    System.out.println(str1 == str1.intern());
    
    System.out.println("------------------");
    
    String str2 = new StringBuilder("ja").append("va").toString();
    System.out.println(str2);
    System.out.println(str2.intern());
    System.out.println(str2 == str2.intern());
}

运行结果：

1
2
3
4
5
6
7

58tongcheng
58tongcheng
true
------------------
java
java
false

解析

按照代码结果，java字符串答案为false 必然是两个不同的java，那另外一个java字符串如何加载进来的?

因为有一个初始化的java字符串**(JDK加载时自带的)， 在加载sun.misc.Version这个类的时候进入常量池**。

1、OpenJDK8底层源码说明问题

1、System源码解析

System→ initializeSystemClass→Version：

2、类加载器和rt.jar

根加载器提前部署加载rt.jar

2、关于String 的 intern方法

1

public native String intern();

Returns a canonical representation for the string object.
A pool of strings, initially empty, is maintained privately by the class String.
When the intern method is invoked, if the pool already contains a string equal to this String object as determined by the equals(Object) method, then the string from the pool is returned. Otherwise, this String object is added to the pool and a reference to this String object is returned.
It follows that for any two strings s and t, s.intern() == t.intern() is true if and only if s.equals(t) is true.
All literal strings and string-valued constant expressions are interned. String literals are defined in section 3.10.5 of the The Java™ Language Specification.
Returns:
a string that has the same contents as this string, but is guaranteed to be from a pool of unique strings.

String::intern()是一个本地方法，它的作用是如果字符串常量池中已经包含一个等于此String对象的字符串，则返回代表池中这个字符串的String对象的引用；否则，会将此String对象包含的字符串添加到字符串常量池中，并且返回次String对象的引用。

方法区和运行时常量池的溢出：

由于运行时常量池是方法区的一部分，所以这两个区域的溢出测试可以放在一起进行。在JDK6或者更早之前的HotSpot虚拟机中，常量池都是分配在永久代中，我们可以通过-XX:PermSize和-XX:MaxPermSize限制永久代的大小，即可间接限制其中常量池的容量。而在HotSpot虚拟机在JDK8中完全使用元空间来代替永久代，原本存放在永久代的字符串常量池被移至java堆当中，所以通过限制方法区容量已经没有了意义。如果我们在JDK7以及以上版本，通过限制java堆空间的大小，如：-Xmx。就能看到OOM：Java heap space。

小结

如果在JDK6当中，面试的代码返回的是两个false，因为在JD6当中，intern()方法会把首次遇到的字符串实例复制到永久代的字符串常量池当中存储，返回的也是永久代里面这个字符串实例的引用，与StringBuilder创建的字符串在java堆空间当中，所以必然不可能是同一个引用，结果返回false。

而在JDK7当中，intern()方法实现就不需要拷贝字符串实例到永久代了，因为字符串常量池已经从方法区移动到java堆空间当中，因此intern()方法只需要在字符串常量池里记录一下首次出现的字符串实例即可，因此intern()返回的引用和StringBuilder创建的字符串实例的引用就是同一个，结果返回true。

由于字符串”java”在类加载的时候就已经加载进字符串常量池当中了（不是首次创建），所以之后在java堆空间创建的字符串”java”的引用与在java堆空间的字符串常量池的字符串”java”的引用不是同一个，因此返回false。

注：不只是字符串”java”，在JDK7以及之后的版本中，其他字符串如果有在java初始化类加载的时候进行过加载的话，也是已经加载进java堆的字符串常量池当中了，返回也是false。如zip等等。

JAVA EE

1、Spring Bean 的作用域之间有什么区别

解析：

在Spring中，可以在元素的scope属性你设置bean的作用域，以决定这个bean是单实例的还是多实例的。

默认情况下，Spring只为每个在IOC容器里声明的bean创建唯一一个实例，整个IOC容器范围内都能共享该实例：所有后续的getBean()调用和bean引用都将返回这个唯一的bean实例。该作用域被称为singleton，它是所有bean的默认作用域。

Spring Bean一共有四个作用域，可以通过scope属性来指定bean的作用域：

2、Spring支持的常用数据库事务传播属性和事务隔离级别

解析：

1、什么是事务的传播？

当事务方法被另一个事务方法调用时，必须指定事务应该如何传播。例如：方法可能继续在现有事务中运行，也可能开启一个新事务，并在自己的事务中运行。

2、事务的传播行为种类

事务的传播行为可以由传播属性指定。Spring定义了7种类传播行为

事务传播属性可以在 @Transactional 注解的 propagation 属性中定义。

现在重点来讲一下 REQUIRED 与 REQUIRES_NEW

3、例子

现有100现金，去购买价值60元、库存100件的《Spring》与价值50元、库存100件的《SpringMVC》

有两种结果：

1. 两本书都买不成，现金依旧有100元，两本书的库存依旧是100件
2. 买成了第一本书《Spring》，买不了第二本书《SpringMVC》，现金为40元，《Spring》的库存只剩下99件，而《SpringMVC》的库存依旧有100件

导致以上两种结果的原因是事务的传播行为的不同。

1、REQUIRED

Propagation.REQUIRED：默认值，如果有事务在运行，当前的方法就在这个事务内运行，否则，就启动一个新的事务，并在自己的事务内运行。

结果：两本书都买不成，现金依旧有100元，两本书的库存依旧是100件

解析：

REQUIRED 传播行为：当bookService 的 purchase()方法被另外一个事务方法checkout()调用时，它默认会在现有的事务内运行。这个默认的传播行为就是REQUIRED 。因此在checkout()方法的开始和终止边界类内只有一个事务。这个事务只在checkout()方法结束的时候被提交，结果用户一本书都买不了

2、REQUIRES_NEW

Propagation.REQUIRES_NEW：表示该方法必须启动一个新事务，并在自己的事务内运行。如果有事务在运行，就应该先挂起它。

结果：买成了第一本书《Spring》，买不了第二本书《SpringMVC》，现金为40元，《Spring》的库存只剩下99件，而《SpringMVC》的库存依旧有100件

解析：

4、数据库的事务并发问题

假设现在有两个事务：Transactional01 和 Transactional02 并发执行。

1. 脏读
   1. Transaction01将某条记录的AGE值从20修改为30。
   2. Transaction02读取了Transaction01更新后的值：30。
   3. Transaction01回滚，AGE值恢复到了20。
   4. Transaction02读取到的30就是一个无效的值。
2. 不可重复读
   1. Transaction01读取了AGE值为20。
   2. Transaction02将AGE值修改为30。
   3. Transaction01再次读取AGE值为30，和第一次读取不一致。
3. 幻读
   1. Transaction01读取了STUDENT表中的一部分数据。
   2. Transaction02向STUDENT表中插入了新的行。
   3. Transaction01读取了STUDENT表时，多出了一些行。

5、隔离级别

数据库系统必须具有隔离并发运行各个事务的能力，使它们不会相互影响，避免各种并发问题。一个事务与其他事务隔离的程度称为隔离级别。SQL标准中规定了多种事务隔离级别，不同隔离级别对应不同的干扰程度，隔离级别越高，数据一致性就越好，但并发性越弱。

1. 读未提交：READ UNCOMMITTED
   • 允许TranSaction01读取Transaction02未提交的修改。
2. 读已提交：READ COMMITTED
   • 要求Transaction01只能读取Transaction02已提交的修改。
3. 可重复读：REPEATABLE READ
   • 确保Transaction01可以多次从一个字段中读取到相同的值，即Transaction01执行期间禁止其它事务对这个字段进行更新。
4. 串行化：SERIALIZABLE
   • 确保Transaction01可以多次从一个表中读取到相同的行，在Transaction01执行期间，禁止其它事务对这个表进行添加、更新、删除操作。可以避免任何并发问题，但性能十分低下。

隔离级别属性可以在 @Transactional 注解的 isolation 属性中定义。如：

• Isolation.READ_UNCOMMITTED
• Isolation.READ_COMMITTED

6、各个隔离级别解决并发问题的能力

表格当中的“有”“无”代表的是当前的左边隔离级别有没有上面的并发问题

7、各种数据库产品对事务隔离级别的支持程度

3、SpringMVC如何解决POST请求中文乱码问题

解析：

需要配置一个字符编码过滤器CharacterEncodingFilter来解决POST请求中文乱码问题

字符编码过滤器CharacterEncodingFilter源码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

public class CharacterEncodingFilter extends OncePerRequestFilter {
    // 设置的字符集
    private String encoding;
    // 响应的时候是否需要使用上面设置的字符集
    private boolean forceEncoding = false;
    
    // ...
    
    // 核心方法
    protected void dpFilterInternal(
        HttpServletRequest request, HttpServletResponse response, FilterChain filterChain)
        throws ServletException, IOException {

        /**
        * 如果没有设置 encoding的话，默认就为null。如果设置了encoding的话就为true
        * forceEncoding如果设置为true的话，或者request.getCharacterEncoding()为null的话
        * 就能进入if语句块
        */
        if (this.encoding != null && (this.forceEncoding || request.getCharacterEncoding()==null)) {
            // 将设置的encoding字符集放进去
            request.setCharacterEncoding(this.encoding);
			if (this.forceEncoding) {
                // 响应的时候使用上面设置的字符集
				response.setCharacterEncoding(this.encoding) ;
            }
        }
		filterChain.doFliter(request, response);
}

解决问题：

1. 在web.xml中配置CharacterEncodingFilter过滤器

   1 2 3 4 5 6 7 8 9 10 11 12 13

   <!--解决POST请求的请求乱码问题--> <filter> <filter-name>CharacterEncodingFilter</filter-name> <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class> <init-param> <param-name>encoding</param-name> <param-value>UTF-8</param-value> </init-param> <init-param> <param-name>forceEncoding</param-name> <param-value>true</param-value> </init-param> </filter>

   注：该过滤器要配置在web.xml的最上面

2. 在CharacterEncodingFilter过滤器的下面在配置一些过滤器的相关映射

   1 2 3 4 5

   <filter-mapping> <!-- 注意这里的名字需要和上面配置的filter-name一致--> <filter-name>CharacterEncodingFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>

注意：

• 以上方法只能解决的是POST请求的中文乱码问题
• 如果把请求修改为GET，依旧会出现中文乱码问题

那么，怎么解决GET请求的中文乱码问题?

最简单的一种方式：修改tomcat服务器的server.xml文件

1. 先找到tomcat服务器的server.xml文件

2. 找到第一个Connector标签

3. 在后面添加URIEncoding="UTF-8"

   

4、简单谈一下SpringMVC的工作流程

解析：

SpringMVC的工作流程图：

代码执行流程：

5、MyBatis中当实体类中的属性名和表中的字段名不一样的解决方法

解析：

1. 在对应的mapper文件写sql语句时起别名

   

2. 在Mybatis的全局配置文件mybatis-config.xml中开启驼峰命名规则

   1 2 3 4 5 6

   <settings> <!-- 开启驼峰命名规则，可以将数据库中的下划线映射为驼峰命名 例如: last_name 可以映射为lastName --> <setting name= "mapUnderscoreToCameLCase" value="true"/> </settings>

3. 在Mapper映射文件中使用resultMap来自定义映射规则

   

Spring：主要考察IOC + AOP +TX（事务相关）

1、Aop的常用注解

2、有关于Spring aop的面试题

1、Srping aop全部通知顺序问题

你肯定知道spring，那说说aop的全部通知顺序？springboot或springboot2对aop的执行顺序影响?

• SpringBoot1底层使用的是Spring4
• SpringBoot2底层使用的是Spring5

其实问的就是Spring4与Spring5的aop的全部通知顺序的区别？

1、Spring4的aop的全部通知顺序

版本：Spring4.3.13 +springboot1.5.9

spring4默认用的是JDK的动态代理

正常执行：@Before （前置通知）@After（后置通知）@AfterReturning (正常返回)

异常执行：@Before （前置通知）@After（后置通知）@AfterThrowing (方法异常)

Spring4.3.13 +springboot1.5.9：正常aop顺序：

Spring4.3.13 +springboot1.5.9：异常aop顺序：

总结：

2、Spring5的aop的全部通知顺序

版本：Spring5.2.8 +springboot2.3.3

spring5默认动态代理用的是cglib，不再是JDK的动态代理， 因为JDK必须要实现接口，但有些类它并没有实现接口，所以更加通用的话就是cglib

正常执行：@Before（前置通知）@AfterReturning（正常返回）@After（后置通知)）

异常执行：@Before（前置通知）@AfterThrowing（方法异常）@After（后置通知)）

Spring5+springboot2.3.3：aop正常顺序：

Spring5+springboot2.3.3：aop异常顺序：

总结：

3、Srping aop全部通知顺序总结

2、Spring 的循环依赖问题

1、相关面试题

1. 你解释下spring中的三级缓存？
2. 三级缓存分别是什么？三个Map有什么异同？
3. 什么是循环依赖？请你谈谈？看过 Spring源码吗？一般我们说的 Spring容器是什么？
4. 如何检测是否存在循环依赖？实际开发中见过循环依赖的异常吗？
5. 多例的情况下，循环依赖问题为什么无法解决？

2、什么是循环依赖？

多个 bean 之间相互依赖，形成了一个闭环

比如：A 依赖于 B、B 依赖于 C、C 依赖于 A。

1
2
3
4
5
6
7
8
9
10
11
12
13

public class CircularDependency {
    class A {
        B b;
    }
    
    class B {
        C c;
    }
    
    class C {
        A a;
    }
}

通常来说，如果问 Spring 容器内部如何解决循环依赖， 一定是指默认的单例 Bean 中，属性互相引用的场景。也就是说，Spring 的循环依赖，是 Spring 容器注入时候出现的问题

3、两种注入方式对循环依赖的影响

官网对循环依赖的说明

两种注入方式对循环依赖的影响：

• 构造器注入：容易造成无法解决的循环依赖，不推荐使用（If you use predominantly constructor injection, it is possible to create an unresolvable circular dependency scenario.）
• Setter 注入：推荐使用 setter 方式注入单例 bean

spring容器：

• 默认的单例(singleton)的场景是支持循环依赖的，不报错。
• 原型(Prototype)的场景是不支持循环依赖的，会报错。默认单例，修改为原型scope=”prototype” 就导致了循环依赖错误

结论：我们 AB 循环依赖问题只要注入方式是 setter 且bean 的 scope 属性是 singleton，就不会有循环依赖问题

4、那么Spring底层是怎么解决循环依赖的呢

Spring 内部通过 3 级缓存来解决循环依赖

所谓的三级缓存其实就是 Spring 容器内部用来解决循环依赖问题的三个 Map，这三个 Map 在 DefaultSingletonBeanRegistry 类中

只有单例的bean会通过三级缓存提前暴露来解决循环依赖问题，而非单例的bean，每次从容器中获取都是一个新的对象，都会重新创建，所以非单例的bean是没有缓存的，不会将其放到三级缓存中，因此也解决不了循环依赖问题。

那么三级缓存的这三个Map分别是什么？有什么异同？

1. 第一级缓存〈也叫单例池）Map<String, Object> singletonObjects：常说的 Spring 容器就是指它，我们获取单例 bean 就是在这里面获取的，存放已经经历了完整生命周期的Bean对象
2. 第二级缓存：Map<String, Object> earlySingletonObjects，存放早期暴露出来的Bean对象，Bean的生命周期未结束（属性还未填充完整，可以认为是半成品的 bean）
3. 第三级缓存： Map<String, ObjectFactory<?>> singletonFactories，存放可以生成Bean的工厂，用于生产（创建）bean对象

5、源码 Deug 前置知识

1、实例化 & 初始化

实例化和初始化的区别：

• 实例化：堆内存中申请一块内存空间

  

• 初始化：完成属性的填充

  

2、3个Map & 5个方法

三级缓存 + 五大方法：

三级缓存《==》3个Map：

1. 第一级缓存singletonObjects：存放的是已经初始化好了的Bean，bean名称与bean实例相对应，即所谓的单例池。表示已经经历了完整生命周期的Bean对象
2. 第二级缓存earlySingletonObjects：存放的是实例化了，但是未初始化的Bean，bean名称与bean实例相对应。表示Bean的生命周期还没走完（Bean的属性还未填充）就把这个Bean存入该缓存中。也就是实例化但未初始化的bean放入该缓存里
3. 第三级缓存singletonFactories：表示存放生成bean的工厂，存放的是FactoryBean，bean名称与bean工厂对应。假如A类实现了FactoryBean，那么依赖注入的时候不是A类，而是A类产生的Bean

五大方法：

1. getSingleton()：从容器里面获得单例的bean，没有的话则会创建 bean
2. doCreateBean()：执行创建 bean 的操作（在 Spring 中以 do 开头的方法都是干实事的方法）
3. populateBean()：创建完 bean 之后，对 bean 的属性进行填充
4. initializeBean()：初始化bean对象，也是在这里完成AOP代理
5. addSingleton()：bean 初始化完成之后，添加到单例容器池中，下次执行 getSingleton() 方法时就能获取到

注：关于第三级缓存 Map<String, ObjectFactory<?>> singletonFactories的说明：singletonFactories 的 value 为 ObjectFactory 接口实现类的实例。ObjectFactory 为函数式接口，在该接口中定义了一个 getObject() 方法用于获取 bean，这也正是工厂思想的体现（工厂设计模式）

3、对象在三级缓存中的迁移

A/B 两对象在三级缓存中的迁移说明：

1. A创建过程中需要B，于是A将自己放到三级缓存里面，去实例化B
2. B实例化的时候发现需要A，于是B先查一级缓存，没有，再查二级缓存，还是没有，再查三级缓存，找到了A，然后把三级缓存里面的这个A放到二级缓存里面，并删除三级缓存里面的A
3. B顺利初始化完毕，将自己放到一级缓存里面（此时B里面的A依然是创建中状态），然后回来接着创建A，此时B已经创建结束，直接从一级缓存里面拿到B，然后完成创建，并将A自己放到一级缓存里面。

6、详细 Debug 流程

技巧：如何阅读框架源码？答：打断点 + 看日志

1、beanA的实例化

在 ApplicationContext context = new ClassPathXmlApplicationContext("applicationContext.xml"); 代码处打上断点，逐步执行（Step Over），发现执行 new ClassPathXmlApplicationContext("applicationContext.xml") 操作时，beanA 和 beanB 都已经被创建好了，因此我们需要进入 new ClassPathXmlApplicationContext("applicationContext.xml") 中

进入 new ClassPathXmlApplicationContext("applicationContext.xml") 中：

点击 Step Into，首先进入了静态代码块中，不管我们的事，使用 Step Out 退出此方法

再次 Step Into，进入 ClassPathXmlApplicationContext 类的构造函数，该构造函数使用 this 调用了另一个重载构造函数

继续 Step Into，进入重载构造函数后单步 Step Over，发现执行完 refresh() 方法后输出如下日志，于是我们将断点打在 refresh() 那一行

进入 refresh() 方法：

Step Into 进入 refresh() 方法，发现执行完 finishBeanFactoryInitialization(beanFactory) 方法后输出日志，于是我们将断点打在 finishBeanFactoryInitialization(beanFactory) 那一行

从注释也可以看出本方法完成了非懒加载单例 bean的初始化（Instantiate all remaining (non-lazy-init) singletons.）

进入 finishBeanFactoryInitialization(beanFactory) 方法：

Step Into 进入 finishBeanFactoryInitialization(beanFactory) 方法，发现执行完 beanFactory.preInstantiateSingletons() 方法后输出日志，于是我们将断点打在 beanFactory.preInstantiateSingletons() 那一行

从注释也可以看出本方法完成了非懒加载单例 bean的初始化（Instantiate all remaining (non-lazy-init) singletons.）

进入 beanFactory.preInstantiateSingletons() 方法：

Step Into 进入 beanFactory.preInstantiateSingletons() 方法，发现执行完 getBean(beanName) 方法后输出日志，于是我们将断点打在 getBean(beanName) 那一行

进入 getBean(beanName) 方法：

getBean(beanName) 调用了 doGetBean(name, null, null, false) 方法，即：在 Spring 里面，以do 开头的方法都是干实事的方法

进入 doGetBean(name, null, null, false) 方法：

我们可以给 bean 配置别名，这里的 transformedBeanName(name) 方法就是将用户别名转换为 bean 的真实名称

进入 getSingleton(beanName) 方法：

调用了其重载的方法，allowEarlyReference == true 表示可以从三级缓存 earlySingletonObjects 中获取 bean，allowEarlyReference == false 表示不可以从三级缓存 earlySingletonObjects 中获取 bean

getSingleton(beanName, true) 方法尝试从一级缓存 singletonObjects 中获取 beanA，beanA 现在还没有开始造，（isSingletonCurrentlyInCreation(beanName) 返回 false），获取不到返回 null

回到 doGetBean(name, null, null, false) 方法中：

getSingleton(beanName)方法返回null

我们所说的 bean 对于 Spring 来说就是一个个的 RootBeanDefinition 实例

这个 dependsOn 变量对应于 bean 的 depends-on="" 属性，我们没有配置过，因此为 null

转了一圈发现并没有 beanA，终于要开始准备创建 beanA 啦

进入 getSingleton(beanName, () -> {...} 方法：

首先尝试从一级缓存 singletonObjects 获取 beanA，那肯定是获取不到，因此 singletonObject == null，那么就需要创建 beanA，此时日志会输出：【Creating shared instance of singleton bean ‘a’】

当执行完 singletonObject = singletonFactory.getObject(); 时，会输出【A created success】，这说明执行 singletonFactory.getObject() 方法时将会实例化 beanA，并且根据代码变量名可得知单例工厂创建的，这个单例工厂就是我们传入的 Lambda 表达式

进入 createBean(beanName, mbd, args) 方法:

mbdToUse 将用于创建 beanA：

来了，终于要执行 doCreateBean(beanName, mbdToUse, args) 实例化 beanA：

进入 doCreateBean(beanName, mbdToUse, args) 方法：

在 factoryBeanInstanceCache 中并不存在 beanA 对应的 Wrapper 缓存，instanceWrapper == null，因此我们要去创建 beanA 对应的 instanceWrapper，Wrapper 有包裹之意思，instanceWrapper 翻译过来为实例包裹器的意思，形象理解为：beanA 实例化需要经过 instanceWrapper 之手，beanA 实例被 instanceWrapper 包裹在其中

进入 createBeanInstance(beanName, mbd, args) 方法：

这一看就是反射的操作

这里有个 resolved 变量，写着注释：Shortcut when re-creating the same bean…，我个人理解是 resolved 标志该 bean 是否已经被实例化了，如果已经被实例化了，那么 resolved == true，这样就不用重复创建同一个 bean 了

Candidate constructors for autowiring? 难道是构造器自动注入？在 return 的时候调用 instantiateBean(beanName, mbd) 方法实例化 beanA，并将其返回

进入 instantiateBean(beanName, mbd) 方法：

getInstantiationStrategy().instantiate(mbd, beanName, this) 方法完成了 beanA 的实例化

进入 getInstantiationStrategy().instantiate(mbd, beanName, this) 方法：

首先获取已经解析好的构造器 bd.resolvedConstructorOrFactoryMethod，这是第一次创建，当然还没有啦，因此 constructorToUse == null。然后获取 A 的类型，如果发现是接口则直接抛异常。最后获取 A 的公开构造器，并将其赋值给 bd.resolvedConstructorOrFactoryMethod

获取构造器的目的当然是为了实例化 beanA

进入 BeanUtils.instantiateClass(constructorToUse) 方法：

通过构造器创建 beanA 实例，Step Over 后会输出：【A created success】，并且会回到 getInstantiationStrategy().instantiate(mbd, beanName, this) 方法中

回到 getInstantiationStrategy().instantiate(mbd, beanName, this) 方法中：

在 BeanUtils.instantiateClass(constructorToUse) 方法中创建好了 beanA 实例，不过还没有进行初始化，可以看到属性 b = null，Step Over 后会回到 instantiateBean(beanName, mbd) 方法中

回到 instantiateBean(beanName, mbd) 方法中：

得到刚才创建的 beanA 实例，但其属性并未被初始化

将实例化的 beanA 装进 BeanWrapper 中并返回 bw

回到 createBeanInstance(beanName, mbd, args) 方法中：

得到刚才创建的 beanWrapper 实例，该 beanWrapper 包裹（封装）了刚才创建的 beanA 实例

回到 doCreateBean(beanName, mbdToUse, args) 方法中：

在 doCreateBean(beanName, mbdToUse, args) 方法获得 BeanWrapper instanceWrapper，用于封装 beanA 实例

获取并记录 A 的全类名：

执行 BeanPostProcessor：

如果该 bean 是单例 bean（mbd.isSingleton()），并且允许循环依赖（this.allowCircularReferences），并且当前 bean 正在创建过程中（isSingletonCurrentlyInCreation(beanName)），那么就允许提前暴露该单例 bean（earlySingletonExposure = true），则会执行 addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean)) 方法将该 bean 放到三级缓存 singletonFactories 中

进入 addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean)) 方法：

首先去一级缓存 singletonObjects 中找一下有没有 beanA，肯定没有啦~然后将 beanA 添加到三级缓存 singletonFactories 中，并将 beanA 从二级缓存 earlySingletonObjects 中移除（虽然此时的二级缓存当中没有beanA），最后将 beanName 添加至 registeredSingletons 中，表示该 bean 实例已经被注册

2、beanA 的属性填充——初始化

回到 doCreateBean(beanName, mbdToUse, args) 方法中：

接着回到 doCreateBean(beanName, mbdToUse, args) 方法中，需要执行 populateBean(beanName, mbd, instanceWrapper) 方法对 beanA 中的属性进行填充

进入 populateBean(beanName, mbd, instanceWrapper) 方法：

反射获取 beanA 的属性列表

执行 applyPropertyValues(beanName, mbd, bw, pvs) 方法完成 beanA 属性的填充

进入 applyPropertyValues(beanName, mbd, bw, pvs) 方法：

取到 beanA 的属性列表，发现有个属性为 b

遍历每一个属性，并对每一个属性进行注入，valueResolver.resolveValueIfNecessary(pv, originalValue) 的作用：Given a PropertyValue, return a value, resolving any references to other beans in the factory if necessary.

进入 valueResolver.resolveValueIfNecessary(pv, originalValue) 方法：

通过 resolveReference(argName, ref) 解决依赖注入的问题：

进入 resolveReference(argName, ref) 方法：

先获得属性 b 的名称，再通过 this.beanFactory.getBean(resolvedName) 方法获取 beanB 的实例

3、beanB 的实例化

进入 this.beanFactory.getBean(resolvedName) 方法：

哦，这熟悉的 doGetBean(name, null, null, false) 方法：

再次执行 doGetBean(name, null, null, false) 方法：

beanB 还没有实例化，因此 getSingleton(beanName) 方法返回 null

又来到了这个熟悉的地方，先尝试获取 beanB 实例，获取不到就执行 createBean() 的操作

进入 getSingleton(beanName, () -> {... } 方法：

首先尝试从一级缓存 singletonObjects 中获取 beanB，那肯定是获取不到的呀

然后就调用 singletonFactory.getObject() 创建 beanB

进入 createBean(beanName, mbd, args) 方法：

获取到 beanB 的类型为 com.heygo.spring.circulardependency.B

之前创建 beanA 的时候没有看到，现在看到挺有趣的：Give BeanPostProcessors a chance to return a proxy instead of the target bean instance. 也就是说我们可以通过 BeanPostProcessors 返回 bean 的代理，而非 bean 本身。然后喜闻乐见，又来到了 doCreateBean(beanName, mbdToUse, args) 环节

进入 doCreateBean(beanName, mbdToUse, args) 方法：

老样子，创建 beanB 对应的 BeanWrapper instanceWrapper

进入 createBeanInstance(beanName, mbd, args) 方法：

调用 instantiateBean(beanName, mbd) 创建 beanWrapper

进入 instantiateBean(beanName, mbd) 方法：

调用 getInstantiationStrategy().instantiate(mbd, beanName, this) 创建 beanWrapper

进入 getInstantiationStrategy().instantiate(mbd, beanName, this) 方法：

获取 com.heygo.spring.circulardependency.B 的构造器，并将构造器信息记录在 bd.resolvedConstructorOrFactoryMethod 字段中

调用 BeanUtils.instantiateClass(constructorToUse) 方法创建 beanB 实例：

进入 BeanUtils.instantiateClass(constructorToUse) 方法：

通过调用 B 类的构造器创建 beanB 实例，此时控制台会输出：【B created success】

回到 instantiateBean(beanName, mbd) 方法中：

在 instantiateBean(beanName, mbd) 方法中得到创建好的 beanB 实例，并将其丢进 beanWrapper 中，封装为 BeanWrapper bw 对象

回到 doCreateBean(beanName, mbdToUse, args) 方法中：

createBeanInstance(beanName, mbd, args)方法将返回包装着 beanB 的beanWrapper

执行 BeanPostProcessor 的处理过程：

beanB 由于满足单例并且正在被创建，因此 beanB 可以被提前暴露出去（在属性还未初始化的时候可以提前暴露出去），于是执行 addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean)) 方法将其添加至三级缓存 singletonFactory 中

进入 addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean)) 方法：

将 beanB 实例添加至三级缓存 singletonFactory 中，从二级缓存 earlySingletonObjects 中移除（虽然此时的第二级缓存当中也没有beanB），并注册其 beanName

注：此时第三级缓存有两个值：

• K：beanA，V：beanAFactory的lambda表达式
• K：beanB，V：beanBFactory的lambda表达式

回到 doCreateBean(beanName, mbdToUse, args) 方法中：

执行 populateBean(beanName,mbd,instancewrapper) 方法填充 beanB 的属性

4、beanB 的属性填充——初始化

进入 populateBean(beanName, mbd, instanceWrapper) 方法：

执行 mbd.getPropertyValues() 方法获取 beanB 的属性列表

执行 applyPropertyValues(beanName, mbd, bw, pvs) 方法完成 beanB 属性的填充

进入 applyPropertyValues(beanName, mbd, bw, pvs) 方法：

执行 mpvs.getPropertyValuelist() 方法获取 beanB 的属性列表

遍历每一个属性，并对每一个属性进行注入，valueResolver.resolveValueIfNecessary(pv, originalValue) 的作用：Given a PropertyValue, return a value, resolving any references to other beans in the factory if necessary.

进入 valueResolver.resolveValueIfNecessary(pv, originalValue) 方法：

执行 resolveReference(argName, ref) 方法为 beanB 注入名为 a 属性

进入 resolveReference(argName, ref) 方法：

执行 this.beanFactory.getBean(resolvedName) 方法获取 beanA 实例，其实就是执行 doGetBean(name, null, null, false) 方法

进入 doGetBean(name, null, null, false) 方法：

关键来了，这里执行 getSingleton(beanName) 是够能够获取到 beanA 实例呢？答案是可以

进入 getSingleton(beanName, true) 方法：

getSingleton(beanName) 调用了其重载方法 getSingleton(beanName, true)，接下来的逻辑很重要：

1. beanA 并没有存放在一级缓存 singletonObjects 中，因此执行 Object singletonObject = this.singletonObjects.get(beanName) 后，singletonObject == null，再加上 beanA 正在满足创建的条件（isSingletonCurrentlyInCreation(beanName) == true），因此可以进入第一层 if 判断

   

2. beanA 被存放在三级缓存 singletonFactories 中，从二级缓存 earlySingletonObjects 中获取也是 null，因此可以进入第二层 if 判断

   

3. 从三级缓存中获取 beanA 肯定不为空，因此可以进入第三层 if 判断

   

4. 进入第三个if块之后：

   1. 从单例工厂 singletonFactory 中获取 beanA；
   2. 将 beanA 添加至二级缓存 earlySingletonObjects 中；
   3. 将 beanA 从三级缓存 singletonFactories 中移除

   

注：

• 此时的第三级缓存当中有K：beanB，V：beanBFactory的lambda表达式
• 此时的第二级缓存当中有K：属性A，V：beanA的实例（未完成初始化）

回到 doGetBean(name, null, null, false) 方法中：

执行 Object sharedInstance = getSingleton(beanName) 将获得之前存入三级缓存 singletonFactories 中的 beanA

好家伙，获取到 beanA 后就直接返回了

回到 applyPropertyValues(beanName, mbd, bw, pvs) 方法中：

执行 valueResolver.resolveValueIfNecessary(pv, originalValue) 方法获取到 beanA 实例

将属性 beanA 添加到 deepCopy 集合中（List<PropertyValue> deepCopy = new ArrayList<>(original.size())）

执行 bw.setPropertyValues(new MutablePropertyValues(deepCopy)) 方法将会填充 beanB 中的 a 属性

进入 bw.setPropertyValues(new MutablePropertyValues(deepCopy)) 方法：

调用了其重载方法 setPropertyValues(pvs, false, false)：

进入 setPropertyValues(pvs, false, false) 方法：

在该方法中会对 bean 的每一个属性进行填充（通过 setPropertyValues(pvs, false, false) 方法对属性进行赋值）

回到 applyPropertyValues(beanName, mbd, bw, pvs) 方法中：

此时 bw 包裹着 beanB，执行 bw.setPropertyValues(new MutablePropertyValues(deepCopy)) 方法会将 deepCopy 中的元素依次赋值给 beanB 的各个属性，此时 beanB 中的 a 属性已经赋值为 beanA

回到 doCreateBean(beanName, mbdToUse, args) 方法中：

因为 instanceWrapper 封装了 beanB，所以执行了 populateBean(beanName, mbd, instanceWrapper) 方法后，beanB 中的 a 属性就已经被填充啦，可以看到 beanB 中有 beanA，但 beanA 中没有 beanB

执行 getSingleton(beanName, false) 方法，传入的参数 allowEarlyReference = false，表示不允许从三级缓存 singletonFactories 中获取 beanB

进入 getSingleton(beanName, false) 方法：

由于传入的参数 allowEarlyReference = false，因此第三层 if 判断铁定进不去，而 beanB 在三级缓存 singletonFactories 中存着，因此返回的 singletonObject 为 null

回到 doCreateBean(beanName, mbdToUse, args) 方法中：

这里应该是执行 bean 的 destroy-method ，应该只会在工厂销毁的时候并且 bean 为单例的条件下，其内部逻辑才会执行。registerDisposableBeanIfNecessary(beanName, bean, mbd) 方法的注释如下：Add the given bean to the list of disposable beans in this factory, registering its DisposableBean interface and/or the given destroy method to be called on factory shutdown (if applicable). Only applies to singletons. 最后将 beanB 返回（属性 a 已经填充完毕）

回到 createBean(beanName, mbd, args) 方法：

执行 doCreateBean(beanName, mbdToUse, args) 方法得到包装 beanB 实例（属性 a 已经填充完毕），并将其返回

回到 getSingleton(beanName, () -> { ... } 方法中：

执行 singletonFactory.getObject() 方法获取到 beanB 实例，这里的 singletonFactory 是之前调用 getSingleton(beanName, () -> { … } 方法传入的 Lambda 表达式，然后将 newSingleton 设置为 true

执行 addSingleton(beanName, singletonObject) 方法将 beanB 实例添加到一级缓存 singletonObjects 中

进入 addSingleton(beanName, singletonObject) 方法：

1. 将 beanB 放入一级缓存 singletonObjects 中
2. 将 beanB 从三级缓存 singletonFactories 中删除（beanB 确实在三级缓存中）
3. 将 beanB 从二级缓存 earlySingletonObjects 中删除（beanB 并不在二级缓存中）
4. 将 beanB 的 beanName 注册到 registeredSingletons 中（之前添加至三级缓存的时候已经注册过啦~）

注：

• 此时的第三级缓存当中已经没有东西了
• 第二级缓存当中有K：A，V：beanA的实例（半成品，未初始化）
• 第一级缓存当中有K：B，V：beanB的实例（成品）

回到 getSingleton(beanName, () -> { ... } 方法中：

执行 addSingleton(beanName, singletonObject) 将 beanB 添加到一级缓存 singletonObjects 后，将 beanB 返回

回到 doGetBean(name, null, null, false) 方法中：

执行完 getSingleton(beanName, () -> { ... } 方法后，得到属性已经填充好的 beanB，并且已经将其添加至一级缓存 singletonObjects 中

将 beanB 返回，想想返回到哪儿去了呢？当初时因为 beanA 要填充其属性 b，才执行了创建 beanB 的操作，现在返回肯定是将 beanB 返回给 beanA

5、beanA 的属性填充

回到 resolveReference(argName, ref) 方法中：

执行完 this.beanFactory.getBean(resolvedName) 方法后，获得了属性填充好的 beanB 实例，并将其实例返回

回到 applyPropertyValues(beanName, mbd, bw, pvs) 方法中：

执行完 valueResolver.resolveValueIfNecessary(pv, originalValue) 方法后，将获得属性填充好的 beanB 实例

将 b 属性添加至 deepCopy 集合中：

执行 bw.setPropertyValues(new MutablePropertyValues(deepCopy)) 方法对 beanA 的 b 属性进行填充

进入 setPropertyValues(pvs, false, false) 方法：

在 bw.setPropertyValues(new MutablePropertyValues(deepCopy)) 方法中调用了 setPropertyValues(pvs, false, false) 方法，在该方法中会对 bean 的每一个属性进行填充（通过 setPropertyValues(pvs, false, false) 方法对属性进行赋值）

回到 applyPropertyValues(beanName, mbd, bw, pvs) 方法中：

此时 bw 中包裹着 beanA，执行 bw.setPropertyValues(new MutablePropertyValues(deepCopy)) 方法会将 deepCopy 中的元素依次赋值给 beanA 的各个属性，此时 beanA 中的 b 属性已经赋值为 beanA，又加上之前 beanB 中的 a 属性已经赋值为 beanA，此时可开启无限套娃模式

回到 doCreateBean(beanName, mbdToUse, args) 方法中：

执行完 populateBean(beanName, mbd, instanceWrapper) 方法后，可以开启无限套娃模式

这次执行 getSingleton(beanName, false) 方法能获取到 beanA 吗？答：可以

进入 getSingleton(beanName, false) 方法：

之前 beanB 中注入 a 属性时，将 beanA 从三级缓存 singletonFactories 移动到了二级缓存 earlySingletonObjects 中，因此可以从二级缓存 earlySingletonObjects 中获取到 beanA

回到 doCreateBean(beanName, mbdToUse, args) 方法中：

最终将获取到的 beanA 返回

回到 createBean(beanName, mbd, args) 方法中：

执行 doCreateBean(beanName, mbdToUse, args) 方法后得到 beanA 实例，并将此实例返回

回到 getSingleton(beanName, () -> { ... } 方法：

执行 singletonFactory.getObject() 方法后将获得 beanA 实例，这里的 singletonFactory 是我们传入的 Lambda 表达式（专门用于创建 bean 实例）

执行 addSingleton(beanName, singletonObject) 方法将 beanA 添加到一级缓存 singletonObjects 中

进入 addSingleton(beanName, singletonObject) 方法：

1. 将 beanA 放入一级缓存 singletonObjects 中
2. 将 beanA 从三级缓存 singletonFactories 中删除（beanA 并不在三级缓存中）
3. 将 beanA 从二级缓存 earlySingletonObjects 中删除（beanA 确实在二级缓存中）
4. 将 beanA 的 beanName 注册到 registeredSingletons 中（之前添加至三级缓存的时候已经注册过啦~）

注：

• 此时的第三级、第二级缓存都没有东西了
• 在第一级缓存有两个已经实例化初始化好的成品：beanA与beanB

回到 getSingleton(beanName, () -> { ... } 方法中：

将 beanA 添加至一级缓存 singletonObjects 后，将其返回

回到 doGetBean(name, null, null, false) 方法中：

执行 getSingleton(beanName, () -> { ... } 方法得到 beanA 实例后，将其返回

回到 preInstantiateSingletons() 方法中：

终于要结束了。。。执行完 getBean(beanName) 方法后，将得到无限套娃版本的 beanA 和 beanB 实例

6、循环依赖总结

全部 Debug 断点：

导出 Debug 所有断点：点击【View Breakpoints】

Debug 步骤总结：

1. 调用doGetBean()方法，想要获取beanA，于是调用getSingleton()方法从缓存中查找beanA
2. 在getSingleton()方法中，从一级缓存中查找，没有，返回null
3. doGetBean()方法中获取到的beanA为null，于是走对应的处理逻辑，调用getSingleton()的重载方法（参数为ObjectFactory的)去获取一个beanA单例
4. 在getSingleton()方法中，先将beanA_name添加到一个集合中，用于标记该bean正在创建中。然后回调匿名内部类的creatBean()方法创建beanA对象
5. 进入AbstractAutowireCapableBeanFactory#doCreateBean()，先反射调用构造器创建出beanA的实例，然后判断。是否为单例、是否允许提前暴露引用(对于单例一般为true)**、是否正在创建中〈即是否在第四步的集合中)。判断为true则将beanA添加到【三级缓存】中**
6. 调用populateBean()对beanA进行属性填充，此时检测到beanA依赖于beanB，于是开始从一级缓存当中查找beanB
7. 调用doGetBean()方法，和上面beanA的过程一样，到一级缓存中查找beanB，没有则创建，然后给beanB填充属性
8. 此时beanB依赖于beanA，调用getSingleton()获取beanA，依次从一级、二级、三级缓存中找，此时从三级缓存中获取到beanA的创建工厂，通过创建工厂获取到singletonObject，此时这个singletonObject指向的就是上面在doCreateBean()方法中实例化的beanA
9. 这样beanB就获取到了beanA的依赖，于是beanB顺利完成实例化，将beanB从第三级缓存放在第一级缓存当中，并将beanA从三级缓存移动到二级缓存中
10. 随后beanA继续他的属性填充工作，此时也获取到了beanB，beanA也随之完成了创建，回到getsingleton()方法中继续向下执行，将beanA从二级缓存移动到一级缓存中

7、三级缓存总结

Spring 创建 Bean 的两大步骤：

1. 创建原始bean对象
2. 填充对象属性和初始化

每次创建bean之前，我们都会从缓存中查下有没有该bean，因为是单例，只能有一个。当我们创建 beanA的原始对象后，并把它放到三级缓存中，接下来就该填充对象属性了，这时候发现依赖了beanB，接着就又去创建beanB，同样的流程，创建完 beanB填充属性时又发现它依赖了beanA又是同样的流程。

==不同的是==：这时候可以在三级缓存中查到刚放进去的原始对象beanA，所以不需要继续创建，用它注入beanB，完成beanB的创建。既然 beanB创建好了，所以beanA就可以完成填充属性的步骤了，接着执行剩下的逻辑，闭环完成。

Spring解决循环依赖依靠的是Bean的“中间态”这个概念，而这个中间态指的是已经实例化但还没初始化的状态，也即半成品。

实例化的过程又是通过构造器创建的，如果A还没创建好出来怎么可能提前曝光，所以构造器的循环依赖无法解决。

Spring为了解决单例的循环依赖问题，使用了三级缓存：

1. 其中一级缓存为单例池〈 singletonObjects)，我们的应用中使用的bean对象就是一级缓存中的
2. 二级缓存为提前曝光对象( earlySingletonObjects)，用来解决对象创建过程中的循环依赖问题
3. 三级缓存为提前曝光对象工厂( singletonFactories），用于处理存在 AOP 时的循环依赖问题

假设A、B循环引用，实例化A的时候就将其放入三级缓存中，接着填充属性的时候，发现依赖了B，同样的流程也是实例化后放入三级缓存，接着去填充属性时又发现自己依赖A，这时候从缓存中查找到早期暴露的A，没有AOP代理的话，直接将A的原始对象注入B，完成B的初始化后，进行属性填充和初始化，这时候B完成后，就去完成剩下的A的步骤，如果有AOP代理，就进行AOP处理获取代理后的对象A，注入B，走剩下的流程。

8、Spring循环依赖+AOP源码分析

1、情况一：没有依赖，有 AOP

此时， SimpleBean 对象在 Spring 中是如何创建的呢，我们一起来跟下源码

接下来，我们从 DefaultListableBeanFactory 的 preInstantiateSingletons 方法开始 debug

没有跟进去的方法，或者快速跳过的，我们可以先略过，重点关注跟进去了的方法和停留了的代码，此时有几个属性值中的内容值得我们留意下：

我们接着从 createBean 往下跟

关键代码在 doCreateBean 中，其中有几个关键方法的调用值得大家去跟下：

此时：代理对象的创建是在对象实例化完成，并且初始化也完成之后进行的，是对一个成品对象创建代理对象

所以此种情况下：只用一级缓存就够了，其他两个缓存可以不要

2、情况二：循环依赖，没有AOP

此时循环依赖的两个类是： Circle 和 Loop

对象的创建过程与前面的基本一致，只是多了循环依赖，少了 AOP，所以我们重点关注： populateBean 和 initializeBean 方法

先创建的是 Circle 对象，那么我们就从创建它的 populateBean 开始，再开始之前，我们先看看三级缓存中的数据情况

我们开始跟 populateBean ，它完成属性的填充，与循环依赖有关，一定要仔细看，仔细跟

对 circle 对象的属性 loop 进行填充的时候，去 Spring 容器中找 loop 对象，发现没有则进行创建，又来到了熟悉的 createBean

此时三级缓存中的数据没有变化，但是 Set<String> singletonsCurrentlyInCreation 中多了个 loop

相信到这里大家都没有问题，我们继续往下看

loop 实例化完成之后，对其属性 circle 进行填充，去 Spring 中获取 circle 对象，又来到了熟悉的 doGetBean

此时一、二级缓存中都没有 circle、loop ，而三级缓存中有这两个，我们接着往下看，重点来了，仔细看哦

通过 getSingleton 获取 circle 时，三级缓存调用了 getEarlyBeanReference ，但**由于没有 AOP，所以 getEarlyBeanReference 直接返回了普通的半成品 circle**，然后将 半成品 circle 放到了二级缓存，并将其返回，然后填充到了 loop 对象中

此时的 loop 对象就是一个成品对象了；接着将 loop 对象返回，填充到 circle 对象中，如下如所示

我们发现直接将 成品 loop 放到了一级缓存中，二级缓存自始至终都没有过 loop ，三级缓存虽说存了 loop ，但没用到就直接 remove 了

此时缓存中的数据，相信大家都能想到了：

虽说 loop 对象已经填充到了 circle 对象中，但还有一丢丢流程没走完，我们接着往下看

将 成品 circle 放到了一级缓存中，二级缓存中的 circle 没有用到就直接 remove 了，最后各级缓存中的数据相信大家都清楚了，就不展示了

我们回顾下这种情况下各级缓存的存在感，一级缓存存在感十足，二级缓存可以说无存在感，三级缓存有存在感（向 loop 中填充 circle 的时候有用到）

所以此种情况下：可以减少某个缓存，只需要两级缓存就够了

3、情况三：循环依赖 + AOP

比上一种情况多了 AOP，我们来看看对象的创建过程有什么不一样；同样是先创建 Circle ，在创建 Loop

创建过程与上一种情况大体一样，只是有小部分区别，跟源码的时候我会在这些区别上有所停顿，其他的会跳过，大家要仔细看

实例化 Circle ，然后填充 半成品 circle 的属性 loop ，去 Spring 容器中获取 loop 对象，发现没有

则实例化 Loop ，接着填充 半成品 loop 的属性 circle ，去 Spring 容器中获取 circle 对象

这个过程与前一种情况是一致的，就直接跳过了，我们从上图中的红色步骤开始跟源码，此时三级缓存中的数据如下

我们发现从第三级缓存获取 circle 的时候，调用了 getEarlyBeanReference 创建了 半成品 circle 的代理对象

将 半成品 circle 的代理对象放到了第二级缓存中，并将代理对象返回赋值给了 半成品 loop 的 circle 属性

注意：此时是在进行 loop 的初始化，但却把 半成品 circle 的代理对象提前创建出来了

loop 的初始化还未完成，我们接着往下看，又是一个重点，仔细看

在 initializeBean 方法中完成了 半成品 loop 的初始化，并在最后创建了 loop 成品 的代理对象

loop 代理对象创建完成之后会将其放入到第一级缓存中（移除第三级缓存中的 loop ，第二级缓存自始至终都没有 loop ）

然后将 loop 代理对象返回并赋值给 半成品 circle 的属性 loop ，接着进行 半成品 circle 的 initializeBean

因为 circle 的代理对象已经生成过了（在第二级缓存中），所以不用再生成代理对象了；

将第二级缓存中的 circle 代理对象移到第一级缓存中，并返回该代理对象

此时各级缓存中的数据情况如下（普通 circle 、 loop 对象在各自代理对象的 target 中）

我们回顾下这种情况下各级缓存的存在感，一级缓存仍是存在感十足，二级缓存有存在感，三级缓存挺有存在感

第三级缓存提前创建 circle 代理对象，不提前创建则只能给 loop 对象的属性 circle 赋值成 半成品 circle ，==那么 loop 对象中的 circle 对象就无 AOP 增强功能了==

第二级缓存用于存放 circle 代理，用于解决循环依赖；也许在这个示例体现的不够明显，因为依赖比较简单，依赖稍复杂一些，就能感受到了

第一级缓存存放的是对外暴露的对象，可能是代理对象，也可能是普通对象

所以此种情况下：三级缓存一个都不能少

4、情况四：循环依赖 + AOP + 删除第三级缓存

没有依赖，有AOP 这种情况中，我们知道 AOP 代理对象的生成是在成品对象创建完成之后创建的，这也是 Spring 的设计原则，代理对象尽量推迟创建

循环依赖 + AOP 这种情况中， circle 代理对象的生成提前了，因为必须要保证其 AOP 功能，但 loop 代理对象的生成还是遵循的 Spring 的原则

如果我们打破这个原则，将代理对象的创建逻辑提前，那是不是就可以不用三级缓存了，而只用两级缓存了呢？

对 Spring 的源码做了非常小的改动，改动如下：

去除了第三级缓存，并将代理对象的创建逻辑提前，置于实例化之后，初始化之前；我们来看下执行结果：

并没有什么问题。

5、情况五：循环依赖 + AOP + 注解

目前基于 xml 的配置越来越少，而基于注解的配置越来越多，所以了也提供了一个注解的版本供大家去跟源码

代码还是很简单：spring-circle-annotation

跟踪流程与 循环依赖 + AOP 那种情况基本一致，只是属性的填充有了一些区别，具体可查看：Spring 的自动装配 → 骚话 @Autowired 的底层工作原理

6、总结

1. 三级缓存各自的作用
   1. 第一级缓存的是对外暴露的对象，也就是我们应用需要用到的
   2. 第二级缓存的作用是==为了处理循环依赖的对象创建问题==，里面存的是半成品对象或半成品对象的代理对象
   3. 第三级缓存的作用==处理存在 AOP + 循环依赖的对象创建问题==，能将==代理对象提前创建==
2. Spring 为什么要引入第三级缓存
   1. 严格来讲，第三级缓存并非缺它不可，因为可以提前创建代理对象
   2. 提前创建代理对象只是会节省那么一丢丢内存空间，并不会带来性能上的提升，但是会破环 Spring 的设计原则
   3. Spring 的设计原则是尽可能保证普通对象创建完成之后，再生成其 AOP 代理（尽可能延迟代理对象的生成）
   4. 所以 Spring 用了第三级缓存，既维持了设计原则，又处理了循环依赖；牺牲那么一丢丢内存空间是愿意接受的

9、循环依赖于三级缓存相关面试解答

1、说下什么是循环依赖

两个或则两个以上的bean对象互相依赖对方，最终形成 闭环 。例如 A 对象依赖 B 对象，B 对象也依赖 A 对象

2、那循环依赖会有什么问题呢

在bean对象的创建过程会产生死循环，类似如下

3、那么Spring 是如何解决的呢？

通过三级缓存提前暴露bean对象来解决的

4、三级缓存里面分别存的什么

三级缓存就是三个map对象

1. 一级缓存是一个ConcurrentHashMap，容量为256，里面存的是成品对象，实例化和初始化都完成了，我们的应用中使用的对象就是一级缓存中的
2. 二级缓存是一个HashMap，容量为16，里面存的是半成品，用来解决对象创建过程中的循环依赖问题
3. 三级缓存是一个HashMap，容量为16，里面存的是 ObjectFactory<?> 类型的 lambda 表达式，用于处理存在 AOP 时的循环依赖问题

5、Spring使用三级缓存解决循环依赖的前提是什么？

有两个前提：

1. bean是单例实例，即scope的属性为singleton

   • 因为如果是scope的属性为prototype原型，那么每一次创建的bean对象都是新对象，不会走三级缓存。

2. bean对象的依赖注入方式不能全是构造器注入的方式

   • Spring解决循环依赖依靠的是Bean的“中间态”这个概念，而这个中间态指的是已经实例化但还没初始化的状态，也即半成品。

   • 实例化的过程又是通过构造器创建的，如果A还没创建好出来怎么可能提前曝光，所以构造器的循环依赖无法解决

   • 也就是说：

     • 构造方法注入的方式，将实例化与初始化并在一起完成，能够快速创建一个可直接使用的对象
     • setter 方法注入的方式，是在对象实例化完成之后，再通过反射调用对象的 setter 方法完成属性的赋值。将对象的实例化与初始化分隔开了

   • 那又为什么说不能全是构造器注入的方式

     依赖情况	依赖注入方式	循环依赖是否被解决
     AB相互依赖（循环依赖）	均采用setter方式注入	是
     AB相互依赖（循环依赖）	均采用构造器方式注入	否
     AB相互依赖（循环依赖）	A注入B的方式为setter，B注入A的方式为构造器	是
     AB相互依赖（循环依赖）	B注入A的方式为setter，A注入B的方式为构造器	否

   为什么在下表中的第三种情况的循环依赖能被解决，而第四种情况不能被解决呢？

   Spring在创建Bean时默认会根据自然排序进行创建，所以A会先于B进行创建。

6、为什么要用三级缓存来解决循环依赖问题（只用一级缓存行不行，只用二级缓存行不行）

只用一级缓存也是可以解决的，但是会复杂化整个逻辑

半成品对象是没法直接使用的（存在 NPE 问题），所以 Spring 需要保证在启动的过程中，所有中间产生的半成品对象最终都会变成成品对象。

如果将半成品对象和成品对象都混在一级缓存中，那么为了区分他们，势必会增加一些而外的标记和逻辑处理，这就会导致对象的创建过程变得复杂化了。

将半成品对象与成品对象分开存放，两级缓存各司其职，能够简化对象的创建过程，更简单、直观。

如果 Spring 不引入 AOP，那么两级缓存就够了，但是作为 Spring 的核心之一，AOP 怎能少得了呢？

所以为了处理 AOP代理时的循环依赖，Spring 引入第三级缓存来处理循环依赖时的代理对象的创建。

如果要使用二级缓存解决循环依赖，意味着所有Bean在实例化后就要完成AOP代理，这样违背了Spring设计的原则，Spring在设计之初就是通过AnnotationAwareAspectJAutoProxyCreator这个后置处理器来在Bean生命周期的最后一步来完成AOP代理，而不是在实例化后就立马进行AOP代理。

7、如果将代理对象的创建过程提前，紧随于实例化之后，而在初始化之前，那是不是就可以只用两级缓存了？

可以，没有问题。但是会破坏Spring的设计原则：尽可能保证普通对象创建完成之后，再生成其 AOP 代理（尽可能延迟代理对象的生成）

Linux

1、Linux常用服务类相关命令

1、service (Centos6)

• 注册在系统中的标准化程序

• 有方便统一的管理方式(常用的方法)

  • service 服务名 start：开启服务
  • service 服务名 stop：关闭服务
  • service 服务名 restart：重启服务
  • service 服务名 reload：重新加载服务
  • service 服务名 status：查看当前服务的状态

• 查看服务的方法：/etc/init.d/服务名

• 通过chkconfig命令设置自启动

  • 查看服务

    1	chkconfig --list | grep xxx

  • 设置服务是否开机自启动

    1	chkconfig --level 5 服务名 off

2、systemctl (Centos7)

• 注册在系统中的标准化程序

• 有方便统一的管理方式(常用的方法)

  • systemctl start 服务名(xxxx.service)：开启服务
  • systemctl restart 服务名(xxxx.service)：重启服务
  • systemctl stop 服务名(xxxx.service)：关闭服务
  • systemctl reload 服务名(xxxx.service)：重新加载服务
  • systemctl status 服务名(xxxx.service)：查看当前服务的状态

• 查看服务的方法：/usr/lib/systemd/system

• 查看服务的命令

  1 2 3 4 5 6

  systemctl list-unit-files # 可以使用grep进行过滤 systemctl list-unit-files | grep xxx systemctl --type service

• 通过systemctl命令设置自启动

  1 2 3 4 5

  # 开机自启动 systemctl enable service_name # 开机不自启动 systemctl disable service_name

Git

1、git分支相关命令

• 创建分支

  1 2 3 4 5

  # 创建分支 git branch <分支名> # 查看分支 git branch -v <分支名>

• 切换分支

  1 2 3 4

  git checkout <分支名> # 一步完成：创建分支并切换到该分支（最常用） git checkout -b <分支名>

• 合并分支

  1 2 3 4 5

  # 先切换到主分支 git checkout master # 合并分支 git merge <分支名>

• 删除分支

  1 2 3 4 5

  # 先切换到主分支 git checkout master # 删除分支 git branch -D <分支名>

2、请讲一下Git的工作流

• 在master主分支下分出develop开发分支进行开发工作
  • master一般是项目经理或者运维人员才能操作的
  • 开发人员接触的最多的就是develop分支
  • 注意：master分支和develop要保持一致
• 在develop分支下，根据项目的不同模块再分出对应的开发分支
• 如果在master主分支（上线）出现了bug，那么master会分出hotfix分支进行bug的修复工作
  • bug修复过后在下线master分支，将hotfix分支合并到master之后在上线
  • 同时要将hotfix分支合并到develop分支当中，保证master分支和develop要保持一致，防止将来把develop分支合并到master主分支出现重复的bug
• 当模块的开发工作完成之后，将对应模块的开发分支提交到develop分支当中，并创建release分支查看是否有bug，如果有bug的话进行修复。最终合并到master主分支当中进行上线

3、GitHub的常用词

• watch：会持续收到该项目的动态
• fork：复制某个项目到自己的GitHub仓库
• star：点赞
• clone：将项目下载至本地
• follow：关注你感兴趣的作者，会收到他们的动态

4、in关键字限制搜索范围

公式：

1

[要搜索的关键字] in name 或description 或readme

• xxx in:name——项目名包含xxx的
• xxx in:description——项目描述包含xxx的
• xxx in:readme——项目的readme文件中包含xxx的

组合使用：

1
2

# 搜索项目名或者readme或者项目描述中包含秒杀的项目
seckill in:name,readmw,description

5、stars或fork数量关键词去查找

stars的公式：

1
2
3
4
5
6
7

[要搜索的关键字] stars 通配符[:> 或者 :>=]

# 区间范围数字
[要搜索的关键字] stars:数字1..数字2

# eg：查找stars数大于等于5000的springboot项目
springboot stars:>=5000

forks的公式：

1
2
3
4
5
6
7

[要搜索的关键字] forks 通配符[:> 或者 :>=]

# 区间范围数字
[要搜索的关键字] forks:数字1..数字2

# eg：查找forks数大于500的springcloud项目
springcloud forks:>500

组合使用：

1
2

# 查找fork在100到200之间并且stars数在80到100之间的springboot项目
springboot forks:100..200 stars:80..100

6、awesome加强搜索

公式：

1

awesome 关键字

awesome系列一般是用来学习、工具、书籍类相关的项目

使用：搜索优秀的redis相关的项目，包括框架、教程等

1

awesome redis

7、高亮显示某一行代码

公式：

1
2
3
4
5
6
7
8
9

# 1行
地址后面紧跟#L数字
# eg:高亮显示在Dao层的SeckillDao.java的第13行
https://github.com/codingXiaxw/seckill/blob/master/scr/main/java/cn/codingxiaxw/dao/SeckillDao.java#L13

# 多行
地址后面紧跟#L数字-L数字2
# eg
https://github.com/codingXiaxw/seckill/blob/master/scr/main/java/cn/codingxiaxw/dao/SeckillDao.java#L13-L23

8、项目内搜索

在键盘输入英文t，此时路径会变成xxx/find/master。网页的代码呈现一个树状的结构，方便我们查看源码和相关框架。

github的其他快捷键

9、搜索某个地区内的大佬

公式：

1

location:地区 language:语言

使用：

1
2

# 搜索地区在北京的Java方向的大佬
location:beijing language:java

Redis

1、redis持久化

Redis提供了2个不同形式的持久化方式。

• RDB (Redis DataBase)
• AOF (Append Of File)

1、RDB

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。

备份是如何执行的？

• Redis会单独创建(fork) 一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。
• 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。
• RDB的缺点是最后一次持久化后的数据可能丢失。

RDB的优缺点：

• 优点：
  • 节省磁盘空间
  • 恢复速度快
• 缺点：
  • 虽然Redis在fork时使用了写时拷贝技术，但是如果数据庞大时还是比较消耗性能。
  • 在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

2、AOF

以日志的形式来记录每个==写==操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，Redis启动之初会读取该文件重新构建数据，换言之，Redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

备份是如何执行的？

AOF与RDB类似，都是依靠一个fork子进程和一个缓冲区进行写指令的备份的。而且AOF在进行写指令备份的时候，可以开启重写机制来提高性能

AOF的优缺点：

• 优点：
  • 备份机制更稳健，丢失数据概率更低。
  • 可读的日志文本，通过操作AOF稳健，可以处理误操作。
• 缺点：
  • 恢复备份速度要慢。
  • 每次读写都同步的话，有一定的性能压力。
  • 存在个别Bug，造成恢复不能。

2、Redis在项目中的使用场景

3、Redis 6.0.7的bug

Redis突然发布了紧急版本 6.0.8 ，之前消息称 6.0.7 被称作最后一个 6.x 版本，但 Redis 团队表示 6.0.8 版本升级迫切性等级为高：任何将 Redis 6.0.7 与 Sentinel 或 CONFIG REWRITE 命令配合使用的人都会受到影响，应尽快升级。

从官方给出的信息来看，估计是出现了Bug，具体更新的内容如下：

1. Bug修复
   1. CONFIG REWRITE在通过CONFIG设置oom-score-adj-values后，可以通过CONFIG设置或从配置文件中加载，会生成一个损坏的配置文件。将会导致Redis无法启动
   2. 修正MacOS上redis-cli –pipe的问题。
   3. 在不存在的密钥上，修复HKEYS/HVALS的RESP3响应。
   4. 各种小的错误修复
2. 新功能
   1. 当设置为madvise时，移除THP警告。
   2. 允许在群集中只读副本上使用读命令进行EXEC。
   3. 在redis-cli-cluster调用命令中增加master/replicas选项。
3. 模块化API
   1. 添加RedisModule_ThreadSafeContextTryLock。

官网地址：

• 官网地址：https://redis.io/
• 中文官网地址：http://www.redis.cn/

查看当前Redis版本的方法：

1. 在 Linux 命令行下：在 redis 安装目录下执行 redis-server -v 命令
2. 在 redis 客户端命令行下：执行 info 命令，第二行就是当前启动的Redis的版本

4、Redis 命令大全

官网命令大全

直接搜索即可

如果当前不能使用外网或者不能进行线上查看，可以使用Redis自带的help指令：help @关键字

eg：help @String

注意事项：执行 redis 指令可能会出现如下错误：(error) MISCONF Redis is configured to save RDB snapshots, but it is currently not able to persist on disk. Commands that may modify the data set are disabled, because this instance is configured to report errors during writes if RDB snapshotting fails (stop-writes-on-bgsave-error option). Please check the Redis logs for details about the RDB error.

原因分析：究其原因是因为强制把 redis 快照关闭了导致不能持久化的问题，在网上查了一些相关解决方案，通过 stop-writes-on-bgsave-error 值设置为 no 即可避免这种问题。

解决方案一：通过 redis 命令行修改，在 redis 命令行执行 config set stop-writes-on-bgsave-error no 指令

解决方案二：直接修改 redis.conf 配置文件，使用 vim 编辑器打开 redis-server 配置的 redis.conf 文件，然后使用快捷匹配模式：/stop-writes-on-bgsave-error 定位到 stop-writes-on-bgsave-error 字符串所在位置，接着把后面的 yes 设置为 no 即可。

5、Redis的分布式锁

知道分布式锁吗？有哪些实现方案？ 你谈谈对redis分布式锁的理解， 删key的时候有什么问题？

单机版的锁与分布式锁：

• JVM层面的加锁，单机版的锁
• 分布式微服务架构，拆分后各个微服务组件为了避免冲突和数据故障而加入的一种锁，分布式的锁

分布式锁的几种实现方式：

1. mysql
2. zookeeper
3. redis

一般的互联网公司，大家都习惯用redis做分布式锁

redis ==》 redlock ==》 redisson

1、分布式锁的常见面试题

1. Redis除了拿来做缓存，你还见过基于Redis的什么用法?
2. Redis做分布式锁的时候有需要注意的问题?
3. 如果是Redis是单点部署的，会带来什么问题? 那你准备怎么解决单点问题呢?
4. 集群模式下，比如主从模式，有没有什么问题呢?
5. 那你简单的介绍一下Redlock吧? 你简历上写redisson，你谈谈
6. Redis分布式锁如何续期?看门狗知道吗?

2、为什么需要分布式锁？分布式锁的最终形成

1、版本1.0：单机版&没加锁

问题：单机版程序没有加锁，在并发测试下数字不对，会出现并发安全问题

解决：加锁，那么问题又来了，加 synchronized 锁还是 ReentrantLock 锁呢？

1. synchronized：不见不散，等不到锁就会死等
2. ReentrantLock：过时不候，lock.tryLock() 提供一个过时时间的参数，时间一到自动放弃锁

如何选择：根据业务需求来选，如果非要抢到锁不可，就使用 synchronized 锁；如果可以暂时放弃锁，等会再来强，就使用 ReentrantLock 锁

2、版本2.0：单机版&加锁

使用 synchronized 锁保证单机版程序在并发下的安全性

注意事项：

1. 在单机环境下，可以使用 synchronized 锁或 Lock 锁来实现。
2. 但是在分布式系统中，因为竞争的线程可能不在同一个节点上（同一个 jvm 中）即不同线程抢夺的不是同一把锁，所以需要一个让所有进程都能访问到的锁来实现，比如 redis 或者 zookeeper 来构建；
3. 不同进程 jvm 层面的锁就不管用了，那么可以利用第三方的一个组件，来获取锁，未获取到锁，则阻塞当前想要运行的线程

3、版本3.0：分布式版&不加分布式锁

分布式部署之后，单机版的锁失效，撤销单机版的锁，并且在微服务之上，挡了一个 nginx 服务器，用于实现负载均衡的功能

在jmeter的压测下出现并发问题

4、版本4.0：分布式版&用redis做分布式锁

Redis具有极高的性能，且其命令对分布式锁支持友好，借助 SET 命令即可实现加锁处理

设置分布式锁：set key value [Ex seconds] [PX milliseconds] [NX|XX]

参数解释：

1. EX：key在多少秒之后过期
2. PX：key在多少毫秒之后过期
3. NX：当key不存在的时候，才创建key，效果等同于setnx key value
4. XX：当key存在的时候，覆盖key

代码层面：

使用当前请求的 UUID + 线程名作为分布式锁的 value：

1
2

// 当前请求的 UUID + 线程名
String value = UUID.randomUUID().toString()+Thread.currentThread().getName();

使用setnx命令的jedis来加分布式锁

1
2
3
4
5
6
7
8
9
10
11
12

// 分布式锁
private static final Object REDIS_LOCK_KEY = new Object();

// setIfAbsent() 就相当于 setnx，如果不存在就新建锁
Boolean lockFlag = stringRedisTemplate.opsForValue().setIfAbsent(REDIS_LOCK_KEY, value);

// 抢锁失败
if(lockFlag == false){
    return "抢锁失败 o(╥﹏╥)o";
}

// 业务代码

进程抢占分布式锁，如果抢占失败，则返回值为 false；如果抢占成功，则返回值为 true。

最后记得解锁：

1
2

// 释放分布式锁
stringRedisTemplate.delete(REDIS_LOCK_KEY);

5、版本5.0：finally版

上面代码存在的问题：如果代码在执行的过程中出现异常，那么就可能无法释放锁，因此必须要在代码层面加上 finally 代码块，保证锁的释放

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

try {
    // 加锁
    // setIfAbsent() 就相当于 setnx，如果不存在就新建锁
    Boolean lockFlag = stringRedisTemplate.opsForValue().setIfAbsent(REDIS_LOCK_KEY, value);

    // 抢锁失败
    if (lockFlag == false) {
        return "抢锁失败 o(╥﹏╥)o";
    }

    // 业务代码
} finally {
    // 释放分布式锁
    stringRedisTemplate.delete(REDIS_LOCK_KEY);
}

6、版本6.0：过期时间版

上面代码存在的问题：假设部署了微服务 jar 包的服务器挂了，代码层面根本没有走到 finally 这块，也没办法保证解锁。既使之后该服务器重新启动，这个 key 也没有被删除，其他微服务就一直抢不到锁，因此我们需要加入一个过期时间限定的 key

使用setex命令的jedis来加分布式锁的过期时间

1
2
3
4

// setIfAbsent() 就相当于 setnx，如果不存在就新建锁
Boolean lockFlag = stringRedisTemplate.opsForValue().setIfAbsent(REDIS_LOCK_KEY, value);
// 设置过期时间为 10s
stringRedisTemplate.expire(REDIS_LOCK_KEY, 10L, TimeUnit.SECONDS);

7、版本7.0：加锁原子版

上面代码存在的问题：加锁与设置过期时间的操作分开了，假设服务器刚刚执行了加锁操作，然后宕机了，也没办法保证解锁。——没能保证加锁与过期时间的原子性

使用setIfAbsent的重载方法来保证原子性：

1
2
3
4
5
6
7

// setIfAbsent() 就相当于 setnx，如果不存在就新建锁，同时加上过期时间保证原子性
Boolean lockFlag = stringRedisTemplate.opsForValue().setIfAbsent(REDIS_LOCK_KEY, value, 10L, TimeUnit.SECONDS);

// 抢锁失败
if (lockFlag == false) {
    return "抢锁失败 o(╥﹏╥)o";
}

8、版本8.0：加UUID防止张冠李戴

上面代码存在的问题：张冠李戴，删除了别人的锁：我们无法保证一个业务的执行时间，有可能是 10s，有可能是 20s，也有可能更长。因为执行业务的时候可能会调用其他服务，我们并不能保证其他服务的调用时间。如果设置的锁过期了，当前业务还正在执行，那么就有可能出现并发问题，并且还有可能出现当前业务执行完成后，释放了其他业务的锁

如下图，假设进程 A 在 T2 时刻设置了一把过期时间为 30s 的锁，在 T5 时刻该锁过期被释放，在 T5 和 T6 期间，Test 这把锁已经失效了，并不能保证进程 A 业务的原子性了。于是进程 B 在 T6 时刻能够获取 Test 这把锁，但是进程 A 在 T7 时刻删除了进程 B 加的锁，进程 B 在 T8 时刻删除锁的时候就蒙蔽了，我 TM 锁呢？

因此可以在解锁之前使用UUID判断当前的锁是不是自己的锁

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// 当前请求的 UUID + 线程名
String value = UUID.randomUUID().toString() + Thread.currentThread().getName();
try {
    // setIfAbsent() 就相当于 setnx，如果不存在就新建锁，同时加上过期时间保证原子性
    Boolean lockFlag = stringRedisTemplate.opsForValue().setIfAbsent(REDIS_LOCK_KEY, value, 10L, TimeUnit.SECONDS);

    // 抢锁失败
    if (lockFlag == false) {
        return "抢锁失败 o(╥﹏╥)o";
    }
    // ...
} finally {
    // 判断是否是自己加的锁
    if(value.equalsIgnoreCase(stringRedisTemplate.opsForValue().get(REDIS_LOCK_KEY))){
        stringRedisTemplate.delete(REDIS_LOCK_KEY); // 释放分布式锁
    }
}

9、版本9.0：解锁原子性

上面代码存在的问题：在 finally 代码块中的判断与删除并不是原子操作，假设执行 if 判断的时候，这把锁还是属于当前业务，但是有可能刚执行完 if 判断，这把锁就被其他业务给释放了，还是会出现误删锁的情况

1、版本9.1：解锁原子性——lura脚本保证解锁原子性操作（常用）

lua 脚本

redis 可以通过 eval 命令保证代码执行的原子性

代码：

1、**RedisUtils 工具类**：

getJedis() 方法用于从 jedisPool 中获取一个连接块对象

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

public class RedisUtils {

    private static JedisPool jedisPool;

    // Redis服务器的IP地址
    private static String hostAddr = "192.168.152.233";

    static {
        JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
        jedisPoolConfig.setMaxTotal(20);
        jedisPoolConfig.setMaxIdle(10);
        jedisPool = new JedisPool(jedisPoolConfig, hostAddr, 6379, 100000);
    }

    public static Jedis getJedis() throws Exception {
        if (null != jedisPool) {
            return jedisPool.getResource();
        }
        throw new Exception("Jedispool is not ok");
    }
}

2、使用 lua 脚本保证解锁操作的原子性

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

try {
	// ...
} finally {
    // 获取连接对象
    Jedis jedis = RedisUtils.getJedis();
    // lua 脚本，摘自官网
    String script = "if redis.call('get', KEYS[1]) == ARGV[1]" + "then "
        + "return redis.call('del', KEYS[1])" + "else " + "  return 0 " + "end";
    try {
        // 执行 lua 脚本
        Object result = jedis.eval(script, Collections.singletonList(REDIS_LOCK_KEY), Collections.singletonList(value));
        // 获取 lua 脚本的执行结果
        if ("1".equals(result.toString())) {
            System.out.println("------del REDIS_LOCK_KEY success");
        } else {
            System.out.println("------del REDIS_LOCK_KEY error");
        }
    } finally {
        // 关闭链接
        if (null != jedis) {
            jedis.close();
        }
    }
}

2、版本9.2：解锁原子性——Redis事务保证解锁原子性操作

1、事务介绍

• Redis的事务是通过MULTl，EXEC，DISCARD和WATCH这四个命令来完成。
• Redis的单个命令都是原子性的，所以这里确保事务性的对象是命令集合。
• Redis将命令集合序列化并确保处于同一事务的命令集合连续且不被打断的执行。
• Redis不支持回滚的操作。

2、相关命令

1. MULTI
   1. 用于标记事务块的开始。
   2. Redis会将后续的命令逐个放入队列中，然后使用EXEC命令原子化地执行这个命令序列。
   3. 语法：MULTI
2. EXEC
   1. 在一个事务中执行所有先前放入队列的命令，然后恢复正常的连接状态。
   2. 语法：EXEC
3. DISCARD
   1. 清除所有先前在一个事务中放入队列的命令，然后恢复正常的连接状态。
   2. 语法：DISCARD
4. WATCH
   1. 当某个事务需要按条件执行时，就要使用这个命令将给定的键设置为受监控的状态。
   2. 语法：WATCH key[key..…]
   3. 注：该命令可以实现redis的乐观锁，不会有ABA问题
5. UNWATCH
   1. 清除所有先前为一个事务监控的键。
   2. 语法：UNWATCH

代码：

开启事务不断监视 REDIS_LOCK_KEY 这把锁有没有被别人动过，如果已经被别人动过了，那么继续重新执行删除操作，否则就解除监视

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

try {
    // ...
} finally {
    while (true) {
        //加事务，乐观锁
        stringRedisTemplate.watch(REDIS_LOCK_KEY);
        // 判断是否是自己加的锁
        if (value.equalsIgnoreCase(stringRedisTemplate.opsForValue().get(REDIS_LOCK_KEY))) {
            // 开启事务
            stringRedisTemplate.setEnableTransactionSupport(true);
            stringRedisTemplate.multi();
            stringRedisTemplate.delete(REDIS_LOCK_KEY);
            // 判断事务是否执行成功，如果等于 null，就是没有删掉，删除失败，再回去 while 循环那再重新执行删除
            List<Object> list = stringRedisTemplate.exec();
            if (list == null) {
                continue;
            }
        }
        //如果删除成功，释放监控器，并且 break 跳出当前循环
        stringRedisTemplate.unwatch();
        break;
    }
}

10、版本10.0：自动续期版

上面代码存在的问题：我们无法保证一个业务的执行时间，有可能是 10s，有可能是 20s，也有可能更长。因为执行业务的时候可能会调用其他服务，我们并不能保证其他服务的调用时间。如果设置的锁过期了，当前业务还正在执行，那么之前设置的锁就失效了，就有可能出现并发问题。

因此我们需要确保 redisLock 过期时间大于业务执行时间的问题，即面临如何对 Redis 分布式锁进行续期的问题：

redis 与 zookeeper 在 CAP 方面的对比：

• redis：
  • redis 异步复制造成的锁丢失， 比如：主节点没来的及把刚刚 set 进来这条数据给从节点，就挂了，那么主节点和从节点的数据就不一致。此时如果集群模式下，就得上 Redisson 来解决
• zookeeper：
  • zookeeper 保持强一致性原则，对于集群中所有节点来说，要么同时更新成功，要么失败，因此使用 zookeeper 集群并不存在主从节点数据丢失的问题，但丢失了速度方面的性能

使用 Redisson 实现自动续期功能：

redis 集群环境下，我们自己写的也不OK，直接上 RedLock 之 Redisson 落地实现

1. redis 分布式锁
2. redisson GitHub 地址

代码：

注入 Redisson 对象

在 RedisConfig 配置类中注入 Redisson 对象

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

@Configuration
public class RedisConfig {

    @Value("${spring.redis.host}")
    private String redisHost;

    @Bean
    public RedisTemplate<String, Serializable> redisTemplate(LettuceConnectionFactory connectionFactory) {
        // 新建 RedisTemplate 对象，key 为 String 对象，value 为 Serializable（可序列化的）对象
        RedisTemplate<String, Serializable> redisTemplate = new RedisTemplate<>();
        // key 值使用字符串序列化器
        redisTemplate.setKeySerializer(new StringRedisSerializer());
        // value 值使用 json 序列化器
        redisTemplate.setValueSerializer(new GenericJackson2JsonRedisSerializer());
        // 传入连接工厂
        redisTemplate.setConnectionFactory(connectionFactory);
        // 返回 redisTemplate 对象
        return redisTemplate;
    }

    @Bean
    public Redisson redisson() {
        Config config = new Config();
        config.useSingleServer().setAddress("redis://" + redisHost + ":6379").setDatabase(0);
        return (Redisson) Redisson.create(config);
    }
}

2、业务逻辑

直接 redissonLock.lock()、redissonLock.unlock() 完事儿，这尼玛就是 juc 版本的 redis 分布式锁啊

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

/**
 * @ClassName GoodController
 * @Description TODO
 * @Author Oneby
 * @Date 2021/2/2 18:59
 * @Version 1.0
 */
@RestController
public class GoodController {

    private static final String REDIS_LOCK_KEY = "lockOneby";

    @Autowired
    private StringRedisTemplate stringRedisTemplate;

    @Value("${server.port}")
    private String serverPort;

    @Autowired
    private Redisson redisson;

    @GetMapping("/buy_goods")
    public String buy_Goods() throws Exception {
        // 当前请求的 UUID + 线程名
        String value = UUID.randomUUID().toString() + Thread.currentThread().getName();
        // 获取锁
        RLock redissonLock = redisson.getLock(REDIS_LOCK_KEY);
        // 上锁
        redissonLock.lock();

        try {
            // 从 redis 中获取商品的剩余数量
            String result = stringRedisTemplate.opsForValue().get("goods:001");
            int goodsNumber = result == null ? 0 : Integer.parseInt(result);
            String retStr = null;

            // 商品数量大于零才能出售
            if (goodsNumber > 0) {
                int realNumber = goodsNumber - 1;
                stringRedisTemplate.opsForValue().set("goods:001", realNumber + "");
                retStr = "你已经成功秒杀商品，此时还剩余：" + realNumber + "件" + "\t 服务器端口: " + serverPort;
            } else {
                retStr = "商品已经售罄/活动结束/调用超时，欢迎下次光临" + "\t 服务器端口: " + serverPort;
            }
            System.out.println(retStr);
            return retStr;
        } finally {
            // 解锁
            redissonLock.unlock();
        }
    }
}

完善代码，修改可能出现的bug

问题：在超高并发的情况下，可能会抛出如下异常，原因是解锁 lock 的线程并不是当前线程

代码：在释放锁之前加一个判断：还在持有锁的状态，并且是当前线程持有的锁再解锁

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

@RestController
public class GoodController {

    private static final String REDIS_LOCK_KEY = "lockOneby";

    @Autowired
    private StringRedisTemplate stringRedisTemplate;

    @Value("${server.port}")
    private String serverPort;

    @Autowired
    private Redisson redisson;

    @GetMapping("/buy_goods")
    public String buy_Goods() throws Exception {
        // 当前请求的 UUID + 线程名
        String value = UUID.randomUUID().toString() + Thread.currentThread().getName();
        // 获取锁
        RLock redissonLock = redisson.getLock(REDIS_LOCK_KEY);
        // 上锁
        redissonLock.lock();

        try {
            // 从 redis 中获取商品的剩余数量
            String result = stringRedisTemplate.opsForValue().get("goods:001");
            int goodsNumber = result == null ? 0 : Integer.parseInt(result);
            String retStr = null;

            // 商品数量大于零才能出售
            if (goodsNumber > 0) {
                int realNumber = goodsNumber - 1;
                stringRedisTemplate.opsForValue().set("goods:001", realNumber + "");
                retStr = "你已经成功秒杀商品，此时还剩余：" + realNumber + "件" + "\t 服务器端口: " + serverPort;
            } else {
                retStr = "商品已经售罄/活动结束/调用超时，欢迎下次光临" + "\t 服务器端口: " + serverPort;
            }
            System.out.println(retStr);
            return retStr;
        } finally {
            // 还在持有锁的状态，并且是当前线程持有的锁再解锁
            if (redissonLock.isLocked() && redissonLock.isHeldByCurrentThread()){
                redissonLock.unlock();
            }
        }
    }
}

11、分布式锁总结

1. synchronized 锁：单机版 OK，上 nginx分布式微服务，单机锁就不 OK,
2. 分布式锁：取消单机锁，上 redis 分布式锁 SETNX
3. 如果出异常的话，可能无法释放锁， 必须要在 finally 代码块中释放锁
4. 如果宕机了，部署了微服务代码层面根本没有走到 finally 这块，也没办法保证解锁，因此需要有设置锁的过期时间
5. 除了增加过期时间之外，还必须要 SETNX 操作和设置过期时间的操作必须为原子性操作
6. 规定只能自己删除自己的锁，你不能把别人的锁删除了，防止张冠李戴，可使用 lua 脚本或者事务
7. 判断锁所属业务与删除锁的操作也需要是原子性操作
8. redis 集群环境下，我们自己写的也不 OK，直接上 RedLock 之 Redisson 落地实现

3、Redis 删除策略与缓存淘汰策略

1、Redis 缓存淘汰策略相关的面试题

1. 生产上你们的redis内存设置多少？
2. 如何配置、修改redis的内存大小？
3. 如果内存满了你怎么办？
4. redis 清理内存的方式？定期删除和惰性删除了解过吗
5. redis 的缓存淘汰策略
6. redis 的 LRU 淘汰机制了解过吗？可否手写一个 LRU 算法

2、redis 内存满了怎么办

redis 默认内存多少？在哪里查看? 如何设置修改?

1、如何查看 redis 最大占用内存

在 redis.conf 配置文件中有一个，输入 :set nu 显示行号，大约在 859 多行有一个 maxmemory 字段，用预设值 redis 的最大占用内存

2、redis 会占用物理机器多少内存？

如果不设置最大内存大小或者设置最大内存大小为 0，在 64 位操作系统下不限制内存大小，在32位操作系统下最多使用 3GB 内存

3、一般生产上如何配置 redis 的内存

一般推荐Redis设置内存为最大物理内存的四分之三，也就是 0.75

4、如何修改 redis 内存设置

1、通过修改文件配置（永久生效）：修改 maxmemory 字段，单位为字节

2、通过命令修改（重启失效）：config set maxmemory 104857600 设置 redis 最大占用内存为 100MB，config get maxmemory 获取 redis 最大占用内存

5、通过命令查看 redis 内存使用情况?

通过 info 指令info memory可以查看 redis 内存使用情况：used_memory_human 表示实际已经占用的内存，maxmemory 表示 redis 最大占用内存

6、如果把 redis 内存打满了会发生什么? 如果 redis 内存使用超出了设置的最大值会怎样?

redis 将会报错：(error) OOM command not allowed when used memory > ‘maxmemory’

如果设置了 maxmemory 的选项，假如 redis 内存使用达到上限，并且 key 都没有加上过期时间，就会导致数据写爆 redis 内存。为了避免类似情况，于是引出下一部分的内存淘汰策略

3、redis 删除策略

redis 如何删除设置了过期时间的 key

1、redis过期键的删除策略

如果一个键是过期的，那它到了过期时间之后是不是马上就从内存中被被删除呢？那么过期后到底什么时候被删除呢？redis 如何操作的呢

通过查看 redis 配置文件可知，默认淘汰策略是【noeviction（Don’t evict anything, just return an error on write operations.）】，如果 redis 内存被写爆了，直接返回 error

redis 对于过期 key 的三种不同删除策略：

1. 立即删除
   • 立即删除能保证内存中数据的最大新鲜度，因为它保证过期键值会在过期后马上被删除，其所占用的内存也会随之释放。但是立即删除对 CPU 是最不友好的。因为删除操作会占用 CPU 的时间，如果刚好碰上了 CPU 很忙的时候，比如正在做交集或排序等计算的时候，就会给 CPU 造成额外的压力，让 CPU 心累，时时需要删除，忙死
   • 这会产生大量的性能消耗，同时也会影响数据的读取操作。
   • 总结：定时删除对 CPU 不友好，但对 memory 友好，用处理器性能换取存储空间（拿时间换空间）
2. 惰性删除
   • 惰性删除的策略刚好和定时删除相反，惰性删除在数据到达过期时间后不做处理，等下次访问该数据时：如果发现未过期，则返回该数据；如果发现已过期，则将其删除，并返回不存在。
   • 如果一个键已经过期并且未被访问到，那么这个键仍然保留在数据库中，那么只要这个过期键不被删除，它所占用的内存就不会释放。因此惰性删除策略的缺点是：它对内存是最不友好的。
   • 在使用惰性删除策略时，如果数据库中有非常多的过期键，而这些过期键又恰好没有被访问到的话，那么它们也许永远也不会被删除（除非用户手动执行 FLUSHDB），我们甚至可以将这种情况看作是一种内存泄漏——无用的垃圾数据占用了大量的内存，而服务器却不会自己去释放它们，这对于运行状态非常依赖于内存的 redis 服务器来说，肯定不是一个好消息
   • 总结：惰性删除对 memory 不友好，但对 CPU 友好，用存储空间换取处理器性能（拿空间换时间）
3. 定期删除：（折中方案）
   • 上面两种删除策略都走极端，因此引出我们的定期删除策略。
   • 定期删除策略是前两种策略的折中：定期删除策略每隔一段时间执行一次删除过期键操作，并通过限制删除操作执行的时长和频率来减少删除操作对 CPU 时间的影响。
   • 其做法为：**==周期性轮询== redis 库中的时效性数据，采用==随机抽取==的策略，利用==过期数据占比==的方式控制删除频度。**
   • 定期删除的特点：
     • CPU 性能占用设置有峰值，检测频度可自定义设置
     • 内存压力不是很大，长期占用内存的冷数据会被持续清理
   • 总结：周期性抽查存储空间（随机抽查，重点抽查)
   • 定期删除的举例：
     • redis 默认每间隔 100ms 检查是否有过期的 key，如果有过期 key 则删除。
     • 注意：redis 不是每隔100ms 将所有的 key 检查一次而是随机抽取进行检查（如果每隔 100ms，全部 key 进行检查，redis 直接进去ICU）。因此，如果只采用定期删除策略，会导致很多 key 到时间没有删除。
   • 定期删除的难点：
     • 定期删除策略的难点是确定删除操作执行的时长和频率：redis 不可能时时刻刻遍历所有被设置了生存时间的 key，来检测数据是否已经到达过期时间，然后对它进行删除。
     • 如果删除操作执行得太频繁，或者执行的时间太长，定期删除策略就会退化成定时删除策略，以至于将 CPU 时间过多地消耗在删除过期键上面。
     • 如果删除操作执行得太少，或者执行的时间太短，定期删除策略又会和惰性删除束略一样，出现浪费内存的情况。
     • 因此，如果采用定期删除策略的话，服务器必须根据情况，合理地设置删除操作的执行时长和执行频率。

总结：

惰性删除和定期删除都存在数据没有被抽到的情况，如果这些数据已经到了过期时间，没有任何作用，这会导致大量过期的 key 堆积在内存中，导致 redis 内存空间紧张或者很快耗尽

因此必须要有一个更好的兜底方案，接下来引出 redis 内存淘汰策略

4、Redis的缓存淘汰策略

redis 6.0.8 版本的内存淘汰策略有哪些？：

8 种内存淘汰策略

• noeviction：不会驱逐任何key
• allkeys-lru：对所有key使用LRU算法进行删除
• volatile-lru：对所有设置了过期时间的key使用LRU算法进行删除
• allkeys-random：对所有key随机删除
• volatile-random：对所有设置了过期时间的key随机删除
• volatile-ttl：删除马上要过期的key
• allkeys-lfu：对所有key使用LFU算法进行删除
• volatile-lfu：对所有设置了过期时间的key使用LFU算法进行删除

总结:

• 2个维度
  1. 过期键中筛选
  2. 所有键中筛选
• 4个方面
  1. lru
  2. lfu
  3. random
  4. ttl、noeviction

如何配置 redis 的内存淘汰策略：

1、通过修改文件配置（永久生效）：配置 maxmemory-policy 字段：

通过命令修改（重启失效）：config set maxmemory-policy allkeys-lru 命令设置内存淘汰策略，config get maxmemory-policy 命令获取当前采用的内存淘汰策略

5、redis LRU 算法

1、LRU 算法简介

LRU 是 Least Recently Used 的缩写，即最近最少使用，是一种常用的页面置换算法，每次选择最近最久未使用的页面予以淘汰

2、LRU 算法题来源

146. LRU 缓存机制

运用你所掌握的数据结构，设计和实现一个 LRU (最近最少使用) 缓存机制 。

实现 LRUCache 类：

1. LRUCache(int capacity)：以正整数作为容量 capacity 初始化 LRU 缓存
2. int get(int key)：如果关键字 key 存在于缓存中，则返回关键字的值，否则返回 -1 。
3. void put(int key, int value)：如果关键字已经存在，则变更其数据值；如果关键字不存在，则插入该组「关键字-值」。当缓存容量达到上限时，它应该在写入新数据之前删除最久未使用的数据值，从而为新的数据值留出空间.

进阶：你是否可以在 O(1) 时间复杂度内完成这两种操作？

示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

输入
["LRUCache", "put", "put", "get", "put", "get", "put", "get", "get", "get"]
[[2], [1, 1], [2, 2], [1], [3, 3], [2], [4, 4], [1], [3], [4]]
输出
[null, null, null, 1, null, -1, null, -1, 3, 4]

解释
LRUCache lRUCache = new LRUCache(2);
lRUCache.put(1, 1); // 缓存是 {1=1}
lRUCache.put(2, 2); // 缓存是 {1=1, 2=2}
lRUCache.get(1);    // 返回 1
lRUCache.put(3, 3); // 该操作会使得关键字 2 作废，缓存是 {1=1, 3=3}
lRUCache.get(2);    // 返回 -1 (未找到)
lRUCache.put(4, 4); // 该操作会使得关键字 1 作废，缓存是 {4=4, 3=3}
lRUCache.get(1);    // 返回 -1 (未找到)
lRUCache.get(3);    // 返回 3
lRUCache.get(4);    // 返回 4

3、LRU 算法设计思想

查找和插入的时间复杂度为 O(1)，HashMap 没得跑了，但是 HashMap 是无序的集合，怎么样将其改造为有序集合呢？答案就是在各个 Node 节点之间增加 prev 指针和 next 指针，构成双向链表。即：HashMap + 双向链表

LRU 的算法核心是哈希链表，本质就是 HashMap+DoubleLinkedList 时间复杂度是O(1)，哈希表+双向链表的结合体，下面这幅动图完美诠释了 HashMap+DoubleLinkedList 的工作原理：

4、LRU 算法编码实现

1、**借助 JDK 自带的 LinkedHashMap**：

LinkedHashMap 的注释中写明了： LinkedHashMap 非常适合用来构建 LRU 缓存

LRU 代码：

通过继承 LinkedHashMap，重写 boolean removeEldestEntry(Map.Entry<K, V> eldest) 方法就行了

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

public class LRUCacheDemo<K, V> extends LinkedHashMap<K, V> {

    // 缓存容量
    private int capacity;

    public LRUCacheDemo(int capacity) {
        // accessOrder：the ordering mode. true for access-order；false for insertion-order
        super(capacity, 0.75F, true);
        this.capacity = capacity;
    }

    // 用于判断是否需要删除最近最久未使用的节点
    @Override
    protected boolean removeEldestEntry(Map.Entry<K, V> eldest) {
        return super.size() > capacity;
    }

    public static void main(String[] args) {
        LRUCacheDemo lruCacheDemo = new LRUCacheDemo(3);

        lruCacheDemo.put(1, "a");
        lruCacheDemo.put(2, "b");
        lruCacheDemo.put(3, "c");
        System.out.println(lruCacheDemo.keySet());

        lruCacheDemo.put(4, "d");
        System.out.println(lruCacheDemo.keySet());

        lruCacheDemo.put(3, "c");
        System.out.println(lruCacheDemo.keySet());
        lruCacheDemo.put(3, "c");
        System.out.println(lruCacheDemo.keySet());
        lruCacheDemo.put(3, "c");
        System.out.println(lruCacheDemo.keySet());
        lruCacheDemo.put(5, "x");
        System.out.println(lruCacheDemo.keySet());
    }
}

为何要重写 boolean removeEldestEntry(Map.Entry<K, V> eldest) 方法：

先来看看 LinkedHashMap 中的 boolean removeEldestEntry(Map.Entry<K, V> eldest) 方法，直接 return false，缓存爆就爆，反正就是不会删除 EldestEntry

1
2
3
4
5
6
7
8
9
10
11

/**
 * Returns <tt>true</tt> if this map should remove its eldest entry.
 * This method is invoked by <tt>put</tt> and <tt>putAll</tt> after
 * inserting a new entry into the map.  It provides the implementor
 * with the opportunity to remove the eldest entry each time a new one
 * is added.  This is useful if the map represents a cache: it allows
 * the map to reduce memory consumption by deleting stale entries.
 */
protected boolean removeEldestEntry(Map.Entry<K,V> eldest) {
    return false;
}

boolean removeEldestEntry(Map.Entry<K, V> eldest) 方法在 void afterNodeInsertion(boolean evict) 方法中被调用，只有当 boolean removeEldestEntry(Map.Entry<K, V> eldest) 方法返回 true 时，才能够删除 EldestEntry

1
2
3
4
5
6
7

void afterNodeInsertion(boolean evict) { // possibly remove eldest
    LinkedHashMap.Entry<K,V> first;
    if (evict && (first = head) != null && removeEldestEntry(first)) {
        K key = first.key;
        removeNode(hash(key), key, null, false, true);
    }
}

因此我们重写之后的判断条件为：如果 LinkedHashMap 中存储的元素个数已经大于缓存容量 capacity，则返回 true，表示允许删除 EldestEntry；否则返回 false，表示无需删除 EldestEntry

1
2
3
4
5

// 用于判断是否需要删除最近最久未使用的节点
@Override
protected boolean removeEldestEntry(Map.Entry<K, V> eldest) {
    return super.size() > capacity;
}

举例说明构造函数中的 accessOrder 的含义：

构造函数中的 accessOrder 字段

在 LRUCacheDemo 的构造方法中，我们调用了 LinkedHashMap 的构造方法，其中有一个字段为 accessOrder

accessOrder = true 和 accessOrder = false 的情况：

• 当 accessOrder = true 时，每次使用 key 时（put 或者 get 时），都将 key 对应的数据移动到队尾（右边），表示最近经常使用；
• 当 accessOrder = false 时，key 的顺序为插入双向链表时的顺序

注：false可以说是一种优化，没有去移动相关节点，性能会更好一点

LinkedHashMap 的 put() 方法：

LinkedHashMap 其实没有 put() 方法，LinkedHashMap的put()方法其实就是 HashMap 的 put() 方法，我就奇了怪了，LinkedHashMap 就是 HashMap？？？其实并不是。。。一起来看一下HashMap的putVal()方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

/**
 * Implements Map.put and related methods
 *
 * @param hash hash for key
 * @param key the key
 * @param value the value to put
 * @param onlyIfAbsent if true, don't change existing value
 * @param evict if false, the table is in creation mode.
 * @return previous value, or null if none
 */
final V putVal(int hash, K key, V value, boolean onlyIfAbsent,
               boolean evict) {
    Node<K,V>[] tab; Node<K,V> p; int n, i;
    if ((tab = table) == null || (n = tab.length) == 0)
        n = (tab = resize()).length;
    if ((p = tab[i = (n - 1) & hash]) == null)
        tab[i] = newNode(hash, key, value, null);
    else {
        Node<K,V> e; K k;
        if (p.hash == hash &&
            ((k = p.key) == key || (key != null && key.equals(k))))
            e = p;
        else if (p instanceof TreeNode)
            e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);
        else {
            for (int binCount = 0; ; ++binCount) {
                if ((e = p.next) == null) {
                    p.next = newNode(hash, key, value, null);
                    if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st
                        treeifyBin(tab, hash);
                    break;
                }
                if (e.hash == hash &&
                    ((k = e.key) == key || (key != null && key.equals(k))))
                    break;
                p = e;
            }
        }
        if (e != null) { // existing mapping for key
            V oldValue = e.value;
            if (!onlyIfAbsent || oldValue == null)
                e.value = value;
            afterNodeAccess(e);
            return oldValue;
        }
    }
    ++modCount;
    if (++size > threshold)
        resize();
    afterNodeInsertion(evict);
    return null;
}

在 putval() 方法的调用了两个方法：afterNodeAccess(e) 方法和 afterNodeInsertion(evict) 方法，这两个方法就是专门针对于 LinkedHashMap 写的方法：在 HashMap 中这些方法均为空实现的方法，没有任何代码逻辑，需要推迟到子类 LinkedHashMap 中去实现，就是模板方法设计模式

1
2
3
4

// Callbacks to allow LinkedHashMap post-actions
void afterNodeAccess(Node<K,V> p) { }
void afterNodeInsertion(boolean evict) { }
void afterNodeRemoval(Node<K,V> p) { }

注释也写了：Callbacks to allow LinkedHashMap post-actions

在 LinkedHashMap 的 void afterNodeAccess(Node<K,V> e) 方法中：如果设置了 accessOrder = true 时，则每次使用 key 时（put 或者 get 时），都将 key 对应的数据移动到队尾（右边），表示这是最近经常使用的节点

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

void afterNodeAccess(Node<K,V> e) { // move node to last
    LinkedHashMap.Entry<K,V> last;
    //  accessOrder如果设置为true，进入if块
    if (accessOrder && (last = tail) != e) {
        LinkedHashMap.Entry<K,V> p =
            (LinkedHashMap.Entry<K,V>)e, b = p.before, a = p.after;
        p.after = null;
        if (b == null)
            head = a;
        else
            b.after = a;
        if (a != null)
            a.before = b;
        else
            last = b;
        if (last == null)
            head = p;
        else {
            p.before = last;
            last.after = p;
        }
        tail = p;
        ++modCount;
    }
}

在 LinkedHashMap 的 void afterNodeInsertion(boolean evict) 方法中：如果头指针不为空并且当前需要删除老节点，则执行 removeNode(hash(key), key, null, false, true) 方法删除 EldestEntry（若 accessOrder = true 时，EldestEntry 表示最近最少使用的数据，若 accessOrder = false 时，EldestEntry 表示最先插入链表的节点）

1
2
3
4
5
6
7

void afterNodeInsertion(boolean evict) { // possibly remove eldest
    LinkedHashMap.Entry<K,V> first;
    if (evict && (first = head) != null && removeEldestEntry(first)) {
        K key = first.key;
        removeNode(hash(key), key, null, false, true);
    }
}

LinkedHashMap 的 get() 方法：

在 LinkedHashMap 的 get() 方法中：若 accessOrder = true 时，则每次 get(key) 之后都会将 key 对应的数据移动至双向链表的尾部：

1
2
3
4
5
6
7
8

public V get(Object key) {
    Node<K,V> e;
    if ((e = getNode(hash(key), key)) == null)
        return null;
    if (accessOrder)
        afterNodeAccess(e);
    return e.value;
}

LinkedHashMap 中如何构造双向链表？

Entry<K,V> 继承了 HashMap.Node<K,V>，并且有 Entry<K,V> before, after; 两个字段，这不就是双线链表的标配嘛

1
2
3
4
5
6
7
8
9

/**
 * HashMap.Node subclass for normal LinkedHashMap entries.
 */
static class Entry<K,V> extends HashMap.Node<K,V> {
    Entry<K,V> before, after;
    Entry(int hash, K key, V value, Node<K,V> next) {
        super(hash, key, value, next);
    }
}

在 LinkedHashMap 中定义了 head 和 tail ，分别指向双向链表的头部和尾部，人家注释中也说了，**head 用于指向双向链表中最老的节点，tail 用于指向最年轻的节点，至于最老和最年轻的定义，就得看 accessOrder 字段的值了：如果 accessOrder = false，那么最老的节点就是最久没有被使用过的节点，最年轻的节点就是最近被刚被使用过的节点；如果 accessOrder = true，那么最老的节点就是链表头部的节点，最年轻的节点就是链表尾部的节点**

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

/**
 * The head (eldest) of the doubly linked list.
 */
transient LinkedHashMap.Entry<K,V> head;

/**
 * The tail (youngest) of the doubly linked list.
 */
transient LinkedHashMap.Entry<K,V> tail;

/**
 * The iteration ordering method for this linked hash map: <tt>true</tt>
 * for access-order, <tt>false</tt> for insertion-order.
 *
 * @serial
 */
final boolean accessOrder;

2、完全自己手写

1. 依葫芦画瓢，先定义 Node 类作为数据的承载体

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

   // 1.构造一个node节点作为数据载体 class Node<K, V> { K key; V value; Node<K, V> prev; Node<K, V> next; public Node() { this.prev = this.next = null; } public Node(K key, V value) { this.key = key; this.value = value; this.prev = this.next = null; } }

2. 定义双向链表，里面存放的就是 Node 对象，Node 节点之间通过 prev 和 next 指针连接起来

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

   // 2.构建一个虚拟的双向链表,,里面存放的就是我们的Node class DoubleLinkedList<K, V> { Node<K, V> head; Node<K, V> tail; public DoubleLinkedList() { head = new Node<>(); tail = new Node<>(); head.next = tail; tail.prev = head; } // 3.添加到头（头插法） public void addHead(Node<K, V> node) { node.next = head.next; node.prev = head; head.next.prev = node; head.next = node; } // 4.删除节点 public void removeNode(Node<K, V> node) { node.next.prev = node.prev; node.prev.next = node.next; node.prev = null; node.next = null; } // 5.获得最后一个节点 public Node getLast() { return tail.prev; } }

3. 通过 HashMap 和 DoubleLinkedList 构建 LinkedHashMap，我们这里可是将最近最常使用的节点放在了双向链表的头部（和 LinkedHashMap 不同哦）

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

   private int cacheSize; Map<Integer, Node<Integer, Integer>> map; DoubleLinkedList<Integer, Integer> doubleLinkedList; public LRUCacheDemo(int cacheSize) { this.cacheSize = cacheSize;//坑位 map = new HashMap<>();//查找 doubleLinkedList = new DoubleLinkedList<>(); } public int get(int key) { if (!map.containsKey(key)) { return -1; } Node<Integer, Integer> node = map.get(key); doubleLinkedList.removeNode(node); doubleLinkedList.addHead(node); return node.value; } public void put(int key, int value) { if (map.containsKey(key)) { //update Node<Integer, Integer> node = map.get(key); node.value = value; map.put(key, node); doubleLinkedList.removeNode(node); doubleLinkedList.addHead(node); } else { if (map.size() == cacheSize) //坑位满了 { Node<Integer, Integer> lastNode = doubleLinkedList.getLast(); map.remove(lastNode.key); doubleLinkedList.removeNode(lastNode); } //新增一个 Node<Integer, Integer> newNode = new Node<>(key, value); map.put(key, newNode); doubleLinkedList.addHead(newNode); } }

4. 测试 LRUCacheDemo

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

   public static void main(String[] args) { LRUCacheDemo lruCacheDemo = new LRUCacheDemo(3); lruCacheDemo.put(1, 1); lruCacheDemo.put(2, 2); lruCacheDemo.put(3, 3); System.out.println(lruCacheDemo.map.keySet()); lruCacheDemo.put(4, 1); System.out.println(lruCacheDemo.map.keySet()); lruCacheDemo.put(3, 1); System.out.println(lruCacheDemo.map.keySet()); lruCacheDemo.put(3, 1); System.out.println(lruCacheDemo.map.keySet()); lruCacheDemo.put(3, 1); System.out.println(lruCacheDemo.map.keySet()); lruCacheDemo.put(5, 1); System.out.println(lruCacheDemo.map.keySet()); }

5. 测试结果：我们实现的是accessOrder = false最近最少使用的数据已经被删除了