# Java #### 1. 什么是字节码，采取字节码的好处是什么 JVM 可以理解的代码就叫做字节码（即扩展名为 `.class` 的文件），它不面向任何特定的处理器，只面向虚拟机。 由于字节码并不针对一种特定的机器，因此，Java 程序无须重新编译便可在多种不同操作系统的计算机上运行。 #### 2. 为什么说 Java 编译与解释并存 * 编译型：编译型语言会通过编译器将源代码一次性翻译成可被该平台执行的机器码。一般情况下，编译语言的执行速度比较快，开发效率比较低。常见的编译性语言有 C、C++、Go、Rust 等等。 * 解释型：解释型语言会通过解释器一句一句的将代码解释（interpret）为机器代码后再执行。解释型语言开发效率比较快，执行速度比较慢。常见的解释性语言有 Python、JavaScript、PHP 等等。 Java 语言既具有编译型语言的特征，也具有解释型语言的特征。因为 Java 程序要经过先编译，后解释两个步骤，由 Java 编写的程序需要先经过编译步骤，生成字节码（`.class` 文件），这种字节码必须由 Java 解释器来解释执行。 #### 3. AOT 有什么优点，为什么不全部使用 AOT 和 JIT 不同的是，这种编译模式会在程序被执行前就将其编译成机器码，属于静态编译。AOT 避免了 JIT 预热等各方面的开销，可以提高 Java 程序的启动速度，避免预热时间长。并且，AOT 还能减少内存占用和增强 Java 程序的安全性（AOT 编译后的代码不容易被反编译和修改）。 JIT 与 AOT，两者各有优点，只能说 AOT 更适合当下的云原生场景，对微服务架构的支持也比较友好。除此之外，AOT 编译无法支持 Java 的一些动态特性，如反射、动态代理、动态加载、JNI（Java Native Interface）等。然而，很多框架和库（如 Spring、CGLIB）都用到了这些特性。 #### 4. Java 和 C++ 的区别 Java 和 C++ 都是面向对象的语言，都支持封装、继承和多态 * Java 不提供指针来直接访问内存，程序内存更加安全 * Java 的类是单继承的，C++ 支持多重继承；虽然 Java 的类不可以多继承，但是接口可以多继承。 * Java 有自动内存管理垃圾回收机制 (GC)，不需要程序员手动释放无用内存。 * C ++ 同时支持方法重载和操作符重载，但是 Java 只支持方法重载（操作符重载增加了复杂性，这与 Java 最初的设计思想不符）。 #### 5. 基本类型与包装类型的存储方式 基本数据类型的局部变量存放在 Java 虚拟机栈中的局部变量表中，基本数据类型的成员变量（未被 `static` 修饰 ）存放在 Java 虚拟机的堆中。包装类型属于对象类型，我们知道几乎所有对象实例都存在于堆中。HotSpot 虚拟机引入了 JIT 优化之后，会对对象进行逃逸分析，如果发现某一个对象并没有逃逸到方法外部，那么就可能通过标量替换来实现栈上分配，而避免堆上分配内存 > **基本数据类型存放在栈中是一个常见的误区！** 基本数据类型的存储位置取决于它们的作用域和声明方式。如果它们是局部变量，那么它们会存放在栈中；如果它们是成员变量，那么它们会存放在堆中。 #### 6. 包装类型的缓存机制 Java 基本数据类型的包装类型的大部分都用到了缓存机制来提升性能。 `Byte`,`Short`,`Integer`,`Long` 这 4 种包装类默认创建了数值 **\[-128，127]** 的相应类型的缓存数据，`Character` 创建了数值在 **\[0,127]** 范围的缓存数据，`Boolean` 直接返回 `True` or `False`。 如果超出对应范围仍然会去创建新的对象，缓存的范围区间的大小只是在性能和资源之间的权衡。 两种浮点数类型的包装类 `Float`,`Double` 并没有实现缓存机制。 ```java Integer i1 = 33; Integer i2 = 33; System.out.println(i1 == i2);// 输出 true Float i11 = 333f; Float i22 = 333f; System.out.println(i11 == i22);// 输出 false Double i3 = 1.2; Double i4 = 1.2; System.out.println(i3 == i4);// 输出 false ``` **所有整型包装类对象之间值的比较，全部使用 equals 方法比较**。 #### 7. 自动装箱与拆箱 * **装箱**：将基本类型用它们对应的引用类型包装起来； * **拆箱**：将包装类型转换为基本数据类型； ```java Integer i = 10; //装箱 int n = i; //拆箱 ``` 从字节码中，我们发现装箱其实就是调用了 包装类的 `valueOf()` 方法，拆箱其实就是调用了 `xxxValue()` 方法。 因此， * `Integer i = 10` 等价于 `Integer i = Integer.valueOf(10)` * `int n = i` 等价于 `int n = i.intValue()`; **如果频繁拆装箱的话，也会严重影响系统的性能。我们应该尽量避免不必要的拆装箱操作。** #### 8. 如何解决浮点数运算的精度丢失问题 `BigDecimal` 可以实现对浮点数的运算，不会造成精度丢失。通常情况下，大部分需要浮点数精确运算结果的业务场景（比如涉及到钱的场景）都是通过 `BigDecimal` 来做的。 ```java BigDecimal a = new BigDecimal("1.0"); BigDecimal b = new BigDecimal("0.9"); BigDecimal c = new BigDecimal("0.8"); BigDecimal x = a.subtract(b); BigDecimal y = b.subtract(c); System.out.println(x); /* 0.1 */ System.out.println(y); /* 0.1 */ System.out.println(Objects.equals(x, y)); /* true */ ``` #### 9. 超过 long 的数据应该怎么表示 基本数值类型都有一个表达范围，如果超过这个范围就会有数值溢出的风险。 在 Java 中，64 位 long 整型是最大的整数类型。 ```java long l = Long.MAX_VALUE; System.out.println(l + 1); // -9223372036854775808 System.out.println(l + 1 == Long.MIN_VALUE); // true ``` `BigInteger` 内部使用 `int[]` 数组来存储任意大小的整形数据。 相对于常规整数类型的运算来说，`BigInteger` 运算的效率会相对较低。 #### 10. 静态变量有什么用 静态变量也就是被 `static` 关键字修饰的变量。它可以被类的所有实例共享，无论一个类创建了多少个对象，它们都共享同一份静态变量。也就是说，静态变量只会被分配一次内存，即使创建多个对象，这样可以节省内存。 #### 11. 静态方法为什么不能调用非静态成员 * 静态方法是属于类的，在类加载的时候就会分配内存，可以通过类名直接访问。而非静态成员属于实例对象，只有在对象实例化之后才存在，需要通过类的实例对象去访问。 * 在类的非静态成员不存在的时候静态方法就已经存在了，此时调用在内存中还不存在的非静态成员，属于非法操作。 #### 12. 静态方法和实例方法有什么不同 在外部调用静态方法时，可以使用 `类名.方法名` 的方式，也可以使用 `对象.方法名` 的方式，而实例方法只有后面这种方式。也就是说，**调用静态方法可以无需创建对象** 。一般建议使用 `类名.方法名` 的方式来调用静态方法。 静态方法在访问本类的成员时，只允许访问静态成员（即静态成员变量和静态方法），不允许访问实例成员（即实例成员变量和实例方法），而实例方法不存在这个限制。 #### 13. 重载和重写有什么区别 * 重载 编译期，发生在同一个类中（或者父类和子类之间），方法名必须相同，参数类型不同、个数不同、顺序不同，方法返回值和访问修饰符可以不同。同一个类中多个同名方法根据不同的传参来执行不同的逻辑处理。 * 重写 重写发生在运行期，是子类对父类的允许访问的方法的实现过程进行重新编写。 1. 方法名、参数列表必须相同，子类方法返回值类型应比父类方法返回值类型更小或相等，抛出的异常范围小于等于父类，访问修饰符范围大于等于父类。 2. 如果父类方法访问修饰符为 `private/final/static` 则子类就不能重写该方法，但是被 `static` 修饰的方法能够被再次声明。 3. 构造方法无法被重写 #### 14. 什么是可变长参数 可变参数只能作为函数的最后一个参数，但其前面可以有也可以没有任何其他参数。 ```java public static void method2(String arg1, String... args) { //...... } ``` **遇到方法重载的情况会优先匹配固定参数的方法，因为固定参数的方法匹配度更高。** 另外，Java 的可变参数编译后实际会被转换成一个数组，我们看编译后生成的 `class` 文件就 可以看出来了。 #### 15. 对象实体与对象引用有何不同 new 创建对象实例（对象实例在堆内存中），对象引用指向对象实例（对象引用存放在栈内存中）。 * 一个对象引用可以指向 0 个或 1 个对象（一根绳子可以不系气球，也可以系一个气球）； * 一个对象可以有 n 个引用指向它（可以用 n 条绳子系住一个气球）。 * 对象的相等一般比较的是内存中存放的内容是否相等。 * 引用相等一般比较的是他们指向的内存地址是否相等。 #### 16. 构造方法的特点 * 名字与类名相同。 * 没有返回值，但不能用 void 声明构造函数。 * 生成类的对象时自动执行，无需调用。 构造方法不能被 override（重写）,但是可以 overload（重载）,所以你可以看到一个类中有多个构造函数的情况。 #### 17. Java 深浅拷贝 * **浅拷贝**：浅拷贝会在堆上创建一个新的对象（区别于引用拷贝的一点），不过，如果原对象内部的属性是引用类型的话，浅拷贝会直接复制内部对象的引用地址，也就是说拷贝对象和原对象共用同一个内部对象。 * **深拷贝**：深拷贝会完全复制整个对象，包括这个对象所包含的内部对象。 **那什么是引用拷贝呢？** 简单来说，引用拷贝就是两个不同的引用指向同一个对象。 #### 18. hashcode 有什么用 `hashCode()` 的作用是获取哈希码（`int` 整数），也称为散列码。这个哈希码的作用是确定该对象在哈希表中的索引位置。 当你把对象加入 `HashSet` 时，`HashSet` 会先计算对象的 `hashCode` 值来判断对象加入的位置，同时也会与其他已经加入的对象的 `hashCode` 值作比较，如果没有相符的 `hashCode`，`HashSet` 会假设对象没有重复出现。但是如果发现有相同 `hashCode` 值的对象，这时会调用 `equals()` 方法来检查 `hashCode` 相等的对象是否真的相同。如果两者相同，`HashSet` 就不会让其加入操作成功。如果不同的话，就会重新散列到其他位置。这样我们就大大减少了 `equals` 的次数，相应就大大提高了执行速度。 * 如果两个对象的 `hashCode` 值相等，那这两个对象不一定相等（哈希碰撞）。 * 如果两个对象的 `hashCode` 值相等并且 `equals()` 方法也返回 `true`，我们才认为这两个对象相等。 * 如果两个对象的 `hashCode` 值不相等，我们就可以直接认为这两个对象不相等。 #### 19. 为什么重写 equals() 时必须重写 hashCode() 方法 如果重写 `equals()` 时没有重写 `hashCode()` 方法的话就可能会导致 `equals` 方法判断是相等的两个对象，`hashCode` 值却不相等。 * `equals` 方法判断两个对象是相等的，那这两个对象的 `hashCode` 值也要相等。 * 两个对象有相同的 `hashCode` 值，他们也不一定是相等的（哈希碰撞）。 #### 14. String StringBuffer StringBuilder 的区别 * 操作少量的数据: 适用 `String` * 单线程操作字符串缓冲区下操作大量数据: 适用 `StringBuilder` * 多线程操作字符串缓冲区下操作大量数据: 适用 `StringBuffer` `String` 中的对象是不可变的，也就可以理解为常量，线程安全。`AbstractStringBuilder` 是 `StringBuilder` 与 `StringBuffer` 的公共父类。`StringBuffer` 对方法加了同步锁或者对调用的方法加了同步锁，所以是线程安全的。`StringBuilder` 并没有对方法进行加同步锁，所以是非线程安全的。 #### 15. String 为什么是不可变的 * 保存字符串的数组被 `final` 修饰且为私有的，并且 `String` 类没有提供/暴露修改这个字符串的方法。 * `String` 类被 `final` 修饰导致其不能被继承，进而避免了子类破坏 `String` 不可变。 #### 16. 字符串常量池的作用 **字符串常量池** 是 JVM 为了提升性能和减少内存消耗针对字符串（String 类）专门开辟的一块区域，主要目的是为了避免字符串的重复创建。 ```java // 在堆中创建字符串对象”ab“ // 将字符串对象”ab“的引用保存在字符串常量池中 String aa = "ab"; // 直接返回字符串常量池中字符串对象”ab“的引用 String bb = "ab"; System.out.println(aa==bb);// true ``` #### 17. String s1 = new String("abc") 这行代码创建了几个字符串对象 1. 如果字符串常量池中不存在字符串对象“abc”的引用，那么它会在堆上创建两个字符串对象，其中一个字符串对象的引用会被保存在字符串常量池中。 2. 如果字符串常量池中已存在字符串对象“abc”的引用，则只会在堆中创建 1 个字符串对象“abc”。 #### 18. 编译器常量折叠 常量折叠会把常量表达式的值求出来作为常量嵌在最终生成的代码中，这是 Javac 编译器会对源代码做的极少量优化措施之一 (代码优化几乎都在即时编译器中进行)。 对于 `String str3 = "str" + "ing";` 编译器会给你优化成 `String str3 = "string";` 。 并不是所有的常量都会进行折叠，只有编译器在程序编译期就可以确定值的常量才可以： * 基本数据类型 ( `byte`、`boolean`、`short`、`char`、`int`、`float`、`long`、`double`) 以及字符串常量。 * `final` 修饰的基本数据类型和字符串变量 * 字符串通过 “+”拼接得到的字符串、基本数据类型之间算数运算（加减乘除）、基本数据类型的位运算（<<、>>、>>> ） #### 19. Exception 和 Error 有什么区别 * **`Exception`** : 程序本身可以处理的异常，可以通过 `catch` 来进行捕获。`Exception` 又可以分为 Checked Exception (受检查异常，必须处理) 和 Unchecked Exception (不受检查异常，可以不处理)。 * **`Error`**：`Error` 属于程序无法处理的错误 ，不建议通过 `catch` 捕获 。例如 Java 虚拟机运行错误（`Virtual MachineError`）、虚拟机内存不够错误 (`OutOfMemoryError`)、类定义错误（`NoClassDefFoundError`）等 。这些异常发生时，Java 虚拟机（JVM）一般会选择线程终止。 #### 20. finally 中的代码一定会执行吗 不一定，在某些情况下，finally 中的代码不会被执行。 * finally 之前虚拟机被终止运行 * 程序所在的线程死亡。 * 关闭 CPU #### 21. 如何使用 `try-with-resources` 代替 `try-catch-finally`？ * **适用范围（资源的定义）：** 任何实现 `java.lang.AutoCloseable` 或者 `java.io.Closeable` 的对象 * **关闭资源和 finally 块的执行顺序：** 在 `try-with-resources` 语句中，任何 catch 或 finally 块在声明的资源关闭后运行 #### 22. 注解的解析方法有哪几种 * **编译期直接扫描**：编译器在编译 Java 代码的时候扫描对应的注解并处理，比如某个方法使用 `@Override` 注解，编译器在编译的时候就会检测当前的方法是否重写了父类对应的方法。 * **运行期通过反射处理**：像框架中自带的注解 (比如 Spring 框架的 `@Value`、`@Component`) 都是通过反射来进行处理的。 #### 23. Java 序列化常见协议 * **序列化**：将数据结构或对象转换成二进制字节流的过程 * **反序列化**：将在序列化过程中所生成的二进制字节流转换成数据结构或者对象的过程 **序列化的主要目的是通过网络传输对象或者说是将对象存储到文件系统、数据库、内存中。** JDK 自带的序列化方式一般不会用 ，因为序列化效率低并且存在安全问题。比较常用的序列化协议有 Hessian、Kryo、Protobuf、ProtoStuff，这些都是基于二进制的序列化协议。 #### 24. serialVersionUID 有什么作用 序列化号 `serialVersionUID` 属于版本控制的作用。反序列化时，会检查 `serialVersionUID` 是否和当前类的 `serialVersionUID` 一致。如果 `serialVersionUID` 不一致则会抛出 `InvalidClassException` 异常。 `static` 修饰的变量是静态变量，属于类而非类的实例，本身是不会被序列化的。然而，`serialVersionUID` 是一个特例。当一个对象被序列化时，`serialVersionUID` 会被写入到序列化的二进制流中。也就是说，`serialVersionUID` 只是用来被 JVM 识别，实际并没有被序列化。 #### 25. 有些字段不想进行序列化怎么办 对于不想进行序列化的变量，可以使用 `transient` 关键字修饰。 `transient` 关键字的作用是：阻止实例中那些用此关键字修饰的的变量序列化；当对象被反序列化时，被 `transient` 修饰的变量值不会被持久化和恢复。 关于 `transient` 还有几点注意： * `transient` 只能修饰变量，不能修饰类和方法。 * `transient` 修饰的变量，在反序列化后变量值将会被置成类型的默认值。例如，如果是修饰 `int` 类型，那么反序列后结果就是 `0`。 * `static` 变量因为不属于任何对象 (Object)，所以无论有没有 `transient` 关键字修饰，均不会被序列化。 #### 26. 为什么不推荐使用 JDK 自带的序列化 * **不支持跨语言调用** : 如果调用的是其他语言开发的服务的时候就不支持了。 * **性能差**：相比于其他序列化框架性能更低，主要原因是序列化之后的字节数组体积较大，导致传输成本加大。 * **存在安全问题**：序列化和反序列化本身并不存在问题。但当输入的反序列化的数据可被用户控制，那么攻击者即可通过构造恶意输入，让反序列化产生非预期的对象，在此过程中执行构造的任意代码 #### 27. 反射的优缺点 **优点**：可以让咱们的代码更加灵活、为各种框架提供开箱即用的功能提供了便利 **缺点**：让我们在运行时有了分析操作类的能力，这同样也增加了安全问题。比如可以无视泛型参数的安全检查（泛型参数的安全检查发生在编译时）。另外，反射的性能也要稍差点，不过，对于框架来说实际是影响不大的。 #### 28. 什么是代理模式 我们使用代理对象来代替对真实对象 (real object) 的访问，这样就可以在不修改原目标对象的前提下，提供额外的功能操作，扩展目标对象的功能。 代理模式的主要作用是扩展目标对象的功能，比如说在目标对象的某个方法执行前后你可以增加一些自定义的操作。 #### 29. 静态代理 静态代理中，我们对目标对象的每个方法的增强都是手动完成的，非常不灵活（比如接口一旦新增加方法，目标对象和代理对象都要进行修改）。 实际应用场景非常非常少，日常开发几乎看不到使用静态代理的场景。 上面我们是从实现和应用角度来说的静态代理，从 JVM 层面来说， **静态代理在编译时就将接口、实现类、代理类这些都变成了一个个实际的 class 文件。** 静态代理实现步骤: 1. 定义一个接口及其实现类； 2. 创建一个代理类同样实现这个接口 3. 将目标对象注入进代理类，然后在代理类的对应方法调用目标类中的对应方法。这样的话，我们就可以通过代理类屏蔽对目标对象的访问，并且可以在目标方法执行前后做一些自己想做的事情。 #### 30. 动态代理 相比于静态代理来说，动态代理更加灵活。我们不需要针对每个目标类都单独创建一个代理类，并且也不需要我们必须实现接口，我们可以直接代理实现类 ( *CGLIB 动态代理机制*)。 就 Java 来说，动态代理的实现方式有很多种，比如 **JDK 动态代理**、**CGLIB 动态代理**等等。 #### 31. JDK 动态代理机制 **在 Java 动态代理机制中 `InvocationHandler` 接口和 `Proxy` 类是核心。** `Proxy` 类中使用频率最高的方法是：`newProxyInstance()` ，这个方法主要用来生成一个代理对象。 ```java public static Object newProxyInstance(ClassLoader loader, Class[] interfaces, InvocationHandler h) throws IllegalArgumentException { ...... } // 1. loader :类加载器，用于加载代理对象。 // 2. interfaces : 被代理类实现的一些接口； // 3. h : 实现了 `InvocationHandler` 接口的对象； ``` 要实现动态代理的话，还必须需要实现 `InvocationHandler` 来自定义处理逻辑。 当我们的动态代理对象调用一个方法时，这个方法的调用就会被转发到实现 `InvocationHandler` 接口类的 `invoke` 方法来调用。 也就是说：**你通过 `Proxy` 类的 `newProxyInstance()` 创建的代理对象在调用方法的时候，实际会调用到实现 `InvocationHandler` 接口的类的 `invoke()` 方法。** 你可以在 `invoke()` 方法中自定义处理逻辑，比如在方法执行前后做什么事情。 #### 32. CGLIB 动态代理机制 **JDK 动态代理有一个最致命的问题是其只能代理实现了接口的类。为了解决这个问题，我们可以用 CGLIB 动态代理机制来避免。** CGLIB 通过继承方式实现代理。Spring 中的 AOP 模块中：如果目标对象实现了接口，则默认采用 JDK 动态代理，否则采用 CGLIB 动态代理。 **在 CGLIB 动态代理机制中 `MethodInterceptor` 接口和 `Enhancer` 类是核心。** 你需要自定义 `MethodInterceptor` 并重写 `intercept` 方法，`intercept` 用于拦截增强被代理类的方法。 ```java public interface MethodInterceptor extends Callback{ // 拦截被代理类中的方法 public Object intercept(Object obj, java.lang.reflect.Method method, Object[] args,MethodProxy proxy) throws Throwable; } ``` 1. **obj** : 被代理的对象（需要增强的对象） 2. **method** : 被拦截的方法（需要增强的方法） 3. **args** : 方法入参 4. **proxy** : 用于调用原始方法 你可以通过 `Enhancer` 类来动态获取被代理类，当代理类调用方法的时候，实际调用的是 `MethodInterceptor` 中的 `intercept` 方法。 #### 33. JDK 动态代理和 CGLIB 动态代理对比 * **JDK 动态代理只能代理实现了接口的类或者直接代理接口，而 CGLIB 可以代理未实现任何接口的类。** 另外， CGLIB 动态代理是通过生成一个被代理类的子类来拦截被代理类的方法调用，因此不能代理声明为 final 类型的类和方法。 * 就二者的效率来说，大部分情况都是 JDK 动态代理更优秀，随着 JDK 版本的升级，这个优势更加明显。 #### 34. 静态代理和动态代理的对比 * **灵活性**：动态代理更加灵活，不需要必须实现接口，可以直接代理实现类，并且可以不需要针对每个目标类都创建一个代理类。另外，静态代理中，接口一旦新增加方法，目标对象和代理对象都要进行修改，这是非常麻烦的！ * **JVM 层面**：静态代理在编译时就将接口、实现类、代理类这些都变成了一个个实际的 class 文件。而动态代理是在运行时动态生成类字节码，并加载到 JVM 中的。 #### 35. Unsafe 的使用注意 **为什么 `public static` 方法无法被直接调用呢？** 这是因为在 `getUnsafe` 方法中，会对调用者的 `classLoader` 进行检查，判断当前类是否由 `Bootstrap classLoader` 加载，如果不是的话那么就会抛出一个 `SecurityException` 异常。也就是说，只有启动类加载器加载的类才能够调用 Unsafe 类中的方法，来防止这些方法在不可信的代码中被调用。 **为什么要对 Unsafe 类进行这么谨慎的使用限制呢?** `Unsafe` 提供的功能过于底层（如直接访问系统内存资源、自主管理内存资源等），安全隐患也比较大，使用不当的话，很容易出现很严重的问题。 #### 36. 为什么 Unsafe 分配内存使用堆外内存 * 对垃圾回收停顿的改善。由于堆外内存是直接受操作系统管理而不是 JVM，所以当我们使用堆外内存时，即可保持较小的堆内内存规模。从而在 GC 时减少回收停顿对于应用的影响。 * 提升程序 I/O 操作的性能。通常在 I/O 通信过程中，会存在堆内内存到堆外内存的数据拷贝操作，对于需要频繁进行内存间数据拷贝且生命周期较短的暂存数据，都建议存储到堆外内存。 #### 37. 集合框架底层数据结构总结 先来看一下 `Collection` 接口下面的集合。 **List** * `ArrayList`：`Object[]` 数组。 * `Vector`：`Object[]` 数组。 * `LinkedList`：双向链表 (JDK1.6 之前为循环链表，JDK1.7 取消了循环)。 **Set** * `HashSet`(无序，唯一): 基于 `HashMap` 实现的，底层采用 `HashMap` 来保存元素。 * `LinkedHashSet`: `LinkedHashSet` 是 `HashSet` 的子类，并且其内部是通过 `LinkedHashMap` 来实现的。 * `TreeSet`(有序，唯一): 红黑树 (自平衡的排序二叉树)。 **Queue** * `PriorityQueue`: `Object[]` 数组来实现小顶堆。 * `DelayQueue`:`PriorityQueue`。 * `ArrayDeque`: 可扩容动态双向数组。 再来看看 `Map` 接口下面的集合。 **Map** * `HashMap`：JDK1.8 之前 `HashMap` 由数组 + 链表组成的，数组是 `HashMap` 的主体，链表则是主要为了解决哈希冲突而存在的（“拉链法”解决冲突）。JDK1.8 以后在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为 8）（将链表转换成红黑树前会判断，如果当前数组的长度小于 64，那么会选择先进行数组扩容，而不是转换为红黑树）时，将链表转化为红黑树，以减少搜索时间。 * `LinkedHashMap`：`LinkedHashMap` 继承自 `HashMap`，所以它的底层仍然是基于拉链式散列结构即由数组和链表或红黑树组成。另外，`LinkedHashMap` 在上面结构的基础上，增加了一条双向链表，使得上面的结构可以保持键值对的插入顺序。同时通过对链表进行相应的操作，实现了访问顺序相关逻辑。 * `Hashtable`：数组 + 链表组成的，数组是 `Hashtable` 的主体，链表则是主要为了解决哈希冲突而存在的。 * `TreeMap`：红黑树（自平衡的排序二叉树）。 #### 38. 如何选用集合 我们主要根据集合的特点来选择合适的集合。比如： * 我们需要根据键值获取到元素值时就选用 `Map` 接口下的集合，需要排序时选择 `TreeMap`，不需要排序时就选择 `HashMap`，需要保证线程安全就选用 `ConcurrentHashMap`。 * 我们只需要存放元素值时，就选择实现 `Collection` 接口的集合，需要保证元素唯一时选择实现 `Set` 接口的集合比如 `TreeSet` 或 `HashSet`，不需要就选择实现 `List` 接口的比如 `ArrayList` 或 `LinkedList`，然后再根据实现这些接口的集合的特点来选用。 #### 39. ArrayList 和 Array（数组）的区别 `ArrayList` 内部基于动态数组实现，比 `Array`（静态数组） 使用起来更加灵活： * `ArrayList` 会根据实际存储的元素动态地扩容或缩容，而 `Array` 被创建之后就不能改变它的长度了。 * `ArrayList` 允许你使用泛型来确保类型安全，`Array` 则不可以。 * `ArrayList` 中只能存储对象。对于基本类型数据，需要使用其对应的包装类（如 Integer、Double 等）。`Array` 可以直接存储基本类型数据，也可以存储对象。 * `ArrayList` 支持插入、删除、遍历等常见操作，并且提供了丰富的 API 操作方法，比如 `add()`、`remove()` 等。`Array` 只是一个固定长度的数组，只能按照下标访问其中的元素，不具备动态添加、删除元素的能力。 * `ArrayList` 创建时不需要指定大小，而 `Array` 创建时必须指定大小。 #### 40. ArrayList 可以添加 null 值吗 `ArrayList` 中可以存储任何类型的对象，包括 `null` 值。不过，不建议向 `ArrayList` 中添加 `null` 值， `null` 值无意义，会让代码难以维护比如忘记做判空处理就会导致空指针异常。 #### 41. ArrayList 插入和删除元素的时间复杂度 对于插入： * 头部插入：由于需要将所有元素都依次向后移动一个位置，因此时间复杂度是 O(n)。 * 尾部插入：当 `ArrayList` 的容量未达到极限时，往列表末尾插入元素的时间复杂度是 O(1)，因为它只需要在数组末尾添加一个元素即可；当容量已达到极限并且需要扩容时，则需要执行一次 O(n) 的操作将原数组复制到新的更大的数组中，然后再执行 O(1) 的操作添加元素。 * 指定位置插入：需要将目标位置之后的所有元素都向后移动一个位置，然后再把新元素放入指定位置。这个过程需要移动平均 n/2 个元素，因此时间复杂度为 O(n)。 对于删除： * 头部删除：由于需要将所有元素依次向前移动一个位置，因此时间复杂度是 O(n)。 * 尾部删除：当删除的元素位于列表末尾时，时间复杂度为 O(1)。 * 指定位置删除：需要将目标元素之后的所有元素向前移动一个位置以填补被删除的空白位置，因此需要移动平均 n/2 个元素，时间复杂度为 O(n)。 #### 42. LinkedList 插入和删除元素的时间复杂度 * 头部插入/删除：只需要修改头结点的指针即可完成插入/删除操作，因此时间复杂度为 O(1)。 * 尾部插入/删除：只需要修改尾结点的指针即可完成插入/删除操作，因此时间复杂度为 O(1)。 * 指定位置插入/删除：需要先移动到指定位置，再修改指定节点的指针完成插入/删除，因此需要遍历平均 n/2 个元素，时间复杂度为 O(n)。 #### 43. LinkedList 为什么不能实现 RandomAccess 接口 `RandomAccess` 是一个标记接口，用来表明实现该接口的类支持随机访问（即可以通过索引快速访问元素）。由于 `LinkedList` 底层数据结构是链表，内存地址不连续，只能通过指针来定位，不支持随机快速访问，所以不能实现 `RandomAccess` 接口。 #### 44. ArrayList 和 LinkedList 区别 * **是否保证线程安全：** `ArrayList` 和 `LinkedList` 都是不同步的，也就是不保证线程安全。 * **底层数据结构：** `ArrayList` 底层使用的是 **`Object` 数组**；`LinkedList` 底层使用的是 **双向链表** 数据结构。 * **插入和删除是否受元素位置的影响：** * `ArrayList` 采用数组存储，所以插入和删除元素的时间复杂度受元素位置的影响。 * `LinkedList` 采用链表存储，所以在头尾插入或者删除元素不受元素位置的影响（`add(E e)`、`addFirst(E e)`、`addLast(E e)`、`removeFirst()`、 `removeLast()`），时间复杂度为 O(1)，如果是要在指定位置 `i` 插入和删除元素的话（`add(int index, E element)`，`remove(Object o)`,`remove(int index)`）， 时间复杂度为 O(n) ，因为需要先移动到指定位置再插入和删除。 * **是否支持快速随机访问：** `LinkedList` 不支持高效的随机元素访问，而 `ArrayList`（实现了 `RandomAccess` 接口） 支持。快速随机访问就是通过元素的序号快速获取元素对象 (对应于 `get(int index)` 方法)。 * **内存空间占用：** `ArrayList` 的空间浪费主要体现在在 list 列表的结尾会预留一定的容量空间，而 LinkedList 的空间花费则体现在它的每一个元素都需要消耗比 ArrayList 更多的空间（因为要存放直接后继和直接前驱以及数据）。 我们在项目中一般是不会使用到 `LinkedList` 的，需要用到 `LinkedList` 的场景几乎都可以使用 `ArrayList` 来代替，并且，性能通常会更好。 #### 45. Comparable 和 Comparator 的区别 `Comparable` 接口和 `Comparator` 接口都是 Java 中用于排序的接口，它们在实现类对象之间比较大小、排序等方面发挥了重要作用： * `Comparable` 接口实际上是出自 `java.lang` 包 它有一个 `compareTo(Object obj)` 方法用来排序 * `Comparator` 接口实际上是出自 `java.util` 包它有一个 `compare(Object obj1, Object obj2)` 方法用来排序 一般我们需要对一个集合使用自定义排序时，我们就要重写 `compareTo()` 方法或 `compare()` 方法，当我们需要对某一个集合实现两种排序方式，比如一个 `song` 对象中的歌名和歌手名分别采用一种排序方法的话，我们可以重写 `compareTo()` 方法和使用自制的 `Comparator` 方法或者以两个 `Comparator` 来实现歌名排序和歌星名排序，第二种代表我们只能使用两个参数版的 `Collections.sort()`。 #### 46. 无序性和不可重复性的含义是什么 * 无序性不等于随机性 ，无序性是指存储的数据在底层数组中并非按照数组索引的顺序添加 ，而是根据数据的哈希值决定的。 * 不可重复性是指添加的元素按照 `equals()` 判断时 ，返回 false，需要同时重写 `equals()` 方法和 `hashCode()` 方法。 #### 47. 比较 HashSet、LinkedHashSet 和 TreeSet 三者的异同 * `HashSet`、`LinkedHashSet` 和 `TreeSet` 都是 `Set` 接口的实现类，都能保证元素唯一，并且都不是线程安全的。 * `HashSet`、`LinkedHashSet` 和 `TreeSet` 的主要区别在于底层数据结构不同。`HashSet` 的底层数据结构是哈希表（基于 `HashMap` 实现）。`LinkedHashSet` 的底层数据结构是链表和哈希表，元素的插入和取出顺序满足 FIFO。`TreeSet` 底层数据结构是红黑树，元素是有序的，排序的方式有自然排序和定制排序。 * 底层数据结构不同又导致这三者的应用场景不同。`HashSet` 用于不需要保证元素插入和取出顺序的场景，`LinkedHashSet` 用于保证元素的插入和取出顺序满足 FIFO 的场景，`TreeSet` 用于支持对元素自定义排序规则的场景。 #### 48. Queue 和 Deque 的区别 `Queue` 是单端队列，只能从一端插入元素，另一端删除元素，实现上一般遵循 **先进先出（FIFO）** 规则。 `Deque` 是双端队列，在队列的两端均可以插入或删除元素。 #### 49. ArrayDeque 和 LinkedList 的区别 `ArrayDeque` 和 `LinkedList` 都实现了 `Deque` 接口，两者都具有队列的功能。 * `ArrayDeque` 是基于可变长的数组和双指针来实现，而 `LinkedList` 则通过链表来实现。 * `ArrayDeque` 不支持存储 `NULL` 数据，但 `LinkedList` 支持。 * `ArrayDeque` 插入时可能存在扩容过程, 不过均摊后的插入操作依然为 O(1)。虽然 `LinkedList` 不需要扩容，但是每次插入数据时均需要申请新的堆空间，均摊性能相比更慢。 从性能的角度上，选用 `ArrayDeque` 来实现队列要比 `LinkedList` 更好。此外，`ArrayDeque` 也可以用于实现栈。 #### 50. 什么是 BlockingQueue `BlockingQueue` （阻塞队列）是一个接口，继承自 `Queue`。`BlockingQueue` 阻塞的原因是其支持当队列没有元素时一直阻塞，直到有元素；还支持如果队列已满，一直等到队列可以放入新元素时再放入。 ```java public interface BlockingQueue extends Queue { // ... } ``` `BlockingQueue` 常用于生产者 - 消费者模型中，生产者线程会向队列中添加数据，而消费者线程会从队列中取出数据进行处理。 #### 51. ArrayBlockingQueue 和 LinkedBlockingQueue 有什么区别 `ArrayBlockingQueue` 和 `LinkedBlockingQueue` 是 Java 并发包中常用的两种阻塞队列实现，它们都是线程安全的。不过，不过它们之间也存在下面这些区别： * 底层实现：`ArrayBlockingQueue` 基于数组实现，而 `LinkedBlockingQueue` 基于链表实现。 * 是否有界：`ArrayBlockingQueue` 是有界队列，必须在创建时指定容量大小。`LinkedBlockingQueue` 创建时可以不指定容量大小，默认是 `Integer.MAX_VALUE`，也就是无界的。但也可以指定队列大小，从而成为有界的。 * 锁是否分离： `ArrayBlockingQueue` 中的锁是没有分离的，即生产和消费用的是同一个锁；`LinkedBlockingQueue` 中的锁是分离的，即生产用的是 `putLock`，消费是 `takeLock`，这样可以防止生产者和消费者线程之间的锁争夺。 * 内存占用：`ArrayBlockingQueue` 需要提前分配数组内存，而 `LinkedBlockingQueue` 则是动态分配链表节点内存。这意味着，`ArrayBlockingQueue` 在创建时就会占用一定的内存空间，且往往申请的内存比实际所用的内存更大，而 `LinkedBlockingQueue` 则是根据元素的增加而逐渐占用内存空间。 #### 52. HashMap 和 Hashtable 的区别 * **线程是否安全：** `HashMap` 是非线程安全的，`Hashtable` 是线程安全的,因为 `Hashtable` 内部的方法基本都经过 `synchronized` 修饰。（如果你要保证线程安全的话就使用 `ConcurrentHashMap` 吧！） * **效率：** 因为线程安全的问题，`HashMap` 要比 `Hashtable` 效率高一点。另外，`Hashtable` 基本被淘汰，不要在代码中使用它 * **对 Null key 和 Null value 的支持：** `HashMap` 可以存储 null 的 key 和 value，但 null 作为键只能有一个，null 作为值可以有多个；Hashtable 不允许有 null 键和 null 值，否则会抛出 `NullPointerException`。 * **初始容量大小和每次扩充容量大小的不同：** * 创建时如果不指定容量初始值，`Hashtable` 默认的初始大小为 11，之后每次扩充，容量变为原来的 2n+1。`HashMap` 默认的初始化大小为 16。之后每次扩充，容量变为原来的 2 倍。 * 创建时如果给定了容量初始值，那么 `Hashtable` 会直接使用你给定的大小，而 `HashMap` 会将其扩充为 2 的幂次方大小（`HashMap` 中的 `tableSizeFor()` 方法保证）。也就是说 `HashMap` 总是使用 2 的幂作为哈希表的大小,后面会介绍到为什么是 2 的幂次方。 * **底层数据结构：** JDK1.8 以后的 `HashMap` 在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为 8）时，将链表转化为红黑树（将链表转换成红黑树前会判断，如果当前数组的长度小于 64，那么会选择先进行数组扩容，而不是转换为红黑树），以减少搜索时间。`Hashtable` 没有这样的机制。 #### 54. HashMap 和 HashSet 的区别 `HashSet` 底层就是基于 `HashMap` 实现的。 | `HashMap` | `HashSet` | | ------------------------------- | ------------------------------------------------------------------------------------ | | 实现了 `Map` 接口 | 实现 `Set` 接口 | | 存储键值对 | 仅存储对象 | | 调用 `put()` 向 map 中添加元素 | 调用 `add()` 方法向 `Set` 中添加元素 | | `HashMap` 使用键（Key）计算 `hashcode` | `HashSet` 使用成员对象来计算 `hashcode` 值，对于两个对象来说 `hashcode` 可能相同，所以 `equals()` 方法用来判断对象的相等性 | | ### 55. HashMap 和 TreeMap 的区别 | | `TreeMap` 和 `HashMap` 都继承自 `AbstractMap` ，但是需要注意的是 `TreeMap` 它还实现了 `NavigableMap` 接口和 `SortedMap` 接口。 实现 `SortedMap` 接口让 `TreeMap` 有了对集合中的元素根据键排序的能力。 实现 `NavigableMap` 接口让 `TreeMap` 有了对集合内元素的搜索的能力。`NavigableMap` 接口提供了丰富的方法来探索和操作键值对: 1. **定向搜索**: `ceilingEntry()`, `floorEntry()`, `higherEntry()` 和 `lowerEntry()` 等方法可以用于定位大于、小于、大于等于、小于等于给定键的最接近的键值对。 2. **子集操作**: `subMap()`, `headMap()` 和 `tailMap()` 方法可以高效地创建原集合的子集视图，而无需复制整个集合。 3. **逆序视图**:`descendingMap()` 方法返回一个逆序的 `NavigableMap` 视图，使得可以反向迭代整个 `TreeMap`。 4. **边界操作**: `firstEntry()`, `lastEntry()`, `pollFirstEntry()` 和 `pollLastEntry()` 等方法可以方便地访问和移除元素。 这些方法都是基于红黑树数据结构的属性实现的，红黑树保持平衡状态，从而保证了搜索操作的时间复杂度为 O(log n)，这让 `TreeMap` 成为了处理有序集合搜索问题的强大工具。 #### 56. HashSet 如何检查重复 当你把对象加入 `HashSet` 时，`HashSet` 会先计算对象的 `hashcode` 值来判断对象加入的位置，同时也会与其他加入的对象的 `hashcode` 值作比较，如果没有相符的 `hashcode`，`HashSet` 会假设对象没有重复出现。但是如果发现有相同 `hashcode` 值的对象，这时会调用 `equals()` 方法来检查 `hashcode` 相等的对象是否真的相同。如果两者相同，`HashSet` 就不会让加入操作成功。 在 JDK1.8 中，实际上无论 `HashSet` 中是否已经存在了某元素，`HashSet` 都会直接插入，只是会在 `add()` 方法的返回值处告诉我们插入前是否存在相同元素。 #### 57. HashMap 底层实现 **JDK1.8 之前** JDK1.8 之前 `HashMap` 底层是 **数组和链表** 结合在一起使用也就是 **链表散列**。HashMap 通过 key 的 `hashcode` 经过扰动函数处理过后得到 hash 值，然后通过 `(n - 1) & hash` 判断当前元素存放的位置（这里的 n 指的是数组的长度），如果当前位置存在元素的话，就判断该元素与要存入的元素的 hash 值以及 key 是否相同，如果相同的话，直接覆盖，不相同就通过拉链法解决冲突。 所谓扰动函数指的就是 HashMap 的 `hash` 方法。使用 `hash` 方法也就是扰动函数是为了防止一些实现比较差的 `hashCode()` 方法 换句话说使用扰动函数之后可以减少碰撞。 * 先获取 key 的 hashCode() 值,赋给变量 h。 * 然后将 h 的高 16 位与低 16 位进行异或运算。 * 最终返回异或运算的结果。 **JDK1.8 之后** 当链表长度大于阈值（默认为 8）（将链表转换成红黑树前会判断，如果当前数组的长度小于 64，那么会选择先进行数组扩容，而不是转换为红黑树）时，将链表转化为红黑树，以减少搜索时间。 #### 58. HashMap 的长度为什么是 2 的幂次方 一个 40 亿长度的数组，内存是放不下的。所以这个散列值是不能直接拿来用的。用之前还要先做对数组的长度取模运算，得到的余数才能用来要存放的位置也就是对应的数组下标。这个数组下标的计算方法是“ `(n - 1) & hash`”。（n 代表数组长度）。 我们首先可能会想到采用% 取余的操作来实现。但是，重点来了：“取余 (%) 操作中如果除数是 2 的幂次则等价于与其除数减一的与 (&) 操作（也就是说 hash%length == hash&(length-1) 的前提是 length 是 2 的 n 次方）。” 并且 采用二进制位操作 &，相对于 % 能够提高运算效率，这就解释了 HashMap 的长度为什么是 2 的幂次方。 #### 59. HashMap 多线程操作导致死循环问题 JDK1.7 及之前版本的 `HashMap` 在多线程环境下扩容操作可能存在死循环问题，这是由于当一个桶位中有多个元素需要进行扩容时，多个线程同时对链表进行操作，头插法可能会导致链表中的节点指向错误的位置，从而形成一个环形链表，进而使得查询元素的操作陷入死循环无法结束。 为了解决这个问题，JDK1.8 版本的 HashMap 采用了尾插法而不是头插法来避免链表倒置，使得插入的节点永远都是放在链表的末尾，避免了链表中的环形结构。但是还是不建议在多线程下使用 `HashMap`，因为多线程下使用 `HashMap` 还是会存在数据覆盖的问题。并发环境下，推荐使用 `ConcurrentHashMap` 。 #### 60. HashMap 为什么线程不安全 JDK1.7 及之前版本，在多线程环境下，`HashMap` 扩容时会造成死循环和数据丢失的问题。 数据丢失这个在 JDK1.7 和 JDK 1.8 中都存在，这里以 JDK 1.8 为例进行介绍。 JDK 1.8 后，在 `HashMap` 中，多个键值对可能会被分配到同一个桶（bucket），并以链表或红黑树的形式存储。多个线程对 `HashMap` 的 `put` 操作会导致线程不安全，具体来说会有数据覆盖的风险。 * 两个线程 1,2 同时进行 put 操作，并且发生了哈希冲突（hash 函数计算出的插入下标是相同的）。 * 不同的线程可能在不同的时间片获得 CPU 执行的机会，当前线程 1 执行完哈希冲突判断后，由于时间片耗尽挂起。线程 2 先完成了插入操作。 * 随后，线程 1 获得时间片，由于之前已经进行过 hash 碰撞的判断，所有此时会直接进行插入，这就导致线程 2 插入的数据被线程 1 覆盖了。 还有一种情况是这两个线程同时 `put` 操作导致 `size` 的值不正确，进而导致数据覆盖的问题 * 线程 1 执行 `if(++size > threshold)` 判断时，假设获得 `size` 的值为 10，由于时间片耗尽挂起。 * 线程 2 也执行 `if(++size > threshold)` 判断，获得 `size` 的值也为 10，并将元素插入到该桶位中，并将 `size` 的值更新为 11。 * 随后，线程 1 获得时间片，它也将元素放入桶位中，并将 size 的值更新为 11。 * 线程 1、2 都执行了一次 `put` 操作，但是 `size` 的值只增加了 1，也就导致实际上只有一个元素被添加到了 `HashMap` 中。 #### 61. ConcurrentHashMap 和 HashTable 的区别 * **底层数据结构：** JDK1.7 的 `ConcurrentHashMap` 底层采用 **分段的数组 + 链表** 实现，JDK1.8 采用的数据结构跟 `HashMap1.8` 的结构一样，数组 + 链表/红黑二叉树。`Hashtable` 和 JDK1.8 之前的 `HashMap` 的底层数据结构类似都是采用 **数组 + 链表** 的形式，数组是 HashMap 的主体，链表则是主要为了解决哈希冲突而存在的； * **实现线程安全的方式（重要）：** * 在 JDK1.7 的时候，`ConcurrentHashMap` 对整个桶数组进行了分割分段 (`Segment`，分段锁)，每一把锁只锁容器其中一部分数据，多线程访问容器里不同数据段的数据，就不会存在锁竞争，提高并发访问率。 * 到了 JDK1.8 的时候，`ConcurrentHashMap` 已经摒弃了 `Segment` 的概念，而是直接用 `Node` 数组 + 链表 + 红黑树的数据结构来实现，并发控制使用 `synchronized` 和 CAS 来操作。（JDK1.6 以后 `synchronized` 锁做了很多优化） 整个看起来就像是优化过且线程安全的 `HashMap`，虽然在 JDK1.8 中还能看到 `Segment` 的数据结构，但是已经简化了属性，只是为了兼容旧版本； * **`Hashtable`(同一把锁)** : 使用 `synchronized` 来保证线程安全，效率非常低下。当一个线程访问同步方法时，其他线程也访问同步方法，可能会进入阻塞或轮询状态，如使用 put 添加元素，另一个线程不能使用 put 添加元素，也不能使用 get，竞争会越来越激烈效率越低。 #### 62. ConcurrentHashMap 线程安全的具体实现方式 **JDK1.8 之前** 首先将数据分为一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据时，其他段的数据也能被其他线程访问。 **`ConcurrentHashMap` 是由 `Segment` 数组结构和 `HashEntry` 数组结构组成**。 `Segment` 继承了 `ReentrantLock`,所以 `Segment` 是一种可重入锁，扮演锁的角色。`HashEntry` 用于存储键值对数据。 一个 `ConcurrentHashMap` 里包含一个 `Segment` 数组，`Segment` 的个数一旦**初始化就不能改变**。 `Segment` 数组的大小默认是 16，也就是说默认可以同时支持 16 个线程并发写。 `Segment` 的结构和 `HashMap` 类似，是一种数组和链表结构，一个 `Segment` 包含一个 `HashEntry` 数组，每个 `HashEntry` 是一个链表结构的元素，每个 `Segment` 守护着一个 `HashEntry` 数组里的元素，当对 `HashEntry` 数组的数据进行修改时，必须首先获得对应的 `Segment` 的锁。也就是说，对同一 `Segment` 的并发写入会被阻塞，不同 `Segment` 的写入是可以并发执行的。 **JDK1.8 之后** `ConcurrentHashMap` 取消了 `Segment` 分段锁，采用 `Node + CAS + synchronized` 来保证并发安全。数据结构跟 `HashMap` 1.8 的结构类似，数组 + 链表/红黑二叉树。Java 8 在链表长度超过一定阈值（8）时将链表（寻址时间复杂度为 O(N)）转换为红黑树（寻址时间复杂度为 O(log(N))）。 Java 8 中，锁粒度更细，`synchronized` 只锁定当前链表或红黑二叉树的首节点，这样只要 hash 不冲突，就不会产生并发，就不会影响其他 Node 的读写，效率大幅提升。 #### 63. ConcurrentHashMap 为什么 key 和 value 不能为 null `ConcurrentHashMap` 的 key 和 value 不能为 null 主要是为了避免二义性。null 是一个特殊的值，表示没有对象或没有引用。如果你用 null 作为键，那么你就无法区分这个键是否存在于 `ConcurrentHashMap` 中，还是根本没有这个键。同样，如果你用 null 作为值，那么你就无法区分这个值是否是真正存储在 `ConcurrentHashMap` 中的，还是因为找不到对应的键而返回的。 拿 get 方法取值来说，返回的结果为 null 存在两种情况： * 值没有在集合中。 * 值本身就是 null。 > 单线程下可以容忍歧义，而多线程下无法容忍。 与此形成对比的是，`HashMap` 可以存储 null 的 key 和 value，但 null 作为键只能有一个，null 作为值可以有多个。如果传入 null 作为参数，就会返回 hash 值为 0 的位置的值。单线程环境下，不存在一个线程操作该 HashMap 时，其他的线程将该 `HashMap` 修改的情况，所以可以通过 `contains(key)` 来做判断是否存在这个键值对，从而做相应的处理，也就不存在二义性问题。 多线程下无法正确判定键值对是否存在（存在其他线程修改的情况），单线程是可以的（不存在其他线程修改的情况）。 #### 64. ConcurrentHashMap 能保证复合操作的原子性吗 复合操作是指由多个基本操作 (如 `put`、`get`、`remove`、`containsKey` 等) 组成的操作，例如先判断某个键是否存在 `containsKey(key)`，然后根据结果进行插入或更新 `put(key, value)`。这种操作在执行过程中可能会被其他线程打断，导致结果不符合预期。 **那如何保证 `ConcurrentHashMap` 复合操作的原子性呢？** `ConcurrentHashMap` 提供了一些原子性的复合操作，如 `putIfAbsent`、`compute`、`computeIfAbsent` 、`computeIfPresent`、`merge` 等。这些方法都可以接受一个函数作为参数，根据给定的 key 和 value 来计算一个新的 value，并且将其更新到 map 中。 #### 65. Java 线程和操作系统的线程有什么区别 * JDK 1.2 之前，Java 线程是基于绿色线程（Green Threads）实现的，这是一种用户级线程（用户线程），也就是说 JVM 自己模拟了多线程的运行，而不依赖于操作系统。绿色线程在使用时有一些限制（比如绿色线程不能直接使用操作系统提供的功能如异步 I/O、只能在一个内核线程上运行无法利用多核） * 在 JDK 1.2 及以后，Java 线程改为基于原生线程（Native Threads）实现，也就是说 JVM 直接使用操作系统原生的内核级线程（内核线程）来实现 Java 线程，由操作系统内核进行线程的调度和管理。 用户线程创建和切换成本低，但不可以利用多核。内核态线程，创建和切换成本高，可以利用多核。 一句话概括 Java 线程和操作系统线程的关系：**现在的 Java 线程的本质其实就是操作系统的线程**。 #### 66. 如何创建线程 * **继承 Thread 类**：简单易用，但不支持多继承，且不便于共享资源。 * **实现 Runnable 接口**：支持多继承，适合多个线程共享同一资源。 * **使用 Callable 和 Future**：可以返回结果，适合需要处理结果的场景。 不过，这些方式其实并没有真正创建出线程。准确点来说，这些都属于是在 Java 代码中使用多线程的方法。 严格来说，Java 就只有一种方式可以创建线程，那就是通过 `new Thread().start()` 创建。不管是哪种方式，最终还是依赖于 `new Thread().start()`。 #### 67. 线程的生命周期与状态 * NEW: 初始状态，线程被创建出来但没有被调用 `start()` 。 * RUNNABLE: 运行状态，线程被调用了 `start()` 等待运行的状态。 * BLOCKED：阻塞状态，需要等待锁释放。 * WAITING：等待状态，表示该线程需要等待其他线程做出一些特定动作（通知或中断）。 * TIME\_WAITING：超时等待状态，可以在指定的时间后自行返回而不是像 WAITING 那样一直等待。 * TERMINATED：终止状态，表示该线程已经运行完毕。 线程在生命周期中并不是固定处于某一个状态而是随着代码的执行在不同状态之间切换。 * 线程创建之后它将处于 **NEW（新建）** 状态，调用 `start()` 方法后开始运行，线程这时候处于 **READY（可运行）** 状态。可运行状态的线程获得了 CPU 时间片（timeslice）后就处于 **RUNNING（运行）** 状态。 * 当线程执行 `wait()` 方法之后，线程进入 **WAITING（等待）** 状态。进入等待状态的线程需要依靠其他线程的通知才能够返回到运行状态。 * **TIMED\_WAITING(超时等待)** 状态相当于在等待状态的基础上增加了超时限制，比如通过 `sleep（long millis）` 方法或 `wait（long millis）` 方法可以将线程置于 TIMED\_WAITING 状态。当超时时间结束后，线程将会返回到 RUNNABLE 状态。 * 当线程进入 `synchronized` 方法/块或者调用 `wait` 后（被 `notify`）重新进入 `synchronized` 方法/块，但是锁被其它线程占有，这个时候线程就会进入 **BLOCKED（阻塞）** 状态。 * 线程在执行完了 `run()` 方法之后将会进入到 **TERMINATED（终止）** 状态。 #### 68. 什么是线程上下文切换 线程在执行过程中会有自己的运行条件和状态（也称上下文），比如上文所说到过的程序计数器，栈信息等。当出现如下情况的时候，线程会从占用 CPU 状态中退出。 * 主动让出 CPU，比如调用了 `sleep()`, `wait()` 等。 * 时间片用完，因为操作系统要防止一个线程或者进程长时间占用 CPU 导致其他线程或者进程饿死。 * 调用了阻塞类型的系统中断，比如请求 IO，线程被阻塞。 * 被终止或结束运行 这其中前三种都会发生线程切换，线程切换意味着需要保存当前线程的上下文，留待线程下次占用 CPU 的时候恢复现场。并加载下一个将要占用 CPU 的线程上下文。这就是所谓的 **上下文切换**。 #### 69. Thread.sleep() 方法和 Object.wait() 方法对比 **共同点**：两者都可以暂停线程的执行。 **区别**： * **`sleep()` 方法没有释放锁，而 `wait()` 方法释放了锁** 。 * `wait()` 通常被用于线程间交互/通信，`sleep()` 通常被用于暂停执行。 * `wait()` 方法被调用后，线程不会自动苏醒，需要别的线程调用同一个对象上的 `notify()` 或者 `notifyAll()` 方法。`sleep()` 方法执行完成后，线程会自动苏醒，或者也可以使用 `wait(long timeout)` 超时后线程会自动苏醒。 * `sleep()` 是 `Thread` 类的静态本地方法，`wait()` 则是 `Object` 类的本地方法。 #### 70. 为什么 wait() 方法不定义在 Thread 中 `wait()` 是让获得对象锁的线程实现等待，会自动释放当前线程占有的对象锁。每个对象（`Object`）都拥有对象锁，既然要释放当前线程占有的对象锁并让其进入 WAITING 状态，自然是要操作对应的对象（`Object`）而非当前的线程（`Thread`）。 类似的问题：**为什么 `sleep()` 方法定义在 `Thread` 中？** 因为 `sleep()` 是让当前线程暂停执行，不涉及到对象类，也不需要获得对象锁。 #### 71. 可以直接调用 Thread 类的 run 方法吗 new 一个 `Thread`，线程进入了新建状态。调用 `start()` 方法，会启动一个线程并使线程进入了就绪状态，当分配到时间片后就可以开始运行了。 `start()` 会执行线程的相应准备工作，然后自动执行 `run()` 方法的内容，这是真正的多线程工作。 但是，直接执行 `run()` 方法，会把 `run()` 方法当成一个 main 线程下的普通方法去执行，并不会在某个线程中执行它，所以这并不是多线程工作。 **总结：调用 `start()` 方法方可启动线程并使线程进入就绪状态，直接执行 `run()` 方法的话不会以多线程的方式执行** #### 72. 如何理解线程安全和不安全 * 线程安全指的是在多线程环境下，对于同一份数据，不管有多少个线程同时访问，都能保证这份数据的正确性和一致性。 * 线程不安全则表示在多线程环境下，对于同一份数据，多个线程同时访问时可能会导致数据混乱、错误或者丢失。 #### 73. 单核 CPU 上运行多个线程效率一定会高吗 在单核 CPU 上，同一时刻只能有一个线程在运行，其他线程需要等待 CPU 的时间片分配。如果线程是 CPU 密集型的，那么多个线程同时运行会导致频繁的线程切换。如果线程是 IO 密集型的，那么多个线程同时运行可以利用 CPU 在等待 IO 时的空闲时间，提高了效率。 因此，对于单核 CPU 来说，如果任务是 CPU 密集型的，那么开很多线程会影响效率；如果任务是 IO 密集型的，那么开很多线程会提高效率。当然，这里的“很多”也要适度，不能超过系统能够承受的上限。 #### 74. 如何预防和避免线程死锁 **预防** 1. **破坏请求与保持条件**：一次性申请所有的资源。 2. **破坏不剥夺条件**：占用部分资源的线程进一步申请其他资源时，如果申请不到，可以主动释放它占有的资源。 3. **破坏循环等待条件**：靠按序申请资源来预防。按某一顺序申请资源，释放资源则反序释放。破坏循环等待条件。 **避免** 避免死锁就是在资源分配时，借助于算法（比如银行家算法）对资源分配进行计算评估，使其进入安全状态。 #### 75. 如何保证变量的可见性 在 Java 中，`volatile` 关键字可以保证变量的可见性，如果我们将变量声明为 **`volatile`** ，这就指示 JVM，这个变量是共享且不稳定的，每次使用它都到主存中进行读取。 `volatile` 关键字能保证数据的可见性，但不能保证数据的原子性。`synchronized` 关键字两者都能保证。 #### 76. 如何禁止指令重排序 **在 Java 中，`volatile` 关键字除了可以保证变量的可见性，还有一个重要的作用就是防止 JVM 的指令重排序。** 如果我们将变量声明为 **`volatile`** ，在对这个变量进行读写操作的时候，会通过插入特定的 **内存屏障** 的方式来禁止指令重排序。 #### 77. volatile 可以保证原子性吗 **`volatile` 关键字能保证变量的可见性，但不能保证对变量的操作是原子性的。** #### 78. 如何实现乐观锁 **版本号机制** 1. 操作员 A 此时将其读出（ `version`=1 ），并从其帐户余额中扣除 $50（ $100-$50 ）。 2. 在操作员 A 操作的过程中，操作员 B 也读入此用户信息（ `version`=1 ），并从其帐户余额中扣除 $20 （ $100-$20 ）。 3. 操作员 A 完成了修改工作，将数据版本号（ `version`=1 ），连同帐户扣除后余额（ `balance`=$50 ），提交至数据库更新，此时由于提交数据版本等于数据库记录当前版本，数据被更新，数据库记录 `version` 更新为 2 。 4. 操作员 B 完成了操作，也将版本号（ `version`=1 ）试图向数据库提交数据（ `balance`=$80 ），但此时比对数据库记录版本时发现，操作员 B 提交的数据版本号为 1 ，数据库记录当前版本也为 2 ，不满足 “ 提交版本必须等于当前版本才能执行更新 “ 的乐观锁策略，因此，操作员 B 的提交被驳回。 这样就避免了操作员 B 用基于 `version`=1 的旧数据修改的结果覆盖操作员 A 的操作结果的可能。 **CAS 算法** CAS 涉及到三个操作数： * **V**：要更新的变量值 (Var) * **E**：预期值 (Expected) * **N**：拟写入的新值 (New) 当且仅当 V 的值等于 E 时，CAS 通过原子方式用新值 N 来更新 V 的值。如果不等，说明已经有其它线程更新了 V，则当前线程放弃更新。 #### 79. CAS 算法存在的问题 **ABA 问题** 如果一个变量 V 初次读取的时候是 A 值，并且在准备赋值的时候检查到它仍然是 A 值，那我们就能说明它的值没有被其他线程修改过了吗？很明显是不能的，因为在这段时间它的值可能被改为其他值，然后又改回 A，那 CAS 操作就会误认为它从来没有被修改过。这个问题被称为 CAS 操作的 **"ABA" 问题。** ABA 问题的解决思路是在变量前面追加上**版本号或者时间戳**。 **循环时间长开销大** CAS 经常会用到自旋操作来进行重试，也就是不成功就一直循环执行直到成功。如果长时间不成功，会给 CPU 带来非常大的执行开销。 如果 JVM 能支持处理器提供的 pause 指令那么效率会有一定的提升，pause 指令有两个作用： 1. 可以延迟流水线执行指令，使 CPU 不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零。 2. 可以避免在退出循环的时候因内存顺序冲突而引起 CPU 流水线被清空，从而提高 CPU 的执行效率。 **只能保证一个共享变量的原子操作** CAS 只对单个共享变量有效，当操作涉及跨多个共享变量时 CAS 无效。但是从 JDK 1.5 开始，提供了 `AtomicReference` 类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行 CAS 操作.所以我们可以使用锁或者利用 `AtomicReference` 类把多个共享变量合并成一个共享变量来操作。 #### 80. synchronized 是什么 主要解决的是多个线程之间访问资源的同步性，可以保证被它修饰的方法或者代码块在任意时刻只能有一个线程执行。 在 Java 早期版本中，`synchronized` 属于 **重量级锁**，效率低下。这是因为监视器锁（monitor）是依赖于底层的操作系统的 `Mutex Lock` 来实现的，Java 的线程是映射到操作系统的原生线程之上的。如果要挂起或者唤醒一个线程，都需要操作系统帮忙完成，而操作系统实现线程之间的切换时需要从用户态转换到内核态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高。 不过，在 Java 6 之后， `synchronized` 引入了大量的优化。因此， `synchronized` 还是可以在实际项目中使用的，像 JDK 源码、很多开源框架都大量使用了 `synchronized` 。 #### 81. synchronized 底层原理 `synchronized` 同步语句块的实现使用的是 `monitorenter` 和 `monitorexit` 指令，其中 `monitorenter` 指令指向同步代码块的开始位置，`monitorexit` 指令则指明同步代码块的结束位置。 `synchronized` 修饰的方法并没有 `monitorenter` 指令和 `monitorexit` 指令，取得代之的确实是 `ACC_SYNCHRONIZED` 标识，该标识指明了该方法是一个同步方法。 **不过两者的本质都是对对象监视器 monitor 的获取。** #### 82. JDK1.6 之后的 synchronized 底层做了哪些优化？锁升级原理了解吗 在 Java 6 之后， `synchronized` 引入了大量的优化如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销，这些优化让 `synchronized` 锁的效率提升了很多（JDK18 中，偏向锁已经被彻底废弃）。 锁主要存在四种状态，依次是：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态，他们会随着竞争的激烈而逐渐升级。注意锁可以升级不可降级，这种策略是为了提高获得锁和释放锁的效率。 #### 83. synchronized 和 volatile 有什么区别 * `volatile` 关键字是线程同步的轻量级实现，所以 `volatile` 性能肯定比 `synchronized` 关键字要好 。但是 `volatile` 关键字只能用于变量而 `synchronized` 关键字可以修饰方法以及代码块 。 * `volatile` 关键字能保证数据的可见性，但不能保证数据的原子性。`synchronized` 关键字两者都能保证。 * `volatile` 关键字主要用于解决变量在多个线程之间的可见性，而 `synchronized` 关键字解决的是多个线程之间访问资源的同步性。 #### 84. ReentrantLock 是什么 `ReentrantLock` 实现了 `Lock` 接口，是一个可重入且独占式的锁，和 `synchronized` 关键字类似。不过，`ReentrantLock` 更灵活、更强大，增加了轮询、超时、中断、公平锁和非公平锁等高级功能。 `ReentrantLock` 里面有一个内部类 `Sync`，`Sync` 继承 AQS（`AbstractQueuedSynchronizer`），添加锁和释放锁的大部分操作实际上都是在 `Sync` 中实现的。`Sync` 有公平锁 `FairSync` 和非公平锁 `NonfairSync` 两个子类。 `ReentrantLock` 默认使用非公平锁，也可以通过构造器来显式的指定使用公平锁。 ```java // 传入一个 boolean 值，true 时为公平锁，false 时为非公平锁 public ReentrantLock(boolean fair) { sync = fair ? new FairSync() : new NonfairSync(); } ``` #### 85. 公平锁和非公平锁有什么区别 * **公平锁** : 锁被释放之后，先申请的线程先得到锁。性能较差一些，因为公平锁为了保证时间上的绝对顺序，上下文切换更频繁。 * **非公平锁**：锁被释放之后，后申请的线程可能会先获取到锁，是随机或者按照其他优先级排序的。性能更好，但可能会导致某些线程永远无法获取到锁。 #### 86. synchronized 和 ReentrantLock 有什么区别 **都是可重入锁** **可重入锁** 也叫递归锁，指的是线程可以再次获取自己的内部锁。比如一个线程获得了某个对象的锁，此时这个对象锁还没有释放，当其再次想要获取这个对象的锁的时候还是可以获取的，如果是不可重入锁的话，就会造成死锁。 **synchronized 依赖于 JVM 而 ReentrantLock 依赖于 API** `synchronized` 是依赖于 JVM 实现的。 `ReentrantLock` 是 JDK 层面实现的（也就是 API 层面，需要 lock() 和 unlock() 方法配合 try/finally 语句块来完成），所以我们可以通过查看它的源代码，来看它是如何实现的。 **ReentrantLock 比 synchronized 增加了一些高级功能** * **等待可中断** : `ReentrantLock` 提供了一种能够中断等待锁的线程的机制，通过 `lock.lockInterruptibly()` 来实现这个机制。也就是说正在等待的线程可以选择放弃等待，改为处理其他事情。 * **可实现公平锁** : `ReentrantLock` 可以指定是公平锁还是非公平锁。而 `synchronized` 只能是非公平锁。所谓的公平锁就是先等待的线程先获得锁。`ReentrantLock` 默认情况是非公平的，可以通过 `ReentrantLock` 类的 `ReentrantLock(boolean fair)` 构造方法来指定是否是公平的。 * **可实现选择性通知（锁可以绑定多个条件）**: `synchronized` 关键字与 `wait()` 和 `notify()`/`notifyAll()` 方法相结合可以实现等待/通知机制。`ReentrantLock` 类当然也可以实现，但是需要借助于 `Condition` 接口与 `newCondition()` 方法。 #### 87. 可中断锁和不可中断锁有什么区别 * **可中断锁**：获取锁的过程中可以被中断，不需要一直等到获取锁之后 才能进行其他逻辑处理。`ReentrantLock` 就属于是可中断锁。 * **不可中断锁**：一旦线程申请了锁，就只能等到拿到锁以后才能进行其他的逻辑处理。 `synchronized` 就属于是不可中断锁。 #### 88. ReentrantReadWriteLock 适合什么场景 由于 `ReentrantReadWriteLock` 既可以保证多个线程同时读的效率，同时又可以保证有写入操作时的线程安全。因此，在读多写少的情况下，使用 `ReentrantReadWriteLock` 能够明显提升系统性能。 #### 89. 线程持有读锁还能获取写锁吗 * 在线程持有读锁的情况下，该线程不能取得写锁 (因为获取写锁的时候，如果发现当前的读锁被占用，就马上获取失败，不管读锁是不是被当前线程持有)。 * 在线程持有写锁的情况下，该线程可以继续获取读锁（获取读锁时如果发现写锁被占用，只有写锁没有被当前线程占用的情况才会获取失败）。 #### 90. ThreadLocal 有什么用 **`ThreadLocal` 类主要解决的就是让每个线程绑定自己的值，可以将 `ThreadLocal` 类形象的比喻成存放数据的盒子，盒子中可以存储每个线程的私有数据。** 如果你创建了一个 `ThreadLocal` 变量，那么访问这个变量的每个线程都会有这个变量的本地副本，这也是 `ThreadLocal` 变量名的由来。他们可以使用 `get()` 和 `set()` 方法来获取默认值或将其值更改为当前线程所存的副本的值，从而避免了线程安全问题。 #### 91. ThreadLocal 的原理 从 `Thread` 类源代码入手。 ```java public class Thread implements Runnable { //...... //与此线程有关的ThreadLocal值。由ThreadLocal类维护 ThreadLocal.ThreadLocalMap threadLocals = null; //与此线程有关的InheritableThreadLocal值。由InheritableThreadLocal类维护 ThreadLocal.ThreadLocalMap inheritableThreadLocals = null; //...... } ``` 从上面 `Thread` 类 源代码可以看出 `Thread` 类中有一个 `threadLocals` 和 一个 `inheritableThreadLocals` 变量，它们都是 `ThreadLocalMap` 类型的变量,我们可以把 `ThreadLocalMap` 理解为 `ThreadLocal` 类实现的定制化的 `HashMap`。默认情况下这两个变量都是 null，只有当前线程调用 `ThreadLocal` 类的 `set` 或 `get` 方法时才创建它们，实际上调用这两个方法的时候，我们调用的是 `ThreadLocalMap` 类对应的 `get()`、`set()` 方法。 **最终的变量是放在了当前线程的 `ThreadLocalMap` 中，并不是存在 `ThreadLocal` 上，`ThreadLocal` 可以理解为只是 `ThreadLocalMap` 的封装，传递了变量值。** `ThrealLocal` 类中可以通过 `Thread.currentThread()` 获取到当前线程对象后，直接通过 `getMap(Thread t)` 可以访问到该线程的 `ThreadLocalMap` 对象。 **每个 `Thread` 中都具备一个 `ThreadLocalMap`，而 `ThreadLocalMap` 可以存储以 `ThreadLocal` 为 key ，Object 对象为 value 的键值对。** ```java ThreadLocalMap(ThreadLocal firstKey, Object firstValue) { //...... } ``` 比如我们在同一个线程中声明了两个 `ThreadLocal` 对象的话， `Thread` 内部都是使用仅有的那个 `ThreadLocalMap` 存放数据的，`ThreadLocalMap` 的 key 就是 `ThreadLocal` 对象，value 就是 `ThreadLocal` 对象调用 `set` 方法设置的值。 #### 92. ThreadLocal 内存泄露问题是怎么导致的 `ThreadLocalMap` 中使用的 key 为 `ThreadLocal` 的弱引用，而 value 是强引用。所以，如果 `ThreadLocal` 没有被外部强引用的情况下，在垃圾回收的时候，key 会被清理掉，而 value 不会被清理掉。 这样一来，`ThreadLocalMap` 中就会出现 key 为 null 的 Entry。假如我们不做任何措施的话，value 永远无法被 GC 回收，这个时候就可能会产生内存泄露。`ThreadLocalMap` 实现中已经考虑了这种情况，在调用 `set()`、`get()`、`remove()` 方法的时候，会清理掉 key 为 null 的记录。使用完 `ThreadLocal` 方法后最好手动调用 `remove()` 方法 #### 93. 为什么要使用线程池 * **降低资源消耗**。通过重复利用已创建的线程降低线程创建和销毁造成的消耗。 * **提高响应速度**。当任务到达时，任务可以不需要等到线程创建就能立即执行。 * **提高线程的可管理性**。线程是稀缺资源，如果无限制的创建，不仅会消耗系统资源，还会降低系统的稳定性，使用线程池可以进行统一的分配，调优和监控。 #### 94. 线程池的常见参数 * `corePoolSize` : 任务队列未达到队列容量时，最大可以同时运行的线程数量。 * `maximumPoolSize` : 任务队列中存放的任务达到队列容量的时候，当前可以同时运行的线程数量变为最大线程数。 * `workQueue`: 新任务来的时候会先判断当前运行的线程数量是否达到核心线程数，如果达到的话，新任务就会被存放在队列中。 * `keepAliveTime`: 线程池中的线程数量大于 `corePoolSize` 的时候，如果这时没有新的任务提交，核心线程外的线程不会立即销毁，而是会等待，直到等待的时间超过了 `keepAliveTime` 才会被回收销毁。 * `handler` : 拒绝策略。 #### 95. 线程池的拒绝策略有哪些 * `ThreadPoolExecutor.AbortPolicy`：抛出 `RejectedExecutionException` 来拒绝新任务的处理。 * `ThreadPoolExecutor.CallerRunsPolicy`：调用执行自己的线程运行任务，也就是直接在调用 `execute` 方法的线程中运行 (`run`) 被拒绝的任务，如果执行程序已关闭，则会丢弃该任务。因此这种策略会降低对于新任务提交速度，影响程序的整体性能。如果你的应用程序可以承受此延迟并且你要求任何一个任务请求都要被执行的话，你可以选择这个策略。 * `ThreadPoolExecutor.DiscardPolicy`：不处理新任务，直接丢弃掉。 * `ThreadPoolExecutor.DiscardOldestPolicy`：此策略将丢弃最早的未处理的任务请求。 #### 96. CallerRunsPolicy 拒绝策略有什么风险 如果走到 `CallerRunsPolicy` 的任务是个非常耗时的任务，且处理提交任务的线程是主线程，可能会导致主线程阻塞，影响程序的正常运行。 因为 `CallerRunsPolicy` 这个拒绝策略，导致耗时的任务用了主线程执行，导致线程池阻塞，进而导致后续任务无法及时执行，严重的情况下很可能导致 OOM。 我们从问题的本质入手，可以增加阻塞队列 `BlockingQueue` 的大小并调整堆内存以容纳更多的任务，确保任务能够被准确执行。 为了充分利用 CPU，我们还可以调整线程池的 `maximumPoolSize` （最大线程数）参数，这样可以提高任务处理速度，避免累计在 `BlockingQueue` 的任务过多导致内存用完。 导致主线程卡死的本质就是因为我们不希望任何一个任务被丢弃。换个思路，有没有办法既能保证任务不被丢弃且在服务器有余力时及时处理呢？ 这里提供的一种**任务持久化**的思路，这里所谓的任务持久化，包括但不限于: 1. 设计一张任务表间任务存储到 MySQL 数据库中。 2. `Redis` 缓存任务。 3. 将任务提交到消息队列中。 如此一来，一旦我们的线程池中线程以达到满载时，我们就可以通过拒绝策略将最新任务持久化到 MySQL 数据库中，等到线程池有了有余力处理所有任务时，让其优先处理数据库中的任务以避免 " 饥饿 " 问题。 #### 97. 线程池常用的阻塞队列有哪些 * 容量为 `Integer.MAX_VALUE` 的 `LinkedBlockingQueue`（无界队列）：`FixedThreadPool` 和 `SingleThreadExector` 。`FixedThreadPool` 最多只能创建核心线程数的线程（核心线程数和最大线程数相等），`SingleThreadExector` 只能创建一个线程（核心线程数和最大线程数都是 1），二者的任务队列永远不会被放满。 * `SynchronousQueue`（同步队列）：`CachedThreadPool` 。`SynchronousQueue` 没有容量，不存储元素，目的是保证对于提交的任务，如果有空闲线程，则使用空闲线程来处理；否则新建一个线程来处理任务。也就是说，`CachedThreadPool` 的最大线程数是 `Integer.MAX_VALUE` ，可以理解为线程数是可以无限扩展的，可能会创建大量线程，从而导致 OOM。 * `DelayedWorkQueue`（延迟阻塞队列）：`ScheduledThreadPool` 和 `SingleThreadScheduledExecutor` 。`DelayedWorkQueue` 的内部元素并不是按照放入的时间排序，而是会按照延迟的时间长短对任务进行排序，内部采用的是“堆”的数据结构，可以保证每次出队的任务都是当前队列中执行时间最靠前的。`DelayedWorkQueue` 添加元素满了之后会自动扩容原来容量的 1/2，即永远不会阻塞，最大扩容可达 `Integer.MAX_VALUE`，所以最多只能创建核心线程数的线程。 #### 98. 线程池处理任务的流程 1. 如果当前运行的线程数小于核心线程数，那么就会新建一个线程来执行任务。 2. 如果当前运行的线程数等于或大于核心线程数，但是小于最大线程数，那么就把该任务放入到任务队列里等待执行。 3. 如果向任务队列投放任务失败（任务队列已经满了），但是当前运行的线程数是小于最大线程数的，就新建一个线程来执行任务。 4. 如果当前运行的线程数已经等同于最大线程数了，新建线程将会使当前运行的线程超出最大线程数，那么当前任务会被拒绝，拒绝策略会调用 `RejectedExecutionHandler.rejectedExecution()` 方法。 #### 99. 线程池中的线程异常后，销毁还是复用 * **使用 `execute()` 提交任务**：当任务通过 `execute()` 提交到线程池并在执行过程中抛出异常时，如果这个异常没有在任务内被捕获，那么该异常会导致当前线程终止，并且异常会被打印到控制台或日志文件中。线程池会检测到这种线程终止，并创建一个新线程来替换它，从而保持配置的线程数不变。 * **使用 `submit()` 提交任务**：对于通过 `submit()` 提交的任务，如果在任务执行中发生异常，这个异常不会直接打印出来。相反，异常会被封装在由 `submit()` 返回的 `Future` 对象中。当调用 `Future.get()` 方法时，可以捕获到一个 `ExecutionException`。在这种情况下，线程不会因为异常而终止，它会继续存在于线程池中，准备执行后续的任务。 简单来说：使用 `execute()` 时，未捕获异常导致线程终止，线程池创建新线程替代；使用 `submit()` 时，异常被封装在 `Future` 中，线程继续复用。 这种设计允许 `submit()` 提供更灵活的错误处理机制，因为它允许调用者决定如何处理异常，而 `execute()` 则适用于那些不需要关注执行结果的场景。 #### 100. 如何设定线程池大小 线程数量过多的影响主要是增加了**上下文切换**成本。 * 如果我们设置的线程池数量太小的话，如果同一时间有大量任务/请求需要处理，可能会导致大量的请求/任务在任务队列中排队等待执行，甚至会出现任务队列满了之后任务/请求无法处理的情况，或者大量任务堆积在任务队列导致 OOM。 * 如果我们设置线程数量太大，大量线程可能会同时在争取 CPU 资源，这样会导致大量的上下文切换，从而增加线程的执行时间，影响了整体执行效率。 有一个简单并且适用面比较广的公式： * **CPU 密集型任务 (N+1)：** 这种任务消耗的主要是 CPU 资源，可以将线程数设置为 N（CPU 核心数）+1。比 CPU 核心数多出来的一个线程是为了防止线程偶发的缺页中断，或者其它原因导致的任务暂停而带来的影响。一旦任务暂停，CPU 就会处于空闲状态，而在这种情况下多出来的一个线程就可以充分利用 CPU 的空闲时间。 * **I/O 密集型任务 (2N)：** 这种任务应用起来，系统会用大部分的时间来处理 I/O 交互，这时就可以将 CPU 交出给其它线程使用。因此在 I/O 密集型任务的应用中，我们可以多配置一些线程，具体的计算方法是 2N。 #### 101. 如何设计一个能够根据任务的优先级来执行的线程池 可以考虑使用 `PriorityBlockingQueue` （优先级阻塞队列）作为任务队列（`ThreadPoolExecutor` 的构造函数有一个 `workQueue` 参数可以传入任务队列）。 `PriorityBlockingQueue` 是一个支持优先级的无界阻塞队列，可以看作是线程安全的 `PriorityQueue`，两者底层都是使用小顶堆形式的二叉堆，即值最小的元素优先出队。不过，`PriorityQueue` 不支持阻塞操作。 要想让 `PriorityBlockingQueue` 实现对任务的排序，传入其中的任务必须是具备排序能力的，方式有两种： 1. 提交到线程池的任务实现 `Comparable` 接口，并重写 `compareTo` 方法来指定任务之间的优先级比较规则。 2. 创建 `PriorityBlockingQueue` 时传入一个 `Comparator` 对象来指定任务之间的排序规则 (推荐)。 不过，这存在一些风险和问题，比如： * `PriorityBlockingQueue` 是无界的，可能堆积大量的请求，从而导致 OOM。 * 可能会导致饥饿问题，即低优先级的任务长时间得不到执行。 * 由于需要对队列中的元素进行排序操作以及保证线程安全（并发控制采用的是可重入锁 `ReentrantLock`），因此会降低性能。 对于 OOM 这个问题的解决比较简单粗暴，就是继承 `PriorityBlockingQueue` 并重写一下 `offer` 方法 (入队) 的逻辑，当插入的元素数量超过指定值就返回 false 。 饥饿问题这个可以通过优化设计来解决（比较麻烦），比如等待时间过长的任务会被移除并重新添加到队列中，但是优先级会被提升。 对于性能方面的影响，是没办法避免的，毕竟需要对任务进行排序操作。并且，对于大部分业务场景来说，这点性能影响是可以接受的。 #### 102. Future 类有什么用 当我们执行某一耗时的任务时，可以将这个耗时任务交给一个子线程去异步执行。等我们的事情干完后，我们再通过 `Future` 类获取到耗时任务的执行结果。这样一来，程序的执行效率就明显提高了。 在 Java 中，`Future` 类只是一个泛型接口，位于 `java.util.concurrent` 包下，其中定义了 5 个方法，主要包括下面这 4 个功能： * 取消任务； * 判断任务是否被取消; * 判断任务是否已经执行完成; * 获取任务执行结果。 #### 103. Callable 和 Future 有什么关系 `FutureTask` 提供了 `Future` 接口的基本实现，常用来封装 `Callable` 和 `Runnable`，具有取消任务、查看任务是否执行完成以及获取任务执行结果的方法。 `FutureTask` 不光实现了 `Future` 接口，还实现了 `Runnable` 接口，因此可以作为任务直接被线程执行。 `FutureTask` 有两个构造函数，可传入 `Callable` 或者 `Runnable` 对象。实际上，传入 `Runnable` 对象也会在方法内部转换为 `Callable` 对象。 ```java public FutureTask(Callable callable) { if (callable == null) throw new NullPointerException(); this.callable = callable; this.state = NEW; } public FutureTask(Runnable runnable, V result) { // 通过适配器RunnableAdapter来将Runnable对象runnable转换成Callable对象 this.callable = Executors.callable(runnable, result); this.state = NEW; } ``` `FutureTask` 相当于对 `Callable` 进行了封装，管理着任务执行的情况，存储了 `Callable` 的 `call` 方法的任务执行结果。 #### 104. CompletableFuture 类有什么用 `Future` 在实际使用过程中存在一些局限性比如不支持异步任务的编排组合、获取计算结果的 `get()` 方法为阻塞调用。 Java 8 才被引入 `CompletableFuture` 类可以解决 `Future` 的这些缺陷。`CompletableFuture` 除了提供了更为好用和强大的 `Future` 特性之外，还提供了函数式编程、异步任务编排组合（可以将多个异步任务串联起来，组成一个完整的链式调用）等能力。 ```java public class CompletableFuture implements Future, CompletionStage { } ``` `CompletableFuture` 同时实现了 `Future` 和 `CompletionStage` 接口。 `CompletionStage` 接口描述了一个异步计算的阶段。很多计算可以分成多个阶段或步骤，此时可以通过它将所有步骤组合起来，形成异步计算的流水线。 #### 105. AQS 是什么 AQS 为构建锁和同步器提供了一些通用功能的实现，因此，使用 AQS 能简单且高效地构造出应用广泛的大量的同步器，比如我们提到的 `ReentrantLock`，`Semaphore`，其他的诸如 `ReentrantReadWriteLock`，`SynchronousQueue` 等等皆是基于 AQS 的。 #### 106. AQS 的原理是什么 AQS 核心思想是，如果被请求的共享资源空闲，则将当前请求资源的线程设置为有效的工作线程，并且将共享资源设置为锁定状态。如果被请求的共享资源被占用，那么就需要一套线程阻塞等待以及被唤醒时锁分配的机制，这个机制 AQS 是用 **CLH 队列锁** 实现的，即将暂时获取不到锁的线程加入到队列中。 CLH(Craig,Landin,and Hagersten) 队列是一个虚拟的双向队列（虚拟的双向队列即不存在队列实例，仅存在结点之间的关联关系）。AQS 是将每条请求共享资源的线程封装成一个 CLH 锁队列的一个结点（Node）来实现锁的分配。在 CLH 同步队列中，一个节点表示一个线程，它保存着线程的引用（thread）、 当前节点在队列中的状态（waitStatus）、前驱节点（prev）、后继节点（next）。 AQS 使用 **int 成员变量 `state` 表示同步状态**，通过内置的 **线程等待队列** 来完成获取资源线程的排队工作。 以 `ReentrantLock` 为例，`state` 初始值为 0，表示未锁定状态。A 线程 `lock()` 时，会调用 `tryAcquire()` 独占该锁并将 `state+1` 。此后，其他线程再 `tryAcquire()` 时就会失败，直到 A 线程 `unlock()` 到 `state=`0（即释放锁）为止，其它线程才有机会获取该锁。当然，释放锁之前，A 线程自己是可以重复获取此锁的（`state` 会累加），这就是可重入的概念。但要注意，获取多少次就要释放多少次，这样才能保证 state 是能回到零态的。 再以 `CountDownLatch` 以例，任务分为 N 个子线程去执行，`state` 也初始化为 N（注意 N 要与线程个数一致）。这 N 个子线程是并行执行的，每个子线程执行完后 `countDown()` 一次，state 会 CAS(Compare and Swap) 减 1。等到所有子线程都执行完后 (即 `state=0` )，会 `unpark()` 主调用线程，然后主调用线程就会从 `await()` 函数返回，继续后余动作。 #### 107. Semaphore 有什么用 `synchronized` 和 `ReentrantLock` 都是一次只允许一个线程访问某个资源，而 `Semaphore`(信号量) 可以用来控制同时访问特定资源的线程数量。 Semaphore 的使用简单，我们这里假设有 N(N>5) 个线程来获取 `Semaphore` 中的共享资源，下面的代码表示同一时刻 N 个线程中只有 5 个线程能获取到共享资源，其他线程都会阻塞，只有获取到共享资源的线程才能执行。等到有线程释放了共享资源，其他阻塞的线程才能获取到。 `Semaphore` 有两种模式： * **公平模式：** 调用 `acquire()` 方法的顺序就是获取许可证的顺序，遵循 FIFO * **非公平模式：** 抢占式的 ```java // 初始共享资源数量 final Semaphore semaphore = new Semaphore(5); // 获取1个许可 semaphore.acquire(); // 释放1个许可 semaphore.release(); ``` 当初始的资源个数为 1 的时候，`Semaphore` 退化为排他锁。 `Semaphore` 通常用于那些资源有明确访问数量限制的场景比如限流（仅限于单机模式，实际项目中推荐使用 Redis +Lua 来做限流）。 #### 108. Semaphore 的原理是什么 `Semaphore` 是共享锁的一种实现，它默认构造 AQS 的 `state` 值为 `permits`，你可以将 `permits` 的值理解为许可证的数量，只有拿到许可证的线程才能执行。 调用 `semaphore.acquire()` ，线程尝试获取许可证，如果 `state >= 0` 的话，则表示可以获取成功。如果获取成功的话，使用 CAS 操作去修改 `state` 的值 `state=state-1`。如果 `state<0` 的话，则表示许可证数量不足。此时会创建一个 Node 节点加入阻塞队列，挂起当前线程。 调用 `semaphore.release();` ，线程尝试释放许可证，并使用 CAS 操作去修改 `state` 的值 `state=state+1`。释放许可证成功之后，同时会唤醒同步队列中的一个线程。被唤醒的线程会重新尝试去修改 `state` 的值 `state=state-1` ，如果 `state>=0` 则获取令牌成功，否则重新进入阻塞队列，挂起线程。 #### 109. CountDownLatch 有什么用 `CountDownLatch` 允许 `count` 个线程阻塞在一个地方，直至所有线程的任务都执行完毕。 `CountDownLatch` 是一次性的，计数器的值只能在构造方法中初始化一次，之后没有任何机制再次对其设置值，当 `CountDownLatch` 使用完毕后，它不能再次被使用。 #### 110. CountDownLatch 的原理是什么 `CountDownLatch` 是共享锁的一种实现,它默认构造 AQS 的 `state` 值为 `count`。当线程使用 `countDown()` 方法时,其实使用了 `tryReleaseShared` 方法以 CAS 的操作来减少 `state`,直至 `state` 为 0 。当调用 `await()` 方法的时候，如果 `state` 不为 0，那就证明任务还没有执行完毕，`await()` 方法就会一直阻塞，也就是说 `await()` 方法之后的语句不会被执行。直到 `count` 个线程调用了 `countDown()` 使 state 值被减为 0，或者调用 `await()` 的线程被中断，该线程才会从阻塞中被唤醒，`await()` 方法之后的语句得到执行。 #### 111. CountDownLatch 使用场景 `CountDownLatch` 的作用就是 允许 count 个线程阻塞在一个地方，直至所有线程的任务都执行完毕。 例如：我们要读取处理 6 个文件，这 6 个任务都是没有执行顺序依赖的任务，但是我们需要返回给用户的时候将这几个文件的处理的结果进行统计整理。 为此我们定义了一个线程池和 count 为 6 的 `CountDownLatch` 对象 。使用线程池处理读取任务，每一个线程处理完之后就将 count-1，调用 `CountDownLatch` 对象的 `await()` 方法，直到所有文件读取完之后，才会接着执行后面的逻辑。 **是否可以优化呢？** `CompletableFuture` 提供了很多对多线程友好的方法，使用它可以很方便地为我们编写多线程程序，什么异步、串行、并行或者等待所有线程执行完任务什么的都非常方便。 #### 112. CyclicBarrier 有什么用 `CyclicBarrier` 和 `CountDownLatch` 非常类似，它也可以实现线程间的技术等待，但是它的功能比 `CountDownLatch` 更加复杂和强大。主要应用场景和 `CountDownLatch` 类似。 > `CountDownLatch` 的实现是基于 AQS 的，而 `CycliBarrier` 是基于 `ReentrantLock`(`ReentrantLock` 也属于 AQS 同步器) 和 `Condition` 的。 `CyclicBarrier` 的字面意思是可循环使用（Cyclic）的屏障（Barrier）。它要做的事情是：让一组线程到达一个屏障（也可以叫同步点）时被阻塞，直到最后一个线程到达屏障时，屏障才会开门，所有被屏障拦截的线程才会继续干活。 #### 113. CyclicBarrier 的原理是什么 `CyclicBarrier` 内部通过一个 `count` 变量作为计数器，`count` 的初始值为 `parties` 属性的初始化值，每当一个线程到了栅栏这里了，那么就将计数器减 1。如果 count 值为 0 了，表示这是这一代最后一个线程到达栅栏，就尝试执行我们构造方法中输入的任务。 #### 114. Java 中 3 种常见 IO 模型 Java 中常见的 3 种 IO 模型分别是： **BIO (Blocking I/O): 同步阻塞 IO 模型** * 应用程序发起 read 调用后，会一直阻塞，直到内核把数据拷贝到用户空间 * 数据的读取写入必须阻塞在一个线程内等待其完成 * 适用于连接数量小且连接时间较长的应用 **NIO (Non-blocking/New I/O): 同步非阻塞 IO 模型** * 应用程序发起 read 调用后，如果内核中没有数据，会直接返回而不阻塞 * 通过 Selector 实现了 IO 多路复用，一个线程可以监听多个连接 * 适用于连接数量多且连接时间较短的应用 **AIO (Asynchronous I/O): 异步 IO 模型** * 应用程序发起 read 后直接返回，不阻塞在那里 * 当后台处理完成，操作系统会通知相应的线程进行后续操作 * 目前应用还不是很广泛，Netty 之前也尝试使用过 AIO，不过又放弃了 #### 115. NIO 核心组件作用 * **Buffer（缓冲区）**：NIO 读写数据都是通过缓冲区进行操作的。读操作的时候将 Channel 中的数据填充到 Buffer 中，而写操作时将 Buffer 中的数据写入到 Channel 中。 * **Channel（通道）**：Channel 是一个双向的、可读可写的数据传输通道，NIO 通过 Channel 来实现数据的输入输出。通道是一个抽象的概念，它可以代表文件、套接字或者其他数据源之间的连接。 * **Selector（选择器）**：允许一个线程处理多个 Channel，基于事件驱动的 I/O 多路复用模型。所有的 Channel 都可以注册到 Selector 上，由 Selector 来分配线程来处理事件。 #### 116. NIO 零拷贝 零拷贝是指计算机执行 IO 操作时，CPU 不需要将数据从一个存储区域复制到另一个存储区域，从而可以减少上下文切换以及 CPU 的拷贝时间。 无论是传统的 I/O 方式，还是引入了零拷贝之后，2 次 DMA(Direct Memory Access) 拷贝是都少不了的。因为两次 DMA 都是依赖硬件完成的。零拷贝主要是减少了 CPU 拷贝及上下文的切换。 Java 对零拷贝的支持： * `MappedByteBuffer` 是 NIO 基于内存映射（`mmap`）这种零拷⻉⽅式的提供的⼀种实现，底层实际是调用了 Linux 内核的 `mmap` 系统调用。它可以将一个文件或者文件的一部分映射到内存中，形成一个虚拟内存文件，这样就可以直接操作内存中的数据，而不需要通过系统调用来读写文件。 * `FileChannel` 的 `transferTo()/transferFrom()` 是 NIO 基于发送文件（`sendfile`）这种零拷贝方式的提供的一种实现，底层实际是调用了 Linux 内核的 `sendfile` 系统调用。它可以直接将文件数据从磁盘发送到网络，而不需要经过用户空间的缓冲区。 #### 117. Java 运行时内存模型 **线程私有的：** * 程序计数器 * 虚拟机栈 * 本地方法栈 **线程共享的：** * 堆 * 方法区 * 直接内存 (非运行时数据区的一部分) **程序计数器** 程序计数器是一块较小的内存空间，可以看作是当前线程所执行的字节码的行号指示器。字节码解释器工作时通过改变这个计数器的值来选取下一条需要执行的字节码指令。 另外，为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各线程之间计数器互不影响，独立存储，我们称这类内存区域为“线程私有”的内存。 注意：程序计数器是唯一一个不会出现 `OutOfMemoryError` 的内存区域，它的生命周期随着线程的创建而创建，随着线程的结束而死亡。 **Java 虚拟机栈** Java 虚拟机栈（后文简称栈）也是线程私有的，它的生命周期和线程相同，随着线程的创建而创建，随着线程的死亡而死亡。 除了一些 Native 方法调用是通过本地方法栈实现的，其他所有的 Java 方法调用都是通过栈来实现的（也需要和其他运行时数据区域比如程序计数器配合）。 方法调用的数据需要通过栈进行传递，每一次方法调用都会有一个对应的栈帧被压入栈中，每一个方法调用结束后，都会有一个栈帧被弹出。 栈由一个个栈帧组成，而每个栈帧中都拥有：局部变量表、操作数栈、动态链接、方法返回地址。和数据结构上的栈类似，两者都是先进后出的数据结构，只支持出栈和入栈两种操作。 * 局部变量表：存放各种数据类型、对象引用 * 操作数栈：存放方法执行过程中产生的中间计算结果、临时变量 * 动态链接：将符号引用转换为调用方法的直接引用 * 方法返回地址： **栈帧随着方法调用而创建，随着方法结束而销毁。无论方法正常完成还是异常完成都算作方法结束。** * **`StackOverFlowError`：** 若栈的内存大小不允许动态扩展，那么当线程请求栈的深度超过当前 Java 虚拟机栈的最大深度的时候，就抛出 `StackOverFlowError` 错误。 * **`OutOfMemoryError`：** 如果栈的内存大小可以动态扩展， 如果虚拟机在动态扩展栈时无法申请到足够的内存空间，则抛出 `OutOfMemoryError` 异常。 **本地方法栈** 和虚拟机栈所发挥的作用非常相似，区别是：**虚拟机栈为虚拟机执行 Java 方法 （也就是字节码）服务，而本地方法栈则为虚拟机使用到的 Native 方法服务。** 在 HotSpot 虚拟机中和 Java 虚拟机栈合二为一。 **堆** Java 堆是所有线程共享的一块内存区域，在虚拟机启动时创建。**此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例以及数组都在这里分配内存。** 随着 JIT 编译器的发展与逃逸分析技术逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化，所有的对象都分配到堆上也渐渐变得不那么“绝对”了。从 JDK 1.7 开始已经默认开启逃逸分析，如果某些方法中的对象引用没有被返回或者未被外面使用（也就是未逃逸出去），那么对象可以直接在栈上分配内存。 Java 堆是垃圾收集器管理的主要区域，因此也被称作 **GC 堆（Garbage Collected Heap）**。从垃圾回收的角度，由于现在收集器基本都采用分代垃圾收集算法，所以 Java 堆还可以细分为：新生代和老年代；再细致一点有：Eden、Survivor、Old 等空间。进一步划分的目的是更好地回收内存，或者更快地分配内存。 在 JDK 7 版本及 JDK 7 版本之前，堆内存被通常分为下面三部分： 1. 新生代内存 (Young Generation) 2. 老生代 (Old Generation) 3. 永久代 (Permanent Generation) **JDK 8 版本之后 PermGen(永久代) 已被 Metaspace(元空间) 取代，元空间使用的是本地内存。** 大部分情况，对象都会首先在 Eden 区域分配，在一次新生代垃圾回收后，如果对象还存活，则会进入 S0 或者 S1，并且对象的年龄还会加 1(Eden 区 ->Survivor 区后对象的初始年龄变为 1)，当它的年龄增加到一定程度（默认为 15 岁），就会被晋升到老年代中。对象晋升到老年代的年龄阈值，可以通过参数 `-XX:MaxTenuringThreshold` 来设置。 \*\*为什么年龄只能是 0-15? \*\* 因为记录年龄的区域在对象头中，这个区域的大小通常是 4 位。这 4 位可以表示的最大二进制数字是 1111，即十进制的 15。因此，对象的年龄被限制为 0 到 15。 堆这里最容易出现的就是 `OutOfMemoryError` 错误，并且出现这种错误之后的表现形式还会有几种，比如： 1. **`java.lang.OutOfMemoryError: GC Overhead Limit Exceeded`**：当 JVM 花太多时间执行垃圾回收并且只能回收很少的堆空间时，就会发生此错误。 2. **`java.lang.OutOfMemoryError: Java heap space`** : 假如在创建新的对象时, 堆内存中的空间不足以存放新创建的对象, 就会引发此错误。 **方法区** 在不同的虚拟机实现上，方法区的实现是不同的。 当虚拟机要使用一个类时，它需要读取并解析 Class 文件获取相关信息，再将信息存入到方法区。方法区会存储已被虚拟机加载的 **类信息、字段信息、方法信息、常量、静态变量、即时编译器编译后的代码缓存等数据**。 **方法区和永久代以及元空间是什么关系呢？** 方法区和永久代以及元空间的关系很像 Java 中接口和类的关系，类实现了接口，这里的类就可以看作是永久代和元空间，接口可以看作是方法区，也就是说永久代以及元空间是 HotSpot 虚拟机对虚拟机规范中方法区的两种实现方式。并且，永久代是 JDK 1.8 之前的方法区实现，JDK 1.8 及以后方法区的实现变成了元空间。 **运行时常量池** Class 文件中除了有类的版本、字段、方法、接口等描述信息外，还有用于存放编译期生成的各种字面量（Literal）和符号引用（Symbolic Reference）的 **常量池表 (Constant Pool Table)** 。 常量池表会在类加载后存放到方法区的运行时常量池中。既然运行时常量池是方法区的一部分，自然受到方法区内存的限制，当常量池无法再申请到内存时会抛出 `OutOfMemoryError` 错误。 **字符串常量池** **字符串常量池** 是 JVM 为了提升性能和减少内存消耗针对字符串（String 类）专门开辟的一块区域，主要目的是为了避免字符串的重复创建。 **直接内存** 直接内存是一种特殊的内存缓冲区，并不在 Java 堆或方法区中分配的，而是通过 JNI 的方式在本地内存上分配的。 直接内存并不是虚拟机运行时数据区的一部分，也不是虚拟机规范中定义的内存区域，但是这部分内存也被频繁地使用。而且也可能导致 `OutOfMemoryError` 错误出现。 JDK1.4 中新加入的 **NIO（Non-Blocking I/O，也被称为 New I/O）**，引入了一种基于通道（Channel）与缓存区（Buffer）的 I/O 方式，它可以直接使用 Native 函数库直接分配堆外内存。这样就能在一些场景中显著提高性能，因为\*\*避免了在 Java 堆和 Native 堆之间来回复制数据。 直接内存的分配不会受到 Java 堆的限制，但是，既然是内存就会受到本机总内存大小以及处理器寻址空间的限制。 #### 118. 为什么要将永久代替换为元空间呢 * 整个永久代有一个 JVM 本身设置的固定大小上限，无法进行调整（也就是受到 JVM 内存的限制），而元空间使用的是本地内存，受本机可用内存的限制，虽然元空间仍旧可能溢出，但是比原来出现的几率会更小。 * 元空间里面存放的是类的元数据，这样加载多少类的元数据就不由 `MaxPermSize` 控制了, 而由系统的实际可用空间来控制，这样能加载的类就更多了。 * 在 JDK8，合并 HotSpot 和 JRockit 的代码时, JRockit 从来没有一个叫永久代的东西, 合并之后就没有必要额外的设置这么一个永久代的地方了。 * 永久代会为 GC 带来不必要的复杂度，并且回收效率偏低。 #### 119. JDK 1.7 为什么要将字符串常量池移动到堆中 主要是因为永久代（方法区实现）的 GC 回收效率太低，只有在整堆收集 (Full GC) 的时候才会被执行 GC。Java 程序中通常会有大量的被创建的字符串等待回收，将字符串常量池放到堆中，能够更高效及时地回收字符串内存。 #### 120. HotSpot 虚拟机对象创建、布局和访问过程 **对象的创建** 1. 类加载对象 虚拟机遇到一条 new 指令时，首先将去检查这个指令的参数是否能在常量池中定位到这个类的符号引用，并且检查这个符号引用代表的类是否已被加载过、解析和初始化过。如果没有，那必须先执行相应的类加载过程。 2. 分配内存 在**类加载检查**通过后，接下来虚拟机将为新生对象**分配内存**。对象所需的内存大小在类加载完成后便可确定，为对象分配空间的任务等同于把一块确定大小的内存从 Java 堆中划分出来。**分配方式**有 **“指针碰撞”** 和 **“空闲列表”** 两种，**选择哪种分配方式由 Java 堆是否规整决定，而 Java 堆是否规整又由所采用的垃圾收集器是否带有压缩整理功能决定**。 **内存分配的两种方式** ： * 指针碰撞： * 适用场合：堆内存规整（即没有内存碎片）的情况下。 * 原理：用过的内存全部整合到一边，没有用过的内存放在另一边，中间有一个分界指针，只需要向着没用过的内存方向将该指针移动对象内存大小位置即可。 * 使用该分配方式的 GC 收集器：Serial, ParNew * 空闲列表： * 适用场合：堆内存不规整的情况下。 * 原理：虚拟机会维护一个列表，该列表中会记录哪些内存块是可用的，在分配的时候，找一块儿足够大的内存块儿来划分给对象实例，最后更新列表记录。 * 使用该分配方式的 GC 收集器：CMS 选择以上两种方式中的哪一种，取决于 Java 堆内存是否规整。而 Java 堆内存是否规整，取决于 GC 收集器的算法是 " 标记 - 清除 "，还是 " 标记 - 整理 "，值得注意的是，复制算法内存也是规整的。 **内存分配并发问题** 在创建对象的时候有一个很重要的问题，就是线程安全，因为在实际开发过程中，创建对象是很频繁的事情，作为虚拟机来说，必须要保证线程是安全的，通常来讲，虚拟机采用两种方式来保证线程安全： * **CAS + 失败重试：** **虚拟机采用 CAS 配上失败重试的方式保证更新操作的原子性。** * **TLAB：** 为每一个线程预先在 Eden 区分配一块儿内存，JVM 在给线程中的对象分配内存时，首先在 TLAB 分配，当对象大于 TLAB 中的剩余内存或 TLAB 的内存已用尽时，再采用上述的 CAS 进行内存分配 3. 初始化零值 内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象头），这一步操作保证了对象的实例字段在 Java 代码中可以不赋初始值就直接使用，程序能访问到这些字段的数据类型所对应的零值。 4. 设置对象头 **虚拟机要对对象进行必要的设置**，例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的 GC 分代年龄等信息。 **这些信息存放在对象头中。** 5. 执行 init 方法 在上面工作都完成之后，从虚拟机的视角来看，一个新的对象已经产生了，但从 Java 程序的视角来看，对象创建才刚开始，`` 方法还没有执行，所有的字段都还为零。所以一般来说，执行 new 指令之后会接着执行 `` 方法，把对象按照程序员的意愿进行初始化，这样一个真正可用的对象才算完全产生出来。 **对象的内存布局** 在 Hotspot 虚拟机中，对象在内存中的布局可以分为 3 块区域：**对象头（Header）、实例数据（Instance Data）** 和**对齐填充（Padding）**。 对象头包括两部分信息： 1. 标记字段（Mark Word）：用于存储对象自身的运行时数据， 如哈希码（HashCode）、GC 分代年龄、锁状态标志、线程持有的锁、偏向线程 ID、偏向时间戳等等。 2. 类型指针（Klass Word）：对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。 **实例数据部分是对象真正存储的有效信息**，也是在程序中所定义的各种类型的字段内容。 **对齐填充部分不是必然存在的，也没有什么特别的含义，仅仅起占位作用。** 因为 Hotspot 虚拟机的自动内存管理系统要求对象起始地址必须是 8 字节的整数倍，换句话说就是对象的大小必须是 8 字节的整数倍。而对象头部分正好是 8 字节的倍数（1 倍或 2 倍），因此，当对象实例数据部分没有对齐时，就需要通过对齐填充来补全。 **对象的访问定位** 对象的访问方式由虚拟机实现而定，目前主流的访问方式有：**使用句柄**、**直接指针**。 * 如果使用句柄的话，那么 Java 堆中将会划分出一块内存来作为句柄池，reference 中存储的就是对象的句柄地址，而句柄中包含了对象实例数据与对象类型数据各自的具体地址信息。 * 如果使用直接指针访问，reference 中存储的直接就是对象的地址。 这两种对象访问方式各有优势。使用句柄来访问的最大好处是 reference 中存储的是稳定的句柄地址，在对象被移动时只会改变句柄中的实例数据指针，而 reference 本身不需要修改。使用直接指针访问方式最大的好处就是速度快，它节省了一次指针定位的时间开销。 #### 121. 内存分配和回收原则 **对象优先在 Eden 区分配** 大多数情况下，对象在新生代中 Eden 区分配。当 Eden 区没有足够空间进行分配时，虚拟机将发起一次 Minor GC。 通过 **分配担保机制** 把新生代的对象提前转移到老年代中去，老年代上的空间足够存放，所以不会出现 Full GC。执行 Minor GC 后，后面分配的对象如果能够存在 Eden 区的话，还是会在 Eden 区分配内存。 **大对象直接进入老年代** 大对象就是需要大量连续内存空间的对象（比如：字符串、数组）。大对象直接进入老年代的行为是由虚拟机动态决定的，它与具体使用的垃圾回收器和相关参数有关。大对象直接进入老年代是一种优化策略，旨在避免将大对象放入新生代，从而减少新生代的垃圾回收频率和成本。 * G1 垃圾回收器会根据 `-XX:G1HeapRegionSize` 参数设置的堆区域大小和 `-XX:G1MixedGCLiveThresholdPercent` 参数设置的阈值，来决定哪些对象会直接进入老年代。 * Parallel Scavenge 垃圾回收器中，默认情况下，并没有一个固定的阈值 (`XX:ThresholdTolerance` 是动态调整的) 来决定何时直接在老年代分配大对象。而是由虚拟机根据当前的堆内存情况和历史数据动态决定。 **长期存活的对象将进入老年代** 大部分情况，对象都会首先在 Eden 区域分配。如果对象在 Eden 出生并经过第一次 Minor GC 后仍然能够存活，并且能被 Survivor 容纳的话，将被移动到 Survivor 空间（s0 或者 s1）中，并将对象年龄设为 1(Eden 区 ->Survivor 区后对象的初始年龄变为 1)。 对象在 Survivor 中每熬过一次 MinorGC，年龄就增加 1 岁，当它的年龄增加到一定程度（默认为 15 岁），就会被晋升到老年代中。对象晋升到老年代的年龄阈值，可以通过参数 `-XX:MaxTenuringThreshold` 来设置。 **主要进行 GC 的区域** 针对 HotSpot VM 的实现，它里面的 GC 其实准确分类只有两大种： 部分收集 (Partial GC)： * 新生代收集（Minor GC / Young GC）：只对新生代进行垃圾收集； * 老年代收集（Major GC / Old GC）：只对老年代进行垃圾收集。需要注意的是 Major GC 在有的语境中也用于指代整堆收集； * 混合收集（Mixed GC）：对整个新生代和部分老年代进行垃圾收集。 整堆收集 (Full GC)：收集整个 Java 堆和方法区。 #### 122. 死亡对象的判断方法 **引用计数法** * 每当有一个地方引用它，计数器就加 1； * 当引用失效，计数器就减 1； * 任何时候计数器为 0 的对象就是不可能再被使用的。 **这个方法实现简单，效率高，但是目前主流的虚拟机中并没有选择这个算法来管理内存，其最主要的原因是它很难解决对象之间循环引用的问题。** **可达性分析算法** 这个算法的基本思想就是通过一系列的称为 **“GC Roots”** 的对象作为起点，从这些节点开始向下搜索，节点所走过的路径称为引用链，当一个对象到 GC Roots 没有任何引用链相连的话，则证明此对象是不可用的，需要被回收。 **哪些对象可以作为 GC Roots 呢？** * 虚拟机栈 (栈帧中的局部变量表) 中引用的对象 * 本地方法栈 (Native 方法) 中引用的对象 * 方法区中类静态属性引用的对象 * 方法区中常量引用的对象 * 所有被同步锁持有的对象 * JNI（Java Native Interface）引用的对象 **对象可以被回收，就代表一定会被回收吗？** 要真正宣告一个对象死亡，至少要经历两次标记过程；可达性分析法中不可达的对象被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行 `finalize` 方法。当对象没有覆盖 `finalize` 方法，或 `finalize` 方法已经被虚拟机调用过时，虚拟机将这两种情况视为没有必要执行。 被判定为需要执行的对象将会被放在一个队列中进行第二次标记，除非这个对象与引用链上的任何一个对象建立关联，否则就会被真的回收。 #### 123. Java 的引用类型 **1．强引用（StrongReference）** 以前我们使用的大部分引用实际上都是强引用，这是使用最普遍的引用。如果一个对象具有强引用，垃圾回收器绝不会回收它。当内存空间不足，Java 虚拟机宁愿抛出 OutOfMemoryError 错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足问题。 **2．软引用（SoftReference）** 如果一个对象只具有软引用，那就**可有可无**。如果内存空间足够，垃圾回收器就不会回收它，如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存。 软引用可以和一个引用队列（ReferenceQueue）联合使用，如果软引用所引用的对象被垃圾回收，JAVA 虚拟机就会把这个软引用加入到与之关联的引用队列中。 **3．弱引用（WeakReference）** 弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程， 因此不一定会很快发现那些只具有弱引用的对象。 弱引用可以和一个引用队列（ReferenceQueue）联合使用，如果弱引用所引用的对象被垃圾回收，Java 虚拟机就会把这个弱引用加入到与之关联的引用队列中。 **4．虚引用（PhantomReference）** " 虚引用 " 顾名思义，就是形同虚设，与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收。 **虚引用主要用来跟踪对象被垃圾回收的活动**。 **虚引用与软引用和弱引用的一个区别在于：** 虚引用必须和引用队列（ReferenceQueue）联合使用。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之关联的引用队列中。程序可以通过判断引用队列中是否已经加入了虚引用，来了解被引用的对象是否将要被垃圾回收。程序如果发现某个虚引用已经被加入到引用队列，那么就可以在所引用的对象的内存被回收之前采取必要的行动。 特别注意，在程序设计中一般很少使用弱引用与虚引用，使用软引用的情况较多，这是因为**软引用可以加速 JVM 对垃圾内存的回收速度，可以维护系统的运行安全，防止内存溢出（OutOfMemory）等问题的产生**。 #### 124. 如何判断一个常量是废弃常量 假如在字符串常量池中存在字符串 "abc"，如果当前没有任何 String 对象引用该字符串常量的话，就说明常量 "abc" 就是废弃常量，如果这时发生内存回收的话而且有必要的话，"abc" 就会被系统清理出常量池了。 #### 125. 如何判断一个类是无用的类 类需要同时满足下面 3 个条件才能算是 **“无用的类”**： * 该类所有的实例都已经被回收，也就是 Java 堆中不存在该类的任何实例。 * 加载该类的 `ClassLoader` 已经被回收。 * 该类对应的 `java.lang.Class` 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。 虚拟机可以对满足上述 3 个条件的无用类进行回收，这里说的仅仅是“可以”，而并不是和对象一样不使用了就会必然被回收。 #### 126. Java 垃圾收集算法 **标记 - 清除算法** 标记 - 清除（Mark-and-Sweep）算法分为“标记（Mark）”和“清除（Sweep）”阶段：首先标记出所有不需要回收的对象，在标记完成后统一回收掉所有没有被标记的对象。 它是最基础的收集算法，后续的算法都是对其不足进行改进得到。这种垃圾收集算法会带来两个明显的问题： 1. **效率问题**：标记和清除两个过程效率都不高。 2. **空间问题**：标记清除后会产生大量不连续的内存碎片。 **复制算法** 为了解决标记 - 清除算法的效率和内存碎片问题，复制（Copying）收集算法出现了。它将内存分为大小相同的两块，每次使用其中的一块。当这一块的内存使用完后，就将还存活的对象复制到另一块去，然后再把使用的空间一次清理掉。这样就使每次的内存回收都是对内存区间的一半进行回收。 虽然改进了标记 - 清除算法，但依然存在下面这些问题： * **可用内存变小**：可用内存缩小为原来的一半。 * **不适合老年代**：如果存活对象数量比较大，复制性能会变得很差。 **标记 - 整理算法** 标记 - 整理（Mark-and-Compact）算法是根据老年代的特点提出的一种标记算法，标记过程仍然与“标记 - 清除”算法一样，但后续步骤不是直接对可回收对象回收，而是让所有存活的对象向一端移动，然后直接清理掉端边界以外的内存。 由于多了整理这一步，因此效率也不高，适合老年代这种垃圾回收频率不是很高的场景。 **分代收集算法** 当前虚拟机的垃圾收集都采用分代收集算法，根据对象存活周期的不同将内存分为几块。一般将 Java 堆分为新生代和老年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。 比如在新生代中，每次收集都会有大量对象死去，所以可以选择”标记 - 复制“算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。而老年代的对象存活几率是比较高的，而且没有额外的空间对它进行分配担保，所以我们必须选择“标记 - 清除”或“标记 - 整理”算法进行垃圾收集。 #### 127. Java 垃圾收集器 JDK 默认垃圾收集器（使用 `java -XX:+PrintCommandLineFlags -version` 命令查看）： * JDK 8：Parallel Scavenge（新生代）+ Parallel Old（老年代） * JDK 9 \~ JDK20: G1 **Serial 收集器** Serial（串行）收集器是最基本、历史最悠久的垃圾收集器。这是一个单线程收集器。它的 **“单线程”** 的意义不仅仅意味着它只会使用一条垃圾收集线程去完成垃圾收集工作，更重要的是它在进行垃圾收集工作的时候必须暂停其他所有的工作线程（ **"Stop The World"** ），直到它收集结束。 **新生代采用标记 - 复制算法，老年代采用标记 - 整理算法。** Serial 收集器有没有优于其他垃圾收集器的地方呢？它**简单而高效（与其他收集器的单线程相比）**。Serial 收集器由于没有线程交互的开销，自然可以获得很高的单线程收集效率。Serial 收集器对于运行在 Client 模式下的虚拟机来说是个不错的选择。 **ParNew 收集器** ParNew 收集器其实就是 Serial 收集器的多线程版本，除了使用多线程进行垃圾收集外，其余行为（控制参数、收集算法、回收策略等等）和 Serial 收集器完全一样。 **新生代采用标记 - 复制算法，老年代采用标记 - 整理算法。** 它是许多运行在 Server 模式下的虚拟机的首要选择，除了 Serial 收集器外，只有它能与 CMS 收集器（真正意义上的并发收集器）配合工作。 **Parallel Scavenge 收集器** Parallel Scavenge 收集器也是使用标记 - 复制算法的多线程收集器，它看上去几乎和 ParNew 都一样。 Parallel Scavenge 收集器关注点是吞吐量（高效率的利用 CPU）。CMS 等垃圾收集器的关注点更多的是用户线程的停顿时间（提高用户体验）。所谓吞吐量就是 CPU 中用于运行用户代码的时间与 CPU 总消耗时间的比值。 Parallel Scavenge 收集器提供了很多参数供用户找到最合适的停顿时间或最大吞吐量。 **新生代采用标记 - 复制算法，老年代采用标记 - 整理算法。** **Serial Old 收集器** **Serial 收集器的老年代版本**，它同样是一个单线程收集器。它主要有两大用途：一种用途是在 JDK1.5 以及以前的版本中与 Parallel Scavenge 收集器搭配使用，另一种用途是作为 CMS 收集器的后备方案。 **Parallel Old 收集器** **Parallel Scavenge 收集器的老年代版本**。使用多线程和“标记 - 整理”算法。在注重吞吐量以及 CPU 资源的场合，都可以优先考虑 Parallel Scavenge 收集器和 Parallel Old 收集器。 **CMS 收集器** **CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。是第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。** CMS 收集器是一种 **“标记 - 清除”算法**实现的。整个过程分为四个步骤： * **初始标记：** 暂停所有的其他线程，并记录下直接与 root 相连的对象，速度很快 ； * **并发标记：** 同时开启 GC 和用户线程，用一个闭包结构去记录可达对象。但在这个阶段结束，这个闭包结构并不能保证包含当前所有的可达对象。因为用户线程可能会不断的更新引用域，所以 GC 线程无法保证可达性分析的实时性。所以这个算法里会跟踪记录这些发生引用更新的地方。 * **重新标记：** 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录。 * **并发清除：** 开启用户线程，同时 GC 线程开始对未标记的区域做清扫。 它有下面三个明显的缺点： * **对 CPU 资源敏感；** * **无法处理浮动垃圾；** * **它使用的回收算法 -“标记 - 清除”算法会导致收集结束时会有大量空间碎片产生。** **CMS 垃圾回收器在 Java 9 中已经被标记为过时 (deprecated)，并在 Java 14 中被移除。** **G1 收集器** **G1 (Garbage-First) 是一款面向服务器的垃圾收集器，主要针对配备多处理器大容量内存的机器，以极高概率满足 GC 停顿时间要求的同时，还具备高吞吐量性能特征。** 具备以下特点： * **并行与并发**：G1 能充分利用 CPU、多核环境下的硬件优势，使用多个 CPU 核心来缩短 STW 停顿时间。部分其他收集器原本需要停顿 Java 线程执行的 GC 动作，G1 收集器仍然可以通过并发的方式让 Java 程序继续执行。 * **分代收集**：虽然 G1 可以不需要其他收集器配合就能独立管理整个 GC 堆，但是还是保留了分代的概念。 * **空间整合**：G1 从整体来看是基于“标记 - 整理”算法实现的收集器；从局部上来看是基于“标记 - 复制”算法实现的。 * **可预测的停顿**：G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为 M 毫秒的时间片段内，消耗在垃圾收集上的时间不得超过 N 毫秒。 G1 收集器的运作大致分为以下几个步骤： * **初始标记** * **并发标记** * **最终标记** * **筛选回收** **G1 收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的 Region(这也就是它的名字 Garbage-First 的由来)** 。这种使用 Region 划分内存空间以及有优先级的区域回收方式，保证了 G1 收集器在有限时间内可以尽可能高的收集效率（把内存化整为零）。 **从 JDK9 开始，G1 垃圾收集器成为了默认的垃圾收集器。** **ZGC 收集器** ZGC 也采用标记 - 复制算法，不过 ZGC 对该算法做了重大改进。 ZGC 可以将暂停时间控制在几毫秒以内，且暂停时间不受堆内存大小的影响，出现 STW 的情况会更少，但代价是牺牲了一些吞吐量。ZGC 最大支持 16TB 的堆内存。 在 Java21 中，引入了分代 ZGC，暂停时间可以缩短到 1 毫秒以内。 #### 128. 类加载过程 系统加载 Class 类型的文件主要三步：**加载 ->连接 ->初始化**。连接过程又可分为三步：**验证 ->准备 ->解析**。 **加载** 1. 通过全类名获取定义此类的二进制字节流。 2. 将字节流所代表的静态存储结构转换为方法区的运行时数据结构。 3. 在内存中生成一个代表该类的 `Class` 对象，作为方法区这些数据的访问入口。 **验证** **验证是连接阶段的第一步，这一阶段的目的是确保 Class 文件的字节流中包含的信息符合《Java 虚拟机规范》的全部约束要求，保证这些信息被当作代码运行后不会危害虚拟机自身的安全。** 如果程序运行的全部代码都已经被反复使用和验证过，在生产环境的实施阶段就可以考虑使用 `-Xverify:none` 参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。 1. 文件格式验证（Class 文件格式检查） 2. 元数据验证（字节码语义检查） 3. 字节码验证（程序语义检查） 4. 符号引用验证（类的正确性检查） **准备** **准备阶段是正式为类变量分配内存并设置类变量初始值的阶段**，这些内存都将在方法区中分配。对于该阶段有以下几点需要注意： 1. 这时候进行内存分配的仅包括类变量（ Class Variables ，即静态变量，被 `static` 关键字修饰的变量，只与类相关，因此被称为类变量），而不包括实例变量。 2. 从概念上讲，类变量所使用的内存都应当在 **方法区** 中进行分配。而在 JDK 7 及之后，HotSpot 已经把原本放在永久代的字符串常量池、静态变量等移动到堆中，这个时候类变量则会随着 Class 对象一起存放在 Java 堆中。 3. 这里所设置的初始值 " 通常情况 " 下是数据类型默认的零值（如 0、0L、null、false 等），比如我们定义了 `public static int value=111` ，那么 value 变量在准备阶段的初始值就是 0 而不是 111（初始化阶段才会赋值）。特殊情况：比如给 value 变量加上了 final 关键字 `public static final int value=111` ，那么准备阶段 value 的值就被赋值为 111。 **解析** **解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。** 解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用限定符 7 类符号引用进行。 在程序执行方法时，系统需要明确知道这个方法所在的位置。Java 虚拟机为每个类都准备了一张方法表来存放类中所有的方法。当需要调用一个类的方法的时候，只要知道这个方法在方法表中的偏移量就可以直接调用该方法了。通过解析操作符号引用就可以直接转变为目标方法在类中方法表的位置，从而使得方法可以被调用。 **初始化** **初始化阶段是执行初始化方法 ` ()` 方法的过程，是类加载的最后一步，这一步 JVM 才开始真正执行类中定义的 Java 程序代码 (字节码)。** ` ()` 方法是带锁线程安全，在多线程环境下进行类初始化的话可能会引起多个线程阻塞，并且这种阻塞很难被发现。 对于初始化阶段，虚拟机严格规范了有且只有 6 种情况下，必须对类进行初始化 (只有主动去使用类才会初始化类)： 1. 当遇到 `new`、 `getstatic`、`putstatic` 或 `invokestatic` 这 4 条字节码指令时。 2. 使用 `java.lang.reflect` 包的方法对类进行反射调用时如 `Class.forName("...")`, `newInstance()` 等等。如果类没初始化，需要触发其初始化。 3. 初始化一个类，如果其父类还未初始化，则先触发该父类的初始化。 4. 当虚拟机启动时，用户需要定义一个要执行的主类 (包含 `main` 方法的那个类)，虚拟机会先初始化这个类。 5. `MethodHandle` 和 `VarHandle` 可以看作是轻量级的反射调用机制，而要想使用这 2 个调用，就必须先使用 `findStaticVarHandle` 来初始化要调用的类。 6. 当一个接口中定义了 JDK8 新加入的默认方法（被 default 关键字修饰的接口方法）时，如果有这个接口的实现类发生了初始化，那该接口要在其之前被初始化。 #### 129. 什么时候会类卸载 **卸载类即该类的 Class 对象被 GC。** 卸载类需要满足 3 个要求: 1. 该类的所有的实例对象都已被 GC，也就是说堆不存在该类的实例对象。 2. 该类没有在其他任何地方被引用 3. 该类的类加载器的实例已被 GC 所以，在 JVM 生命周期内，由 jvm 自带的类加载器加载的类是不会被卸载的。但是由我们自定义的类加载器加载的类是可能被卸载的。 #### 130. 什么是类加载器 * 类加载器是一个负责加载类的对象，用于实现类加载过程中的加载这一步。 * 每个 Java 类都有一个引用指向加载它的 `ClassLoader`。 * 数组类不是通过 `ClassLoader` 创建的（数组类没有对应的二进制字节流），是由 JVM 直接生成的。 **类加载器的主要作用就是加载 Java 类的字节码（ `.class` 文件）到 JVM 中（在内存中生成一个代表该类的 `Class` 对象）。** 字节码可以是 Java 源程序（`.java` 文件）经过 `javac` 编译得来，也可以是通过工具动态生成或者通过网络下载得来。 #### 131. 类加载器加载规则 JVM 启动的时候，并不会一次性加载所有的类，而是根据需要去动态加载。也就是说，大部分类在具体用到的时候才会去加载，这样对内存更加友好。 对于已经加载的类会被放在 `ClassLoader` 中。在类加载的时候，系统会首先判断当前类是否被加载过。已经被加载的类会直接返回，否则才会尝试加载。也就是说，对于一个类加载器来说，相同二进制名称的类只会被加载一次。 #### 132. 类加载器有哪些 1. **`BootstrapClassLoader`(启动类加载器)**：最顶层的加载类，由 C++ 实现，通常表示为 null，并且没有父级，主要用来加载 JDK 内部的核心类库。 2. **`ExtensionClassLoader`(扩展类加载器)**：主要负责加载 `%JRE_HOME%/lib/ext` 目录下的 jar 包和类以及被 `java.ext.dirs` 系统变量所指定的路径下的所有类。 3. **`AppClassLoader`(应用程序类加载器)**：面向我们用户的加载器，负责加载当前应用 classpath 下的所有 jar 包和类。 用户还可以加入自定义的类加载器来进行拓展，以满足自己的特殊需求。就比如说，我们可以对 Java 类的字节码（ `.class` 文件）进行加密，加载时再利用自定义的类加载器对其解密。 #### 133. 自定义类加载器 除了 `BootstrapClassLoader` 其他类加载器均由 Java 实现且全部继承自 `java.lang.ClassLoader`。如果我们要自定义自己的类加载器，需要继承 `ClassLoader` 抽象类。 `ClassLoader` 类有两个关键的方法： * `protected Class loadClass(String name, boolean resolve)`：加载指定二进制名称的类，实现了双亲委派机制 。 * `protected Class findClass(String name)`：根据类的二进制名称来查找类，默认实现是空方法。 如果我们不想打破双亲委派模型，就重写 `ClassLoader` 类中的 `findClass()` 方法即可，无法被父类加载器加载的类最终会通过这个方法被加载。但是，如果想打破双亲委派模型则需要重写 `loadClass()` 方法。 #### 134. 什么是双亲委派模型 * `ClassLoader` 类使用委托模型来搜索类和资源。 * 双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应有自己的父类加载器。 * `ClassLoader` 实例会在试图亲自查找类或资源之前，将搜索类或资源的任务委托给其父类加载器。 > 双亲委派模型并不是一种强制性的约束，只是 JDK 官方推荐的一种方式。 类加载器之间的父子关系一般不是以继承的关系来实现的，而是通常使用组合关系来复用父加载器的代码。 ```java public abstract class ClassLoader { ... // 组合 private final ClassLoader parent; protected ClassLoader(ClassLoader parent) { this(checkCreateClassLoader(), parent); } ... } ``` 在面向对象编程中，有一条非常经典的设计原则：**组合优于继承，多用组合少用继承。** #### 135. 双亲委派模型执行流程 每当一个类加载器接收到加载请求时，它会先将请求转发给父类加载器。在父类加载器没有找到所请求的类的情况下，该类加载器才会尝试去加载。 总结一下双亲委派模型的执行流程： * 在类加载的时候，系统会首先判断当前类是否被加载过。已经被加载的类会直接返回，否则才会尝试加载（每个父类加载器都会走一遍这个流程）。 * 类加载器在进行类加载的时候，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成（调用父加载器 `loadClass()` 方法来加载类）。这样的话，所有的请求最终都会传送到顶层的启动类加载器 `BootstrapClassLoader` 中。 * 只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载（调用自己的 `findClass()` 方法来加载类）。 * 如果子类加载器也无法加载这个类，那么它会抛出一个 `ClassNotFoundException` 异常。 > **JVM 判定两个 Java 类是否相同的具体规则**：JVM 不仅要看类的全名是否相同，还要看加载此类的类加载器是否一样。只有两者都相同的情况，才认为两个类是相同的。 #### 136. 双亲委派模型的好处 双亲委派模型保证了 Java 程序的稳定运行，可以避免类的重复加载（JVM 区分不同类的方式不仅仅根据类名，相同的类文件被不同的类加载器加载产生的是两个不同的类），也保证了 Java 的核心 API 不被篡改。 比如我们编写一个称为 `java.lang.Object` 类的话，那么程序运行的时候，系统就会出现两个不同的 `Object` 类。`AppClassLoader` 在加载你的 `Object` 类时，会委托给 `ExtClassLoader` 去加载，而 `ExtClassLoader` 又会委托给 `BootstrapClassLoader`，`BootstrapClassLoader` 发现自己已经加载过了 `Object` 类，会直接返回，不会去加载你写的 `Object` 类。 #### 137. 打破双亲委派模型方法 重写 `loadClass()` 方法之后，我们就可以改变传统双亲委派模型的执行流程。例如，子类加载器可以在委派给父类加载器之前，先自己尝试加载这个类，或者在父类加载器返回之后，再尝试从其他地方加载这个类。具体的规则由我们自己实现，根据项目需求定制化。 #### 138. 常用 JVM 参数 **显式指定堆内存** 如果我们需要指定最小和最大堆大小（推荐显示指定大小），以下参数可以帮助你实现： ```sh -Xms[unit] -Xmx[unit] ``` 如果我们要为 JVM 分配最小 2 GB 和最大 5 GB 的堆内存大小，我们的参数应该这样来写： ``` -Xms2G -Xmx5G ``` **显式新生代内存** 一共有两种指定 新生代内存 (Young Generation) 大小的方法： **1.通过 `-XX:NewSize` 和 `-XX:MaxNewSize` 指定** ```sh -XX:NewSize=[unit] -XX:MaxNewSize=[unit] ``` 如果我们要为 新生代分配 最小 256m 的内存，最大 1024m 的内存我们的参数应该这样来写： ```sh -XX:NewSize=256m -XX:MaxNewSize=1024m ``` **2.通过 `-Xmn[unit]` 指定** 如果我们要为 新生代分配 256m 的内存（NewSize 与 MaxNewSize 设为一致），我们的参数应该这样来写： ```sh -Xmn256m ``` GC 调优策略中很重要的一条经验总结是这样说的： > 将新对象预留在新生代，由于 Full GC 的成本远高于 Minor GC，因此尽可能将对象分配在新生代是明智的做法，实际项目中根据 GC 日志分析新生代空间大小分配是否合理，适当通过“-Xmn”命令调节新生代大小，最大限度降低新对象直接进入老年代的情况。 另外，你还可以通过 **`-XX:NewRatio=`** 来设置老年代与新生代内存的比值。 比如下面的参数就是设置老年代与新生代内存的比值为 1。也就是说老年代和新生代所占比值为 1：1，新生代占整个堆栈的 1/2。 ```sh -XX:NewRatio=1 ``` **显式指定永久代/元空间的大小** **从 Java 8 开始，如果我们没有指定 Metaspace 的大小，随着更多类的创建，虚拟机会耗尽所有可用的系统内存（永久代并不会出现这种情况）。** JDK 1.8 之前永久代还没被彻底移除的时候通常通过下面这些参数来调节方法区大小 ```sh -XX:PermSize=N #方法区 (永久代) 初始大小 -XX:MaxPermSize=N #方法区 (永久代) 最大大小,超过这个值将会抛出 OOM ``` 相对而言，垃圾收集行为在这个区域是比较少出现的，但并非数据进入方法区后就“永久存在”了。 **JDK 1.8 的时候，方法区（HotSpot 的永久代）被彻底移除了，取而代之是元空间，元空间使用的是本地内存。** 下面是常用参数： ```sh -XX:MaxMetaspaceSize=N #设置 Metaspace 的最大大小 ``` 对于 64 位 JVM 来说，Metaspace 的初始容量都是 21807104（约 20.8m）。 **垃圾回收器** JVM 具有四种类型的 GC 实现： * 串行垃圾收集器 * 并行垃圾收集器 * CMS 垃圾收集器 * G1 垃圾收集器 可以使用以下参数声明这些实现： ```sh -XX:+UseSerialGC -XX:+UseParallelGC -XX:+UseConcMarkSweepGC -XX:+UseG1GC ``` #### 139. Spring IoC 是什么 **IoC（Inversion of Control: 控制反转）** 是一种设计思想，而不是一个具体的技术实现。IoC 的思想就是将原本在程序中手动创建对象的控制权，交由 Spring 框架来管理。 **为什么叫控制反转？** * **控制**：指的是对象创建（实例化、管理）的权力 * **反转**：控制权交给外部环境（Spring 框架、IoC 容器） 将对象之间的相互依赖关系交给 IoC 容器来管理，并由 IoC 容器完成对象的注入。IoC 容器就像是一个工厂一样，当我们需要创建一个对象的时候，只需要配置好配置文件/注解即可，完全不用考虑对象是如何被创建出来的。 在实际项目中一个 Service 类可能依赖了很多其他的类，假如我们需要实例化这个 Service，你可能要每次都要搞清这个 Service 所有底层类的构造函数。如果利用 IoC 的话，你只需要配置好，然后在需要的地方引用就行了。 在 Spring 中， IoC 容器是 Spring 用来实现 IoC 的载体， IoC 容器实际上就是个 Map（key，value），Map 中存放的是各种对象。 #### 140. 什么是 Spring Bean 简单来说，Bean 代指的就是那些被 IoC 容器所管理的对象。 我们需要告诉 IoC 容器帮助我们管理哪些对象，这个是通过配置元数据来定义的。配置元数据可以是 XML 文件、注解或者 Java 配置类。 ```java ``` #### 141. 将一个类声明为 Bean 的注解有哪些 * `@Component`：通用的注解，可标注任意类为 `Spring` 组件。如果一个 Bean 不知道属于哪个层，可以使用 `@Component` 注解标注。 * `@Repository` : 对应持久层即 Dao 层，主要用于数据库相关操作。 * `@Service` : 对应服务层，主要涉及一些复杂的逻辑，需要用到 Dao 层。 * `@Controller` : 对应 Spring MVC 控制层，主要用于接受用户请求并调用 `Service` 层返回数据给前端页面。 #### 142. @Component 和 @Bean 的区别是什么 * `@Component` 注解作用于类，而 `@Bean` 注解作用于方法。 * `@Component` 通常是通过类路径扫描来自动侦测以及自动装配到 Spring 容器中。`@Bean` 注解通常是我们在标有该注解的方法中定义产生这个 bean，`@Bean` 告诉了 Spring 这是某个类的实例，当我需要用它的时候还给我。 * `@Bean` 注解比 `@Component` 注解的自定义性更强，而且很多地方我们只能通过 `@Bean` 注解来注册 bean。比如当我们引用第三方库中的类需要装配到 `Spring` 容器时，则只能通过 `@Bean` 来实现。 #### 143. @Autowired 和 @Resource 的区别是什么 * `@Autowired` 是 Spring 提供的注解，`@Resource` 是 JDK 提供的注解。 * `Autowired` 默认的注入方式为 `byType`（根据类型进行匹配），`@Resource` 默认注入方式为 `byName`（根据名称进行匹配）。 * 当一个接口存在多个实现类的情况下，`@Autowired` 和 `@Resource` 都需要通过名称才能正确匹配到对应的 Bean。`Autowired` 可以通过 `@Qualifier` 注解来显式指定名称，`@Resource` 可以通过 `name` 属性来显式指定名称。 * `@Autowired` 支持在构造函数、方法、字段和参数上使用。`@Resource` 主要用于字段和方法上的注入，不支持在构造函数或参数上使用。 #### 144. Bean 的作用域有哪些 * **singleton** : IoC 容器中只有唯一的 bean 实例。Spring 中的 bean 默认都是单例的，是对单例设计模式的 pe 应用。 * **prototy** : 每次获取都会创建一个新的 bean 实例。也就是说，连续 `getBean()` 两次，得到的是不同的 Bean 实例。 * **request** （仅 Web 应用可用）: 每一次 HTTP 请求都会产生一个新的 bean（请求 bean），该 bean 仅在当前 HTTP request 内有效。 * **session** （仅 Web 应用可用） : 每一次来自新 session 的 HTTP 请求都会产生一个新的 bean（会话 bean），该 bean 仅在当前 HTTP session 内有效。 * **application/global-session** （仅 Web 应用可用）：每个 Web 应用在启动时创建一个 Bean（应用 Bean），该 bean 仅在当前应用启动时间内有效。 * **websocket** （仅 Web 应用可用）：每一次 WebSocket 会话产生一个新的 bean。 #### 145. Bean 是线程安全的吗 prototype 作用域下，每次获取都会创建一个新的 bean 实例，不存在资源竞争问题。singleton 作用域下，IoC 容器中只有唯一的 bean 实例，可能会存在资源竞争问题（取决于 Bean 是否有状态）。如果这个 bean 是有状态的话，那就存在线程安全问题（有状态 Bean 是指包含可变的成员变量的对象）。 不过，大部分 Bean 实际都是无状态（没有定义可变的成员变量）的（比如 Dao、Service），这种情况下， Bean 是线程安全的。 对于有状态单例 Bean 的线程安全问题，常见的有两种解决办法： 1. 在 Bean 中尽量避免定义可变的成员变量。 2. 在类中定义一个 `ThreadLocal` 成员变量，将需要的可变成员变量保存在 `ThreadLocal` 中（推荐的一种方式）。 #### 146. Bean 的生命周期 1. **创建 Bean 的实例**：Bean 容器首先会找到配置文件中的 Bean 定义，然后使用 Java 反射 API 来创建 Bean 的实例。 2. **Bean 属性赋值/填充**：为 Bean 设置相关属性和依赖，例如 `@Autowired` 等注解注入的对象、`@Resource` 注入的各种资源。 3. **Bean 初始化**：根据实现了哪些接口调用对应的方法，例如 Bean 实现了 `BeanNameAware` 接口，调用 `setBeanName()` 方法，传入 Bean 的名字。 4. **销毁 Bean**：把 Bean 的销毁方法先记录下来，将来需要销毁 Bean 或者销毁容器的时候，就调用这些方法去释放 Bean 所持有的资源。 #### 147. Spring AOP 设计 AOP 能够将那些与业务无关，却为业务模块所共同调用的逻辑或责任（例如事务处理、日志管理、权限控制等）封装起来，便于减少系统的重复代码，降低模块间的耦合度，并有利于未来的可拓展性和可维护性。 Spring AOP 是基于动态代理的，如果要代理的对象，实现了某个接口，那么 Spring AOP 会使用 **JDK Proxy**，去创建代理对象，而对于没有实现接口的对象，就无法使用 JDK Proxy 去进行代理了，这时候 Spring AOP 会使用 **Cglib** 生成一个被代理对象的子类来作为代理。 #### 148. 多个切面的执行顺序如何控制 1. 通常使用 `@Order` 注解直接定义切面顺序 ```java // 值越小优先级越高 @Order(3) @Component @Aspect public class LoggingAspect implements Ordered { ``` 2. 实现 `Ordered` 接口重写 `getOrder` 方法。 ```java @Component @Aspect public class LoggingAspect implements Ordered { // .... @Override public int getOrder() { // 返回值越小优先级越高 return 1; } } ``` #### 148. Spring MVC 工作流程 1. 客户端发送请求， `DispatcherServlet` 拦截请求。 2. `DispatcherServlet` 根据请求信息调用 `HandlerMapping` 。`HandlerMapping` 根据 URL 去匹配查找能处理的 `Handler`，并会将请求涉及到的拦截器和 `Handler` 一起封装。 3. `DispatcherServlet` 调用 `HandlerAdapter` 适配器执行 `Handler` 。 4. `Handler` 完成对用户请求的处理后，会返回一个 `ModelAndView` 对象给 `DispatcherServlet`。 5. `ViewResolver` 会根据逻辑 `View` 查找实际的 `View`。 6. `DispaterServlet` 把返回的 `Model` 传给 `View`（视图渲染）。 7. 把 `View` 返回给请求者。 #### 149. 统一异常处理怎么做 推荐使用使用到 `@ControllerAdvice` + `@ExceptionHandler` 这两个注解进行处理。 ```java @ControllerAdvice @ResponseBody public class GlobalExceptionHandler { @ExceptionHandler(BaseException.class) public ResponseEntity handleAppException(BaseException ex, HttpServletRequest request) { //...... } @ExceptionHandler(value = ResourceNotFoundException.class) public ResponseEntity handleResourceNotFoundException(ResourceNotFoundException ex, HttpServletRequest request) { //...... } } ``` 这种异常处理方式下，会给所有或者指定的 `Controller` 织入异常处理的逻辑（AOP），当 `Controller` 中的方法抛出异常的时候，由被 `@ExceptionHandler` 注解修饰的方法进行处理。 `ExceptionHandlerMethodResolver` 中 `getMappedMethod` 方法决定了异常具体被哪个被 `@ExceptionHandler` 注解修饰的方法处理异常。 **`getMappedMethod()` 会首先找到可以匹配处理异常的所有方法信息，然后对其进行从小到大的排序，最后取最小的那一个匹配的方法 (即匹配度最高的那个)。** #### 150. Spring 用了哪些设计模型 * **工厂设计模式** : Spring 使用工厂模式通过 `BeanFactory`、`ApplicationContext` 创建 bean 对象。 * **代理设计模式** : Spring AOP 功能的实现。 * **单例设计模式** : Spring 中的 Bean 默认都是单例的。 * **模板方法模式** : Spring 中 `jdbcTemplate`、`hibernateTemplate` 等以 Template 结尾的对数据库操作的类，它们就使用到了模板模式。 * **包装器设计模式** : 我们的项目需要连接多个数据库，而且不同的客户在每次访问中根据需要会去访问不同的数据库。这种模式让我们可以根据客户的需求能够动态切换不同的数据源。 * **观察者模式:** Spring 事件驱动模型就是观察者模式很经典的一个应用。 * **适配器模式** : Spring AOP 的增强或通知 (Advice) 使用到了适配器模式、Spring MVC 中也是用到了适配器模式适配 `Controller`。 #### 150. Spring 三级缓存 1. **一级缓存（singletonObjects）**：存放最终形态的 Bean（已经实例化、属性填充、初始化）。一般情况我们获取 Bean 都是从这里单例池获取的，但是并不是所有的 Bean 都在单例池里面，例如原型 Bean 就不在里面。 2. **二级缓存（earlySingletonObjects）**：存放过渡 Bean（半成品，尚未属性填充），也就是三级缓存中 `ObjectFactory` 产生的对象，与三级缓存配合使用的，可以防止 AOP 的情况下，每次调用 `ObjectFactory#getObject()` 都是会产生新的代理对象的。 3. **三级缓存（singletonFactories）**：存放 `ObjectFactory`，`ObjectFactory` 的 `getObject()` 方法（最终调用的是 `getEarlyBeanReference()` 方法）可以生成原始 Bean 对象或者代理对象（如果 Bean 被 AOP 切面代理）。三级缓存只会对单例 Bean 生效。 Spring 创建 Bean 的流程： 1. 先去 **一级缓存 `singletonObjects`** 中获取，存在就返回； 2. 如果不存在或者对象正在创建中，于是去 **二级缓存 `earlySingletonObjects`** 中获取； 3. 如果还没有获取到，就去 **三级缓存 `singletonFactories`** 中获取，通过执行 `ObjectFacotry` 的 `getObject()` 就可以获取该对象，获取成功之后，从三级缓存移除，并将该对象加入到二级缓存中。 #### 151. 如何解决 Spring 的循环依赖 Spring 框架通过使用三级缓存来解决这个问题，确保即使在循环依赖的情况下也能正确创建 Bean。 如果发生循环依赖的话，就去 **三级缓存 `singletonFactories`** 中拿到三级缓存中存储的 `ObjectFactory` 并调用它的 `getObject()` 方法来获取这个循环依赖对象的前期暴露对象（虽然还没初始化完成，但是可以拿到该对象在堆中的存储地址了），并且将这个前期暴露对象放到二级缓存中，这样在循环依赖时，就不会重复初始化了。 不过，这种机制也有一些缺点，比如增加了内存开销（需要维护三级缓存，也就是三个 Map）。并且，还有少部分情况是不支持循环依赖的，比如非单例的 bean 和 `@Async` 注解的 bean 无法支持循环依赖。 #### 152. @Lazy 能解决循环依赖吗 如非必要，尽量不要用全局懒加载。全局懒加载会让 Bean 第一次使用的时候加载会变慢，并且它会延迟应用程序问题的发现（当 Bean 被初始化时，问题才会出现）。 有两个 Bean，A 和 B，他们之间发生了循环依赖，那么 A 的构造器上添加 `@Lazy` 注解之后（延迟 Bean B 的实例化），加载的流程如下： * 首先 Spring 会去创建 A 的 Bean，创建时需要注入 B 的属性； * 由于在 A 上标注了 `@Lazy` 注解，因此 Spring 会去创建一个 B 的代理对象，将这个代理对象注入到 A 中的 B 属性； * 之后开始执行 B 的实例化、初始化，在注入 B 中的 A 属性时，此时 A 已经创建完毕了，就可以将 A 给注入进去。 通过 `@Lazy` 就解决了循环依赖的注入， 关键点就在于对 A 中的属性 B 进行注入时，注入的是 B 的代理对象，因此不会循环依赖。 之前说的发生循环依赖是因为在对 A 中的属性 B 进行注入时，注入的是 B 对象，此时又会去初始化 B 对象，发现 B 又依赖了 A，因此才导致的循环依赖。 #### 153. SpringBoot 允许循环依赖发生吗 SpringBoot 2.6.x 以前是默认允许循环依赖的，SpringBoot 2.6.x 以后官方不再推荐编写存在循环依赖的代码。 SpringBoot 2.6.x 以后，如果你不想重构循环依赖的代码的话，也可以采用下面这些方法： * 在全局配置文件中设置允许循环依赖存在：`spring.main.allow-circular-references=true`。 * 在导致循环依赖的 Bean 上添加 `@Lazy` 注解，这是一种比较推荐的方式。`@Lazy` 用来标识类是否需要懒加载/延迟加载，可以作用在类上、方法上、构造器上、方法参数上、成员变量中。 #### 154. Spring 管理事务的方式有几种 * **编程式事务**：在代码中硬编码 (在分布式系统中推荐使用) : 通过 `TransactionTemplate` 或者 `TransactionManager` 手动管理事务，事务范围过大会出现事务未提交导致超时，因此事务要比锁的粒度更小。 * **声明式事务**：在 XML 配置文件中配置或者直接基于注解（简答应用推荐使用） : 实际是通过 AOP 实现（基于 `@Transactional` 的全注解方式使用最多） #### 155. Spring 事务中的隔离级别有哪几种 * **`TransactionDefinition.ISOLATION_DEFAULT`** : 使用后端数据库默认的隔离级别，MySQL 默认采用的可重复读隔离级别。 * **`TransactionDefinition.ISOLATION_READ_UNCOMMITTED`** : 最低的隔离级别，它允许读取尚未提交的数据变更，**可能会导致脏读、幻读或不可重复读**。 * **`TransactionDefinition.ISOLATION_READ_COMMITTED`** : 允许读取并发事务已经提交的数据，**可以阻止脏读，但是幻读或不可重复读仍有可能发生**。 * **`TransactionDefinition.ISOLATION_REPEATABLE_READ`** : 对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，**可以阻止脏读和不可重复读，但幻读仍有可能发生。** * **`TransactionDefinition.ISOLATION_SERIALIZABLE`** : 最高的隔离级别，所有的事务依次逐个执行，**该级别可以防止脏读、不可重复读以及幻读**。但是这将严重影响程序的性能。 #### 156. @Transactional(rollbackFor = Exception.class) 注解 `@Transactional` 注解默认回滚策略是只有在遇到 `RuntimeException`(运行时异常) 或者 `Error` 时才会回滚事务，而不会回滚 `Checked Exception`（受检查异常）。这是因为 Spring 认为 `RuntimeException` 和 Error 是不可预期的错误，而受检异常是可预期的错误，可以通过业务逻辑来处理。 如果想要修改默认的回滚策略，可以使用 `@Transactional` 注解的 `rollbackFor` 和 `noRollbackFor` 属性来指定哪些异常需要回滚，哪些异常不需要回滚。 #### 157. MinorGC、MajorGC、FullGC 的区别及触发场景 **Minor GC** * **定义**：Minor GC 是针对年轻代（Young Generation）进行的垃圾回收，主要清理 Eden 区和两个 Survivor 区（S0 和 S1）。 * **触发场景**：当 Eden 区满时，JVM 会触发 Minor GC 以释放空间。由于新对象通常在 Eden 区分配，因此如果对象的创建速度较快，Minor GC 会频繁触发。 * **特点**： * 采用标记 - 复制算法，清理过程不会导致内存碎片。 * 触发时会导致所有应用线程暂停（Stop-the-World），但通常暂停时间较短。 **Major GC** * **定义**：Major GC 通常指针对老年代（Tenured Generation）的垃圾回收，虽然没有严格的定义，但它主要清理老年代中的对象。 * **触发场景**：Major GC 通常在 Minor GC 之后触发，尤其是当老年代内存不足以存放从年轻代晋升的对象时。 * **特点**： * 可能会使用并发标记 - 清除算法，减少对应用线程的影响。 * 由于清理范围较大，暂停时间通常比 Minor GC 长。 **Full GC** * **定义**：Full GC 是对整个堆（包括年轻代和老年代）的垃圾回收。 * **触发场景**：Full GC 通常在以下情况下触发： * JVM 内存不足，无法为新对象分配空间。 * 显式调用 System.gc() 方法。 * Major GC 未能释放足够内存时。 * **特点**： * 清理范围最广，可能导致较长的暂停时间。 * 可能会导致性能下降，尤其是在应用对响应时间敏感的情况下。 #### 158. 在 Bean 加载/销毁前后实现特定逻辑的方法 * 实现 InitializingBean 和 DisposableBean 接口 * 使用 @PostConstruct 和 @PreDestroy 注解 * 在 XML 配置中指定 init-method 和 destroy-method #### 159. ConcurrentHashMap 怎么保证可见性 1. **volatile 修饰关键字段**：ConcurrentHashMap 中的一些关键字段使用 volatile 进行修饰。这些字段的修改对其他线程是可见的。 2. **volatile 保证内存可见性**：加上 volatile 关键字，其他线程就能立即看到这些字段的最新值。这就是内存可见性。 #### 160. HashMap 中的 put 和 get **`put` 方法的过程** 1. **计算哈希值**：首先，通过 `key.hashCode()` 计算出键的哈希值。为了确保哈希值的均匀分布，Java 会使用扰动函数来减少冲突的概率。 2. **确定索引**：使用处理后的哈希值与数组长度进行位与运算，以确定在数组中的位置（索引）。 3. **检查位置**：检查该索引位置是否为空： * **如果为空**：直接将新的节点（`Entry`）插入到该位置。 * **如果不为空**：需要处理哈希冲突。遍历该位置的链表，检查是否存在相同的键： * **如果找到相同的键**：替换旧的值，并返回旧值。 * **如果没有找到**：在链表的尾部插入新的节点。 4. **更新大小和扩容**：每次插入后，更新存储的元素数量，并检查是否超过扩容阈值（通常为当前容量的 75%），如超过则进行扩容。 **`get` 方法的过程** 1. **计算哈希值**：与 `put` 方法相同，首先计算出键的哈希值。 2. **确定索引**：同样使用哈希值与数组长度进行位与运算，确定索引位置。 3. **查找节点**：在该索引位置查找对应的节点： * 遍历链表，查找与给定键相等的节点。 * **如果找到**：返回该节点的值。 * **如果未找到**：返回 `null`。 #### 161. 双端检索单例 ```java public class Singleton { private static volatile Singleton instance; private Singleton() {} public static Singleton getInstance() { if (instance == null) { synchronized (Singleton.class) { if (instance == null) { instance = new Singleton(); } } } return instance; } } ``` **注意事项** 1. 使用 `volatile` 关键字修饰实例变量，防止指令重排序导致的错误 2. 第一次检查减少不必要的同步开销 3. 第二次检查避免多个线程同时创建实例 **优化方案** 双重检查锁在某些情况下可能会存在隐患。更安全的方式是使用静态内部类实现单例 ```java public class Singleton { private Singleton() {} private static class SingletonHolder { private static final Singleton INSTANCE = new Singleton(); } public static Singleton getInstance() { return SingletonHolder.INSTANCE; } } ``` 这种方式利用了 Java 的类加载机制来保证线程安全。当 `Singleton` 类被加载时，内部类 `SingletonHolder` 不会被加载。只有当 `getInstance()` 方法第一次被调用时，`SingletonHolder` 才会被加载，此时才会创建唯一实例。这种方式既保证了线程安全，又避免了同步带来的性能开销。 #### 162. 父类和子类的初始化顺序 **父类静态块** → **子类静态块** → **父类初始化块** → **父类构造方法** → **子类初始化块** → **子类构造方法** 这种结构确保了在创建子类实例时，父类的所有静态和非静态初始化操作都已完成，这样可以保证子类能够正确地继承和使用父类的属性和方法。 #### 163. SpringBoot 的启动流程 **启动入口** 每个 Spring Boot 应用都有一个主入口，通常是一个带有 `@SpringBootApplication` 注解的类，其 `main` 方法调用 `SpringApplication.run()` 方法启动应用。 **启动流程** 1. **调用 main 方法**：应用程序从 `main` 方法开始执行，调用 `SpringApplication.run()` 方法。 2. **创建 SpringApplication 实例**：在 `run` 方法中，首先创建一个 `SpringApplication` 对象，这个对象负责整个应用的启动过程。 3. **准备环境**：`SpringApplication` 会准备应用的环境，包括加载配置文件和设置属性。 4. **加载初始化器和监听器**：加载所有的 `ApplicationContextInitializer` 和 `ApplicationListener`，这些组件可以在应用启动的不同阶段执行自定义逻辑。 5. **创建应用上下文**：创建 `ConfigurableApplicationContext` 实例，通常是 `AnnotationConfigApplicationContext` 或 `WebApplicationContext`。 6. **刷新上下文**：调用上下文的 `refresh()` 方法，执行以下操作： * 加载所有的 Bean 定义。 * 实例化所有的单例 Bean。 * 发布 `ApplicationContextInitializedEvent` 和 `ApplicationEnvironmentPreparedEvent` 事件。 7. **调用 CommandLineRunner 和 ApplicationRunner**：在应用上下文刷新完成后，Spring Boot 会执行所有实现了 `CommandLineRunner` 和 `ApplicationRunner` 接口的 Bean，这些 Bean 可以用来在应用启动后执行特定逻辑。 8. **发布应用启动事件**：最后，发布 `ApplicationReadyEvent` 事件，表示应用已准备好接收请求。 #### 164. Java 多态体现形式 1. **编译时多态（静态多态）**：通过方法重载（overloading）实现，即同一方法名根据参数类型或数量的不同，调用不同的方法。 2. **运行时多态（动态多态）**：通过方法重写（overriding）实现，即子类重写父类的方法，运行时根据对象的实际类型调用相应的方法。 **实现机制** Java 通过**方法表**（Method Table）来实现动态绑定。每个类在加载时，JVM 会为其创建一个方法表，记录该类及其父类的方法信息。当调用一个方法时，JVM 会根据对象的实际类型查找方法表，找到对应的方法执行。 #### 165. SpringMVC 的工作流程 1. **用户请求**: 用户通过浏览器发送请求，首先到达前端控制器 `DispatcherServlet`。 2. **处理器映射**: `DispatcherServlet` 接收到请求后，调用 `HandlerMapping` 来查找与请求 URL 对应的处理器（Controller）。 3. **处理器适配**: 一旦找到处理器，`DispatcherServlet` 会调用 `HandlerAdapter` 来适配处理器，以执行具体的处理逻辑。 4. **执行处理器**: `HandlerAdapter` 执行找到的 Controller，并返回一个 `ModelAndView` 对象，这个对象包含了模型数据和视图信息。 5. **视图解析**: `DispatcherServlet` 将 `ModelAndView` 传递给 `ViewResolver`，后者解析出具体的视图（例如 JSP 页面）。 6. **视图渲染**: 最后，`DispatcherServlet` 将模型数据填充到视图中，并将结果返回给用户。 #### 166. 加载多个 JAR 包的原则 1. **本级优先于上级**：当前项目的依赖优先于其父项目的依赖。 2. **本级依赖版本优先于管理版本**：在同一项目中，直接依赖的版本优先于在 `dependencyManagement` 中管理的版本。 3. **后加载版本覆盖先加载版本**：在同一包中，后加载的版本会覆盖先加载的版本。 4. **上级管理版本和本级管理版本覆盖下级依赖版本**：如果上级或本级有管理版本，它们会覆盖下级依赖的版本。 5. **不同下级 JAR 中依赖了不同版本**：在多个下级依赖中，优先使用先加载的下级 JAR 中的版本。 6. **与版本号大小无关**：加载顺序不受版本号大小的影响。 7. **本级无法使用下级管理版本**：当前项目无法直接使用下级的管理版本。 #### 167. SOLID 设计原则 SOLID 是面向对象设计的五个基本原则的首字母缩写: * **S**ingle Responsibility Principle (单一职责原则) * **O**pen/Closed Principle (开闭原则) * **L**iskov Substitution Principle (里氏替换原则) * **I**nterface Segregation Principle (接口隔离原则) * **D**ependency Inversion Principle (依赖倒置原则) 这五个原则旨在使软件设计更加清晰、灵活和可维护。遵循这些原则可以让代码更加健壮和稳定。 #### 168. volatile 原理 1. 可见性 * **强制刷新主内存**：当一个线程写入一个 volatile 变量时，Java 虚拟机会确保这个值被立即写入主内存，而不是仅仅保存在线程的工作内存中。 * **失效其他线程的缓存**：写入 volatile 变量后，其他线程的工作内存中对应的变量值会失效，确保下次读取时会从主内存中获取最新值。 2. 有序性 volatile 通过禁止指令重排序来保证操作的有序性。Java 内存模型通过内存屏障（Memory Barriers）来实现这一点： * 在 volatile 写操作之前，插入 StoreStore 屏障，确保当前的写操作不会与之前的写操作重排序。 * 在 volatile 写操作之后，插入 StoreLoad 屏障，确保当前的写操作在后续的读操作之前完成。 * 在 volatile 读操作之后，插入 LoadLoad 和 LoadStore 屏障，确保当前的读操作不会与后续的读写操作重排序。 #### 169. synchronized 锁膨胀 synchronized 锁的升级过程是从无锁到偏向锁,再到轻量级锁,最后到重量级锁。这个过程也被称为锁膨胀。 **无锁** 一开始 synchronized 锁是无锁状态,对象的 MarkWord 存储的是对象的 hashcode、age 等信息。 **偏向锁** 当一个线程访问同步块并获取锁时,会将对象头中的 MarkWord 设置为指向当前线程的偏向锁。以后该线程进入和退出同步块时不需要 CAS 操作来加锁和解锁,只需简单地测试一下 MarkWord 是否指向当前线程即可。 **轻量级锁** 当有另一个线程想要获取锁时,偏向锁就会升级为轻量级锁。轻量级锁使用 CAS 操作来加锁和解锁,不需要申请操作系统资源。 **重量级锁** 当自旋超过一定次数或者有其他线程在等待该锁时,轻量级锁就会升级为重量级锁。重量级锁会让线程阻塞,使用操作系统的 mutex lock 来实现。 #### 170. 创建对象的四种方式 在 Java 中，创建对象主要有以下四种方式： **1. 使用 `new` 关键字** 这是最常见的创建对象的方法。通过调用类的构造器，可以创建对象的实例。示例代码如下： ```java User user = new User(); ``` **2. 使用反射机制** 反射机制允许在运行时动态创建对象。可以使用 `Class` 类的 `newInstance()` 方法，或者使用 `Constructor` 类的 `newInstance()` 方法来创建对象。示例代码如下： ```java Class userClass = User.class; User user = userClass.newInstance(); // 调用无参构造器 Constructor constructor = userClass.getConstructor(String.class); User userWithArgs = constructor.newInstance("张三"); // 调用有参构造器 ``` **3. 使用 `clone()` 方法** 通过实现 `Cloneable` 接口并重写 `clone()` 方法，可以使用克隆机制创建对象。此方法不会调用构造器。示例代码如下： ```java public class User implements Cloneable { @Override protected Object clone() throws CloneNotSupportedException { return super.clone(); } } // 使用克隆 User user1 = new User(); User user2 = (User) user1.clone(); ``` **4. 通过序列化和反序列化** 对象可以通过序列化存储到文件中，然后通过反序列化读取文件来创建对象。示例代码如下： ```java ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream("user.ser")); out.writeObject(user); out.close(); ObjectInputStream in = new ObjectInputStream(new FileInputStream("user.ser")); User userFromFile = (User) in.readObject(); in.close(); ``` #### 171. Java 基本数据类型 | 数据类型 | 字节数 | 范围 | 默认值 | | ---------------------------------- | --- | --------------------------------------------------------- | -------- | | byte | 1 | -128 to 127 | 0 | | short | 2 | -32,768 to 32,767 | 0 | | int | 4 | -2,147,483,648 to 2,147,483,647 | 0 | | long | 8 | -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807 | 0L | | float | 4 | ±3.40282347E+38 (6-7 significant decimal digits) | 0.0f | | double | 8 | ±1.79769313486231570E+308 (15 significant decimal digits) | 0.0d | | char | 2 | 0 to 65,535 | '\u0000' | | boolean | 1 | true or false | false | | ### 172. 如何设置可以使 JVM 进行频繁的 Full GC | | | | * 使用 `-XX:NewRatio` 参数来设置新生代和老年代的比例。默认情况下，这个比例是 2，表示新生代: 老年代=1:2。可以通过减小老年代的大小来增加 Full GC 的频率，因为老年代的空间不足会导致 Full GC 的发生。 * 使用 `-XX:PretenureSizeThreshold` 参数，可以设置一个偏小的阈值，使得超过该大小的对象直接分配到老年代，从而增加 Full GC 的发生频率。 #### 173. 一个线程 OOM，进程里其他线程还能运行吗 当一个 Java 进程中的某个线程发生了 OutOfMemoryError(OOM) 时，通常情况下只有该线程会被终止，其他线程不会受到直接影响，仍可以继续运行。