> For the complete documentation index, see [llms.txt](https://docs.haiboolang.cn/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.haiboolang.cn/java.md). # Java ## Java 基础 ### 基础概念与常识 #### Java 语言有哪些特点 1. 面向对象（封装，继承，多态）； * 封装 * **定义**：封装是面向对象编程中的一个基本概念，它将数据（属性）和方法（操作）绑定在一起，形成一个独立的单元（类），并通过访问控制符（如 `public`、`private`、`protected`）来限制对类的成员（属性和方法）的访问。 * **目的**：封装可以隐藏类内部的实现细节，使用户只能通过类提供的公共接口来操作类的数据，从而保护数据的安全性和完整性。 * **好处**：封装提高了代码的可维护性和可扩展性，因为外部代码不需要知道类的内部实现细节，只需要知道类提供的公共接口即可。 * 继承 * **定义**：继承是面向对象编程中的一个重要特性，允许一个类（子类）继承另一个类（父类）的属性和方法。 * **目的**：继承可以实现代码的重用，减少重复代码的编写。子类可以继承父类的共有属性和行为，并可以添加自己的特性和行为。 * **好处**：继承可以使代码更加结构化和模块化，提高代码的可维护性和可重用性。 * **多态** ： * **定义**：多态是面向对象编程中的一个强大特性，允许不同类的对象通过相同的接口进行交互。 * **目的**：多态可以提高代码的灵活性和可扩展性，允许程序员编写更通用的代码。 * **好处**：多态使代码更加灵活，可以轻松地扩展和修改程序，而不需要修改大量的现有代码。 2. 平台无关性（Java 虚拟机实现平台无关性）； * **实现原理**： * Java 源代码（`.java` 文件）被编译成字节码（`.class` 文件），字节码是一种中间形式的代码。 * 当 Java 程序运行时，Java 虚拟机（JVM）将字节码解释或编译成本地机器码，从而在目标平台上运行。 * JVM 是一个虚拟机，它提供了一个统一的运行时环境，使得 Java 程序可以在不同的平台上运行。 3. 可靠性（具备异常处理和自动内存管理机制）； 4. 安全性（Java 语言本身的设计就提供了多重安全防护机制如访问权限修饰符、限制程序直接访问操作系统资源）； * **限制程序直接访问操作系统资源**： * Java 程序无法直接访问操作系统的底层资源（如文件系统、网络端口等），而是通过 Java 提供的 API 来间接访问。 5. 高效性（通过 Just In Time 编译器等技术的优化，Java 语言的运行效率还是非常不错的）； * **Just-In-Time (JIT) 编译器**： * **定义**：JIT 编译器是一种在程序运行时对代码进行优化的技术。 * **工作原理**：JIT 编译器会分析程序的运行时行为，将频繁执行的热点代码编译成本地机器码，从而提高程序的执行效率。 * **优势**：JIT 编译器可以使 Java 程序在运行时达到接近本地代码的执行速度。 * **其他优化技术**： * **类加载机制优化**：Java 的类加载机制可以根据需要动态加载类，减少内存占用和加载时间。 * **多线程处理优化**：Java 提供了丰富的多线程编程支持，可以通过 `Thread` 类和 `Runnable` 接口来实现高效的并发编程。 #### JVM vs JDK vs JRE **Java 虚拟机（Java Virtual Machine，JVM）** Java 虚拟机（Java Virtual Machine, JVM）是运行 Java 字节码的虚拟机。JVM 有针对不同系统的特定实现（Windows，Linux，macOS），目的是使用相同的字节码，它们都会给出相同的结果。字节码和不同系统的 JVM 实现是 Java 语言“一次编译，随处可以运行”的关键所在。 **Java 开发工具包（Java Development Kit，JDK）** JDK（Java Development Kit）是一个功能齐全的 Java 开发工具包，供开发者使用，用于创建和编译 Java 程序。它包含了 JRE（Java Runtime Environment），以及编译器 javac 和其他工具，如 javadoc（文档生成器）、jdb（调试器）、jconsole（监控工具）、javap（反编译工具）等。 **Java 运行时环境（Java Runtime Environment，JRE）** JRE 是运行已编译 Java 程序所需的环境，主要包含**JVM**和**Java 基础类库（Class Library）**。Java 基础类库是一组标准的类库，提供常用的功能和 API（如 I/O 操作、网络通信、数据结构等）。不过，从 JDK 9 开始，就不需要区分 JDK 和 JRE 的关系了，取而代之的是模块系统（JDK 被重新组织成 94 个模块）+ jlink 工具 (随 Java 9 一起发布的新命令行工具，用于生成自定义 Java 运行时映像，该映像仅包含给定应用程序所需的模块) 。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-c6548e327dbfbb58bdd54cfc58ac5f806ed1930b%2FPasted%20image%2020250212125612.png?alt=media) ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-7978bd21a487140a22c9e7d40b2d68059dc8ff6d%2FPasted%20image%2020250212125824.png?alt=media) #### 什么是字节码？采用字节码的好处是什么？ 在 Java 中，JVM 可以理解的代码就叫做字节码（即扩展名为 `.class` 的文件），它不面向任何特定的处理器，只面向虚拟机。Java 语言通过字节码的方式，在一定程度上解决了传统解释型语言执行效率低的问题，同时又保留了解释型语言可移植的特点。 在 `.class->机器码` 这一步。在这一步 JVM 类加载器首先加载字节码文件，然后通过解释器逐行解释执行，这种方式的执行速度会相对比较慢。而且，有些方法和代码块是经常需要被调用的(也就是所谓的热点代码)，所以后面引进了 **JIT（Just in Time Compilation）** 编译器，**而 JIT 属于运行时编译。当 JIT 编译器完成第一次编译后，其会将字节码对应的机器码保存下来**，下次可以直接使用。而我们知道，机器码的运行效率肯定是高于 Java 解释器的。这也解释了我们为什么经常会说 **Java 是编译与解释共存的语言** 。 **编译型语言** 编译型语言会通过编译器将源代码一次性翻译成可被该平台执行的机器码。一般情况下，编译语言的执行速度比较快，开发效率比较低。常见的编译性语言有 C、C++、Go、Rust 等等。 **解释型语言** \*\*解释型语言会通过解释器一句一句的将代码解释（interpret）为机器代码后再执行。解释型语言开发效率比较快，执行速度比较慢。常见的解释性语言有 Python、JavaScript、PHP 等等。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-9147ab6066b85138f0d76cbc02cf2c96a7e828c4%2FPasted%20image%2020250212130040.png?alt=media) ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-6c9c92d7b509c1dbdf26f319cb59858d098cf8c0%2FPasted%20image%2020250212130110.jpg?alt=media) #### AOT 有什么优点？为什么不全部使用 AOT 呢？ JDK 9 引入了一种新的编译模式 **AOT（Ahead of Time Compilation）** 。和 JIT 不同的是，这种编译模式会在程序被执行前就将其编译成机器码，属于静态编译（C、 C++，Rust，Go 等语言就是静态编译）。AOT 避免了 JIT 预热等各方面的开销，可以提高 Java 程序的启动速度，避免预热时间长。并且，AOT 还能减少内存占用和增强 Java 程序的安全性（AOT 编译后的代码不容易被反编译和修改），特别适合云原生场景。 我们前面也对比过 JIT 与 AOT，两者各有优点，只能说 AOT 更适合当下的云原生场景，对微服务架构的支持也比较友好。除此之外，AOT 编译无法支持 Java 的一些动态特性，如反射、动态代理、动态加载、JNI（Java Native Interface）等。然而，很多框架和库（如 Spring、CGLIB）都用到了这些特性。如果只使用 AOT 编译，那就没办法使用这些框架和库了，或者说需要针对性地去做适配和优化。 **JDK17 移除了实验性的 AOT 与 JIT** **JDK17 的变动中移除了实验性的 AOT 与 JIT**。**Graal 编译器在 JDK 10 中作为实验性 JIT 编译器**。所以之前在 JDK10 以后，JVM（指HotSpot虚拟机）中的JIT是有三款的，即 C1（'客户端编译器”(Client Compiler)）、C2（“服务端编译器”(Server Compiler)）以及 Graal 编译器。**因此 JDK17 中移除的并非我们所认为的那个 JIT，而是 Graal 编译器以及基于 Graal 的 AOT。我们所认为的 JIT 其实就是C2。** OpenJDK 和 GraalVM 虽然都废弃了传统的 AOT 编译，但是两者都**不约而同**的探索 static-image 技术，假如有个 void foo() 方法，用传统的 AOT 如 jatoc，会把 foo 编译成二进制，而 static-image 会把 foo 编译成二进制，**同时**再带上语言运行时（比如GC、线程模型等），最终得到一个“**闭合的二进制世界**”。static-image 其实就是更广义的 AOT。 #### Java 和 C++ 的区别? **指针** Java 不提供指针来直接访问内存，程序内存更加安全。 **继承** Java 的类是单继承的，C++ 支持多重继承；虽然 Java 的类不可以多继承，但是接口可以多继承。 **垃圾回收** Java 有自动内存管理垃圾回收机制(GC)，不需要程序员手动释放无用内存。 **操作符重载** C++ 同时支持方法重载和操作符重载，但是 Java 只支持方法重载（操作符重载增加了复杂性，这与 Java 最初的设计思想不符）。 ### 基本语法 #### 注释有哪几种形式？ 1. **单行注释**：通常用于解释方法内某单行代码的作用。 2. **多行注释**：通常用于解释一段代码的作用。 3. **文档注释**：通常用于生成 Java 开发文档。 #### 标识符和关键字的区别是什么？ 简单来说， **标识符就是一个名字**，**关键字是被赋予特殊含义的标识符** 。 #### Java 语言关键字有哪些？ | 分类 | 关键字 | | | | | | | | ---------- | -------- | ---------- | -------- | ------------ | ---------- | --------- | ------ | | 访问控制 | private | protected | public | | | | | | 类，方法和变量修饰符 | abstract | class | extends | final | implements | interface | native | | | new | static | strictfp | synchronized | transient | volatile | enum | | 程序控制 | break | continue | return | do | while | if | else | | | for | instanceof | switch | case | default | assert | | | 错误处理 | try | catch | throw | throws | finally | | | | 包相关 | import | package | | | | | | | 基本类型 | boolean | byte | char | double | float | int | long | | | short | | | | | | | | 变量引用 | super | this | void | | | | | | 保留字 | goto | const | | | | | | #### 自增自减运算符 * **前缀形式**（例如 `++a` 或 `--a`）：先自增/自减变量的值，然后再使用该变量。 * **后缀形式**（例如 `a++` 或 `a--`）：先使用变量的当前值，然后再自增/自减变量的值。 ### 基本数据类型 #### Java 中的几种基本数据类型了解么？ Java 中有 8 种基本数据类型，分别为： * 6 种数字类型： * 4 种整数型：`byte`、`short`、`int`、`long` * 2 种浮点型：`float`、`double` * 1 种字符类型：`char` * 1 种布尔型：`boolean`。 #### 基本类型和包装类型的区别？ * **用途**：除了定义一些常量和局部变量之外，我们在其他地方比如方法参数、对象属性中很少会使用基本类型来定义变量。并且，包装类型可用于泛型，而基本类型不可以。 * **存储方式**：基本数据类型的局部变量存放在 Java 虚拟机栈中的**局部变量表**中，基本数据类型的成员变量（未被 `static` 修饰 ）存放在 Java 虚拟机的中。包装类型属于对象类型，我们知道**几乎所有对象实例都存在于堆中**。 * **占用空间**：相比于包装类型（对象类型）， 基本数据类型占用的空间往往非常小。 * **默认值**：成员变量包装类型不赋值就是 `null` ，而基本类型有默认值且不是 `null`。 * **比较方式**：对于基本数据类型来说，`==` 比较的是值。对于包装数据类型来说，`==` 比较的是对象的内存地址。所有整型包装类对象之间值的比较，全部使用 `equals()` 方法。 **为什么说是几乎所有对象实例都存在于堆中呢？** \*\*这是因为 HotSpot 虚拟机引入了 JIT 优化之后，会对对象进行逃逸分析，如果发现某一个对象并没有逃逸到方法外部，那么就可能通过标量替换来实现栈上分配，而避免堆上分配内存。 **基本数据类型存放在栈中是一个常见的误区** 基本数据类型的存储位置取决于它们的作用域和声明方式。如果它们是局部变量，那么它们会存放在栈中；如果它们是成员变量，那么它们会存放在堆/方法区/元空间中。 #### 包装类型的缓存机制了解么？ Java 基本数据类型的包装类型的大部分都用到了缓存机制来提升性能。 `Byte`,`Short`,`Integer`,`Long` 这 4 种包装类默认创建了数值 `[-128，127]` 的相应类型的缓存数据，`Character` 创建了数值在 `[0,127]` 范围的缓存数据，`Boolean` 直接返回 `True` or `False`。 #### 自动装箱与拆箱了解吗？原理是什么？ **什么是自动拆装箱？** * **装箱**：将基本类型用它们对应的引用类型包装起来； * **拆箱**：将包装类型转换为基本数据类型； 装箱其实就是调用了包装类的 `valueOf()` 方法，拆箱其实就是调用了 `xxxValue()` 方法。**如果频繁拆装箱的话，也会严重影响系统的性能。我们应该尽量避免不必要的拆装箱操作。** #### 如何解决浮点数运算的精度丢失问题？ `BigDecimal` 可以实现对浮点数的运算，不会造成精度丢失。通常情况下，大部分需要浮点数精确运算结果的业务场景（比如涉及到钱的场景）都是通过 `BigDecimal` 来做的。 ### 变量 #### 成员变量与局部变量的区别？ **语法形式** 从语法形式上看，成员变量是属于类的，而局部变量是在代码块或方法中定义的变量或是方法的参数；成员变量可以被 `public`，`private`，`static` 等修饰符所修饰，而局部变量不能被访问控制修饰符及 `static` 所修饰；但是，成员变量和局部变量都能被 `final` 所修饰。 **存储方式** 从变量在内存中的存储方式来看，如果成员变量是使用 `static` 修饰的，那么这个成员变量是属于类的，如果没有使用 `static` 修饰，这个成员变量是属于实例的。而对象存在于**堆内存**，局部变量则存在于**栈内存**。 **生存时间** 从变量在内存中的生存时间上看，成员变量是对象的一部分，它随着对象的创建而存在，而局部变量随着方法的调用而自动生成，随着方法的调用结束而消亡。 **默认值** 从变量是否有默认值来看，成员变量如果没有被赋初始值，则会自动以类型的默认值而赋值（一种情况例外:被 `final` 修饰的成员变量也必须显式地赋值），而局部变量则不会自动赋值。 #### 静态变量有什么作用？ 静态变量也就是被 `static` 关键字修饰的变量。**它可以被类的所有实例共享**，无论一个类创建了多少个对象，它们都共享同一份静态变量。也就是说，**静态变量只会被分配一次内存**，即使创建多个对象，这样可以节省内存。 #### 字符型常量和字符串常量的区别? * **形式** : 字符常量是单引号引起的一个字符，字符串常量是双引号引起的 0 个或若干个字符。 * **含义** : 字符常量相当于一个整型值（ASCII 值），可以参加表达式运算；字符串常量代表一个**地址值**（该字符串在内存中存放位置）。 * **占内存大小**：字符常量只占 2 个字节; 字符串常量占若干个字节。 ### 方法 #### 静态方法为什么不能调用非静态成员? 静态方法是属于类的，在**类加载的时候就会分配内存**，可以通过类名直接访问。而非静态成员属于实例对象，只有在对象实例化之后才存在，需要通过类的实例对象去访问。 **在类的非静态成员不存在的时候静态方法就已经存在了，此时调用在内存中还不存在的非静态成员，属于非法操作**。 #### 静态方法和实例方法有何不同？ **调用方式** 在外部调用静态方法时，可以使用 `类名.方法名` 的方式，也可以使用 `对象.方法名` 的方式，而实例方法只有后面这种方式。也就是说，**调用静态方法可以无需创建对象** 。 **访问类成员是否存在限制** 静态方法在访问本类的成员时，只允许访问静态成员（即静态成员变量和静态方法），不允许访问实例成员（即实例成员变量和实例方法），而实例方法不存在这个限制。 #### 重载和重写有什么区别？ 重载就是同一个类中多个同名方法根据不同的传参来执行不同的逻辑处理。**重写发生在运行期，是子类对父类的允许访问的方法的实现过程进行重新编写**。 #### 什么是可变长参数？ 从 Java5 开始，Java 支持定义可变长参数 `Xxx... args`，所谓可变长参数就是允许在调用方法时传入不定长度的参数。Java 的可变参数编译后实际会被转换成一个数组。 ### 面向对象基础 #### 面向对象和面向过程的区别 * **面向过程编程（POP）**：面向过程把解决问题的过程拆成一个个方法，通过一个个方法的执行解决问题。 * **面向对象编程（OOP）**：面向对象会先抽象出对象，然后用对象执行方法的方式解决问题。 #### 创建一个对象用什么运算符？对象实体与对象引用有何不同？ 当使用 `new` 关键字创建一个对象时，Java会执行以下步骤： * **分配内存**：在堆内存中为新对象分配空间。 * **初始化对象**：调用类的构造器，对对象进行初始化。这包括初始化成员变量和执行构造器中的代码。 * **返回对象引用**：`new` 关键字返回对新创建对象的引用，这个引用可以存储在一个变量中，对象引用存放在栈内存中。 **内存管理（对象实例在堆内存中，对象引用存放在栈内存中）** **new 创建对象实例（对象实例在堆内存中），对象引用指向对象实例（对象引用存放在栈内存中）**。 * **对象实例**：对象实例存在于堆内存中。每个对象实例在堆内存中占有独立的内存块。当对象实例不再被引用（强引用）时，Java的垃圾收集器（Garbage Collector）会自动回收该对象占用的内存。 * **对象引用**：对象引用存在于栈内存中。当你创建一个对象引用变量时，Java在栈内存中分配空间来存储这个引用。引用指向堆内存中的对象实例。引用变量的生命周期通常与它所在的作用域一致。 **赋值与复制** * **对象实例**：每次使用 `new` 关键字创建一个对象实例时，都会在堆内存中分配一个新的内存块，即使对象的内容完全相同，它们在内存中也是独立的。 * **对象引用**：当你将一个对象引用赋值给另一个对象引用时，它们指向同一个对象实例。 **参数传递** * **对象实例**：当对象实例作为参数传递时，实际上是传递了对象引用的副本。原始引用和副本引用都指向同一个对象实例。因此，在方法内部对对象的修改会影响到原始对象。 * **对象引用**：在Java中，对象引用作为参数传递时是**按值传递**（pass-by-value），即传递的是对象引用的副本，而不是对象实例的副本。这意味着你在方法中修改对象引用（`box = new Box(30)`）不会改变外部的引用，但你可以通过该引用修改对象实例的内容（`box.value = 20`）。 #### 创建对象的几种方式 **new 创建新的对象** ```java String str = new String("str"); ``` **反射机制** ```java public static void main(String[] args) throws Exception { // 获取类的Class对象 String str = (String)Class.forName("java.lang.String").newInstance(); } ``` **工厂方法** ```java public class DefaultPersonFactory implements PersonFactory { @Override public Person createPerson(String name) { return new Person(name); } } ``` **Object.clone()** ```java public class MyClass implements Cloneable { private int value; @Override public MyClass clone() throws CloneNotSupportedException { return (MyClass) super.clone(); } } ``` **序列化反序列化** ```java public class MyClass implements Serializable { private int value; private void writeObject(ObjectOutputStream out) throws IOException { out.writeInt(value * 2); } private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException { value = in.readInt(); } } ``` **Constructor 构造函数对象的 newInstance() 方法** 类 Constructor 也有newInstance方法，这一点和 Class 有点像。从它的名字可以看出它与 Class 的不同，Class 是通过类来创建对象，而 Constructor 则是通过构造器。 **依赖注入** ```java @Bean public Person person() { return new Person("John"); } public static void main(String[] args) { ApplicationContext context = new AnnotationConfigApplicationContext(AppConfig.class); Person person = context.getBean(Person.class); System.out.println(person.getName()); } ``` #### 对象的相等和引用相等的区别 * 对象的相等一般比较的是内存中存放的内容是否相等。 * 引用相等一般比较的是他们指向的内存地址是否相等。 #### 如果一个类没有声明构造方法，该程序能正确执行吗？ 如果一个类没有声明构造方法，也可以执行！因为一个类即使没有声明构造方法也会有默认的不带参数的构造方法。 #### 构造方法有哪些特点？是否可被 override? 构造方法**不能被重写（override）**，但**可以被重载（overload）**。 #### 面向对象三大特征 **封装** * 封装是指把一个对象的状态信息（也就是属性）隐藏在对象内部，不允许外部对象直接访问对象的内部信息。但是可以提供一些可以被外界访问的方法来操作属性。 | 访问范围 | private | default（默认） | protected | public | | -------- | ------- | ----------- | --------- | ------ | | 同一个类 | 可访问 | 可访问 | 可访问 | 可访问 | | 同一包中的其他类 | 不可访问 | 可访问 | 可访问 | 可访问 | | 不同包中的子类 | 不可访问 | 不可访问 | 可访问 | 可访问 | | 不同包中的非子类 | 不可访问 | 不可访问 | 不可访问 | 可访问 | **继承** * 子类拥有父类对象所有的属性和方法（包括私有属性和私有方法），但是父类中的私有属性和方法子类是无法访问，**只是拥有**。 * 子类可以拥有自己属性和方法，即子类可以对父类进行扩展。 * 子类可以用自己的方式实现父类的方法。 **多态** * 对象类型和引用类型之间具有继承（类）/实现（接口）的关系； * **引用类型变量发出的方法调用的到底是哪个类中的方法，必须在程序运行期间才能确定**； * 多态不能调用“只在子类存在但在父类不存在”的方法； * 如果子类重写了父类的方法，真正执行的是子类重写的方法，如果子类没有重写父类的方法，执行的是父类的方法。 #### 接口和抽象类有什么共同点和区别？ **接口和抽象类的共同点** **实例化** 接口和抽象类都不能直接实例化，只能被实现（接口）或继承（抽象类）后才能创建具体的对象。 **抽象方法** 接口和抽象类都可以包含抽象方法。抽象方法没有方法体，必须在子类或实现类中实现。 **接口和抽象类的区别** **设计目的** 接口主要用于对类的行为进行约束，你实现了某个接口就具有了对应的行为。抽象类主要用于代码复用，强调的是所属关系。 **继承和实现（单继承类，多继承接口）** 一个类只能继承一个类（包括抽象类），因为 Java 不支持多继承。但一个类可以实现多个接口，一个接口也可以继承多个其他接口。 **成员变量** **接口中的成员变量只能是 `public static final` 类型的，不能被修改且必须有初始值**。抽象类的成员变量可以有任何修饰符（`private`，`protected`，`public`），可以在子类中被重新定义或赋值。 **方法** 在 Java 8 及以上版本中，接口引入了新的方法类型：`default` 方法、`static` 方法和 `private` 方法。这些方法让接口的使用更加灵活。 抽象类可以包含抽象方法和非抽象方法。抽象方法没有方法体，必须在子类中实现。非抽象方法有具体实现，可以直接在抽象类中使用或在子类中重写。 #### 深拷贝和浅拷贝区别了解吗？什么是引用拷贝？ * **浅拷贝**（一般使用 `Java Object.clone()`）：浅拷贝会在堆上创建一个新的对象（区别于引用拷贝的一点），不过，如果原对象内部的属性是引用类型的话，浅拷贝会直接复制内部对象的引用地址，也就是说**拷贝对象和原对象共用同一个内部对象**。 * **深拷贝**（一般使用 序列化与反序列化）：深拷贝会完全复制整个对象，包括这个对象所包含的内部对象。 * **引用拷贝**：引用拷贝就是两个不同的引用指向同一个对象 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-452a99aafd75f7ac6dd433d3cb9fc9f6f4c94bf1%2FPasted%20image%2020250212141148.png?alt=media) ### Object #### Object 类的常见方法有哪些？ Object 类是一个特殊的类，是所有类的父类，主要提供了以下 11 个方法： ```java /** * native 方法，用于返回当前运行时对象的 Class 对象，使用了 final 关键字修饰，故不允许子类重写。 */ public final native Class getClass() /** * native 方法，用于返回对象的哈希码，主要使用在哈希表中，比如 JDK 中的HashMap。 */ public native int hashCode() /** * 用于比较 2 个对象的内存地址是否相等，String 类对该方法进行了重写以用于比较字符串的值是否相等。 */ public boolean equals(Object obj) /** * native 方法，用于创建并返回当前对象的一份拷贝。 */ protected native Object clone() throws CloneNotSupportedException /** * 返回类的名字实例的哈希码的 16 进制的字符串。建议 Object 所有的子类都重写这个方法。 */ public String toString() /** * native 方法，并且不能重写。唤醒一个在此对象监视器上等待的线程(监视器相当于就是锁的概念)。如果有多个线程在等待只会任意唤醒一个。 */ public final native void notify() /** * native 方法，并且不能重写。跟 notify 一样，唯一的区别就是会唤醒在此对象监视器上等待的所有线程，而不是一个线程。 */ public final native void notifyAll() /** * native方法，并且不能重写。暂停线程的执行。注意：sleep 方法没有释放锁，而 wait 方法释放了锁 ，timeout 是等待时间。 */ public final native void wait(long timeout) throws InterruptedException /** * 多了 nanos 参数，这个参数表示额外时间（以纳秒为单位，范围是 0-999999）。 所以超时的时间还需要加上 nanos 纳秒。。 */ public final void wait(long timeout, int nanos) throws InterruptedException /** * 跟之前的2个wait方法一样，只不过该方法一直等待，没有超时时间这个概念 */ public final void wait() throws InterruptedException /** * 实例被垃圾回收器回收的时候触发的操作 */ protected void finalize() throws Throwable { } ``` #### == 和 equals() 的区别 **`==`** 对于基本类型和引用类型的作用效果是不同的： * 对于基本数据类型来说，`==` 比较的是值。 * 对于引用数据类型来说，`==` 比较的是对象的内存地址。 `equals()` 方法存在两种使用情况： * **类没有重写 `equals()` 方法**：通过 `equals()` 比较该类的两个对象时，等价于通过 `==` 比较这两个对象，使用的默认是 `Object` 类 `equals()` 方法。 * **类重写了 `equals()` 方法**：一般我们都重写 `equals()` 方法来比较两个对象中的属性是否相等；若它们的属性相等，则返回 true（即，认为这两个对象相等）。 当创建 `String` 类型的对象时，虚拟机会在常量池中查找有没有已经存在的值和要创建的值相同的对象，如果有就把它赋给当前引用。如果没有就在常量池中重新创建一个 `String` 对象。 因为 Java 只有值传递，所以，对于 == 来说，不管是比较基本数据类型，还是引用数据类型的变量，其本质比较的都是值，只是引用类型变量存的值是对象的地址。 ```java String a = new String("ab"); // a 为一个引用 String b = new String("ab"); // b为另一个引用,对象的内容一样 String aa = "ab"; // 放在常量池中 String bb = "ab"; // 从常量池中查找 System.out.println(aa == bb);// true System.out.println(a == b);// false System.out.println(a.equals(b));// true ``` #### hashCode() 有什么用？ `hashCode()` 的作用是获取哈希码（`int` 整数），也称为散列码。这个哈希码的作用是确定该对象在哈希表中的索引位置。 `hashCode()` 定义在 JDK 的 `Object` 类中，这就意味着 Java 中的任何类都包含有 `hashCode()` 函数。另外需要注意的是：`Object` 的 `hashCode()` 方法是本地方法，也就是用 C 语言或 C++ 实现的。 散列表存储的是键值对（key-value），它的特点是：**能根据“键”快速的检索出对应的“值”。这其中就利用到了散列码！** #### 为什么要有 hashCode？ 当你把对象加入 `HashSet` 时，`HashSet` 会先计算对象的 `hashCode` 值来判断对象加入的位置，同时也会与其他已经加入的对象的 `hashCode` 值作比较，如果没有相符的 `hashCode`，`HashSet` 会假设对象没有重复出现。但是如果发现有相同 `hashCode` 值的对象，这时会调用 `equals()` 方法来检查 `hashCode` 相等的对象是否真的相同。如果两者相同，`HashSet` 就不会让其加入操作成功。如果不同的话，就会重新散列到其他位置。这样我们就大大减少了 `equals` 的次数，相应就大大提高了执行速度。 其实，`hashCode()` 和 `equals()` 都是用于比较两个对象是否相等。 * 如果两个对象的`hashCode` 值相等，那这两个对象不一定相等（哈希碰撞）。 * 如果两个对象的`hashCode` 值相等并且`equals()`方法也返回 `true`，我们才认为这两个对象相等。 * 如果两个对象的`hashCode` 值不相等，我们就可以直接认为这两个对象不相等。 #### 为什么重写 equals() 时必须重写 hashCode() 方法？ 因为两个相等的对象的 `hashCode` 值必须是相等。也就是说如果 `equals` 方法判断两个对象是相等的，那这两个对象的 `hashCode` 值也要相等。 ### String #### String、StringBuffer、StringBuilder 的区别？ **可变性（String 不可变，StringBuffer StringBuilder 可变）** `String` 是不可变的。 `StringBuilder` 与 `StringBuffer` 都继承自 `AbstractStringBuilder` 类，在 `AbstractStringBuilder` 中也是使用字符数组保存字符串，不过没有使用 `final` 和 `private` 关键字修饰，最关键的是这个 `AbstractStringBuilder` 类还提供了很多修改字符串的方法比如 `append` 方法。 **线程安全性（String StringBuffer 线程安全，StringBuilder 非线程安全）** **`String` 中的对象是不可变的，也就可以理解为常量，线程安全。`StringBuffer` 对方法加了同步锁或者对调用的方法加了同步锁，所以是线程安全的。`StringBuilder` 并没有对方法进行加同步锁，所以是非线程安全的。** **性能（StringBuilder > StringBuffer >> String）** **每次对 `String` 类型进行改变的时候，都会生成一个新的 `String` 对象**，然后将指针指向新的 `String` 对象。`StringBuffer` 每次都会对 `StringBuffer` 对象本身进行操作，而不是生成新的对象并改变对象引用。相同情况下使用 `StringBuilder` 相比使用 `StringBuffer` 仅能获得 10%\~15% 左右的性能提升，但却要冒多线程不安全的风险。 #### String 为什么是不可变的? `String` 类中使用 `final` 关键字修饰字符数组来保存字符串，~~所以`String` 对象是不可变的。~~ **我们知道被 `final` 关键字修饰的类不能被继承，修饰的方法不能被重写，修饰的变量是基本数据类型则值不能改变，修饰的变量是引用类型则不能再指向其他对象。因此，`final` 关键字修饰的数组保存字符串并不是 `String` 不可变的根本原因，因为这个数组保存的字符串是可变的（`final` 修饰引用类型变量的情况）。** **`String` 真正不可变原因** 保存字符串的数组被 `final` 修饰且为私有的，并且 `String` 类没有提供/暴露修改这个字符串的方法。 `String` 类被 `final` 修饰导致其不能被继承，进而避免了子类破坏 `String` 不可变。 #### 字符串拼接用 “+” 还是 StringBuilder? Java 语言本身并不支持运算符重载，“+” 和 “+=” 是专门为 String 类重载过的运算符，也是 Java 中仅有的两个重载过的运算符。 字符串对象通过 “+” 的字符串拼接方式，实际上是通过 `StringBuilder` 调用 `append()` 方法实现的，拼接完成之后调用 `toString()` 得到一个 `String` 对象 。 不过，在循环内使用 “+” 进行字符串的拼接的话，存在比较明显的缺陷：**编译器不会创建单个 `StringBuilder` 以复用，会导致创建过多的 `StringBuilder` 对象**。 #### 字符串常量池的作用了解吗？ **字符串常量池** 是 JVM 为了提升性能和减少内存消耗针对字符串（String 类）专门开辟的一块区域，主要目的是为了避免字符串的重复创建。 #### String s1 = new String("abc"); 这句话创建了几个字符串对象？ 先说答案：会创建 1 或 2 个字符串对象。 * 字符串常量池中不存在 "abc"：会创建 2 个 字符串对象。一个在字符串常量池中，由 `ldc` 指令触发创建。一个在堆中，由 `new String()` 创建，并使用常量池中的 "abc" 进行初始化。 * 字符串常量池中已存在 "abc"：会创建 1 个 字符串对象。该对象在堆中，由 `new String()` 创建，并使用常量池中的 "abc" 进行初始化。 对于字符串常量，`ldc` 指令的行为如下： * **从常量池加载字符串**：`ldc` 首先检查字符串常量池中是否已经有内容相同的字符串对象。 * **复用已有字符串对象**：如果字符串常量池中已经存在内容相同的字符串对象，`ldc` 会将该对象的引用加载到操作数栈上。 * **没有则创建新对象并加入常量池**：如果字符串常量池中没有相同内容的字符串对象，JVM 会在常量池中创建一个新的字符串对象，并将其引用加载到操作数栈中。 #### String.intern 方法有什么作用? `String.intern()` 是一个 `native` (本地) 方法，用来处理字符串常量池中的字符串对象引用。它的工作流程可以概括为以下两种情况： * **常量池中已有相同内容的字符串对象**：如果字符串常量池中已经有一个与调用 `intern()` 方法的字符串内容相同的 `String` 对象，`intern()` 方法会直接返回常量池中该对象的引用。 * **常量池中没有相同内容的字符串对象**：如果字符串常量池中还没有一个与调用 `intern()` 方法的字符串内容相同的对象，`intern()` 方法会将当前字符串对象的引用添加到字符串常量池中，并返回该引用。 #### String 类型的变量和常量做“+”运算时发生了什么？ **对于编译期可以确定值的字符串，也就是常量字符串 ，jvm 会将其存入字符串常量池。并且，字符串常量拼接得到的字符串常量在编译阶段就已经被存放字符串常量池，这个得益于编译器的优化。** 常量折叠会把常量表达式的值求出来作为常量嵌在最终生成的代码中，这是 Javac 编译器会对源代码做的极少量优化措施之一（代码优化几乎都在即时编译器中进行）。 并不是所有的常量都会进行折叠，只有编译器在程序编译期就可以确定值的常量才可以，**引用的值在程序编译期是无法确定的，编译器无法对其进行优化。** ### 异常 #### Java 异常类层次结构图 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-2d5b496a9815ebc8374093e8274da861a82e324e%2FPasted%20image%2020250212145813.png?alt=media) #### Exception 和 Error 有什么区别？ 在 Java 中，所有的异常都有一个共同的祖先 `java.lang` 包中的 `Throwable` 类。`Throwable` 类有两个重要的子类: * **`Exception`** :程序本身可以处理的异常，可以通过 `catch` 来进行捕获。`Exception` 又可以分为 Checked Exception (受检查异常，必须处理) 和 Unchecked Exception (不受检查异常，可以不处理)。 * **`Error`**：`Error` 属于程序无法处理的错误 ，不建议通过 `catch` 获 。例如 Java 虚拟机运行错误（`Virtual MachineError`）、虚拟机内存不够错误(`OutOfMemoryError`)、类定义错误（`NoClassDefFoundError`）等 。这些异常发生时，Java 虚拟机（JVM）一般会选择线程终止。 #### Checked Exception 和 Unchecked Exception 有什么区别？ **Checked Exception** 即 **受检查异常**，Java 代码在编译过程中，如果受检查异常没有被 `catch` 或者 `throws` 关键字处理的话，就没办法通过编译。 **Unchecked Exception** 即 **不受检查异常** ，Java 代码在编译过程中 ，我们即使不处理不受检查异常也可以正常通过编译，`RuntimeException` 及其子类都统称为非受检查异常。 #### Throwable 类常用方法有哪些？ * `String getMessage()`: 返回异常发生时的详细信息 * `String toString()`: 返回异常发生时的简要描述 * `String getLocalizedMessage()`: 返回异常对象的本地化信息。使用 `Throwable` 的子类覆盖这个方法，可以生成本地化信息。如果子类没有覆盖该方法，则该方法返回的信息与 `getMessage()`返回的结果相同 * `void printStackTrace()`: 在控制台上打印 `Throwable` 对象封装的异常信息 #### try-catch-finally 如何使用？ * `try`块：用于捕获异常。其后可接零个或多个 `catch` 块，如果没有 `catch` 块，则必须跟一个 `finally` 块。 * `catch`块：用于处理 try 捕获到的异常。 * `finally` 块：无论是否捕获或处理异常，`finally` 块里的语句都会被执行。当在 `try` 块或 `catch` 块中遇到 `return` 语句时，`finally` 语句块将在方法返回之前被执行。 **不要在 finally 语句块中使用 return!** 当 try 语句和 finally 语句中都有 return 语句时，try 语句块中的 return 语句会被忽略。这是因为 try 语句中的 return 返回值会先被暂存在一个本地变量中，当执行到 finally 语句中的 return 之后，这个本地变量的值就变为了 finally 语句中的 return 返回值。 #### finally 中的代码一定会执行吗？ 不一定的！就比如说 finally 之前虚拟机被终止运行的话，finally 中的代码就不会被执行。另外，在以下 2 种特殊情况下，`finally` 块的代码也不会被执行： * 程序所在的线程死亡。 * 关闭 CPU。 #### 如何使用 `try-with-resources` 代替 `try-catch-finally`？ * **适用范围（资源的定义）：** 任何实现 `java.lang.AutoCloseable`或者 `java.io.Closeable` 的对象 * **关闭资源和 finally 块的执行顺序：** 在 `try-with-resources` 语句中，任何 catch 或 finally 块在声明的资源关闭后运行 ```java try (BufferedInputStream bin = new BufferedInputStream(new FileInputStream(new File("test.txt"))); BufferedOutputStream bout = new BufferedOutputStream(new FileOutputStream(new File("out.txt")))) { int b; while ((b = bin.read()) != -1) { bout.write(b); } } catch (IOException e) { e.printStackTrace(); } ``` #### 异常使用有哪些需要注意的地方？ * 不要把异常定义为静态变量，因为这样会导致异常栈信息错乱。每次手动抛出异常，我们都需要手动 new 一个异常对象抛出。 * 抛出的异常信息一定要有意义。 * 建议抛出更加具体的异常。 * 避免重复记录日志：如果在捕获异常的地方已经记录了足够的信息（包括异常类型、错误信息和堆栈跟踪等），那么在业务代码中再次抛出这个异常时，就不应该再次记录相同的错误信息。重复记录日志会使得日志文件膨胀，并且可能会掩盖问题的实际原因，使得问题更难以追踪和解决。 ### 注解 #### 何谓注解？ `Annotation` （注解） 是 Java5 开始引入的新特性，可以看作是一种特殊的注释，主要用于修饰类、方法或者变量，提供某些信息供程序在编译或者运行时使用。 #### 注解的解析方法有哪几种？ 注解只有被解析之后才会生效，常见的解析方法有两种： * **编译期直接扫描**：编译器在编译 Java 代码的时候扫描对应的注解并处理，比如某个方法使用`@Override` 注解，编译器在编译的时候就会检测当前的方法是否重写了父类对应的方法。 * **运行期通过反射处理**：像框架中自带的注解(比如 Spring 框架的 `@Value`、`@Component`)都是通过反射来进行处理的。 ### SPI #### 何谓 SPI? SPI 即 Service Provider Interface ，字面意思就是：“服务提供者的接口”，SPI 将服务接口和具体的服务实现分离开来，将服务调用方和服务实现者解耦，能够提升程序的扩展性、可维护性。修改或者替换服务实现并不需要修改调用方。 #### SPI 和 API 有什么区别？ 一般模块之间都是通过接口进行通讯，因此我们在服务调用方和服务实现方（也称服务提供者）之间引入一个“接口”。 * 当实现方提供了接口和实现，我们可以通过调用实现方的接口从而拥有实现方给我们提供的能力，这就是 **API**。这种情况下，**接口和实现都是放在实现方的包中。调用方通过接口调用实现方的功能，而不需要关心具体的实现细节**。 * 当接口存在于调用方这边时，这就是 **SPI** 。**由接口调用方确定接口规则，然后由不同的厂商根据这个规则对这个接口进行实现，从而提供服务**。 #### SPI 的优缺点？ 通过 SPI 机制能够大大地提高接口设计的灵活性，但是 SPI 机制也存在一些缺点： * 需要遍历加载所有的实现类，不能做到按需加载，这样效率还是相对较低的。 * 当多个 `ServiceLoader` 同时 `load` 时，会有并发问题。 ### I/O #### Java IO 流了解吗？ IO 即 `Input/Output`，输入和输出。数据输入到计算机内存的过程即输入，反之输出到外部存储（比如数据库，文件，远程主机）的过程即输出。数据传输过程类似于水流，因此称为 IO 流。IO 流在 Java 中分为输入流和输出流，而根据数据的处理方式又分为字节流和字符流。 Java IO 流的 40 多个类都是从如下 4 个抽象类基类中派生出来的。 * `InputStream`/`Reader`: 所有的输入流的基类，前者是字节输入流，后者是字符输入流。 * `OutputStream`/`Writer`: 所有输出流的基类，前者是字节输出流，后者是字符输出流。 #### I/O 流为什么要分为字节流和字符流呢? 问题本质想问：**不管是文件读写还是网络发送接收，信息的最小存储单元都是字节，那为什么 I/O 流操作要分为字节流操作和字符流操作呢？** * 字符流是由 Java 虚拟机将字节转换得到的，这个过程还算是比较耗时； * 如果我们不知道编码类型的话，使用字节流的过程中很容易出现乱码问题。 ### Java 泛型通配符详解 #### 什么是泛型？有什么作用？ **Java 泛型（Generics）** 是 JDK 5 中引入的一个新特性。使用泛型参数，可以增强代码的可读性以及稳定性。 编译器可以对泛型参数进行检测，并且通过泛型参数可以指定传入的对象类型。 #### 泛型的使用方式有哪几种？ 泛型一般有三种使用方式:**泛型类**、**泛型接口**、**泛型方法**。 `public static < E > void printArray( E[] inputArray )` 一般被称为静态泛型方法；在 java 中泛型只是一个占位符，必须在传递类型后才能使用。类在实例化时才能真正的传递类型参数，由于静态方法的加载先于类的实例化，也就是说类中的泛型还没有传递真正的类型参数，静态的方法的加载就已经完成了，所以静态泛型方法是没有办法使用类上声明的泛型的。只能使用自己声明的 `` #### 项目中哪里用到了泛型？ * 自定义接口通用返回结果 `CommonResult` 通过参数 `T` 可根据具体的返回类型动态指定结果的数据类型 * 定义 `Excel` 处理类 `ExcelUtil` 用于动态指定 `Excel` 导出的数据类型 * 构建集合工具类（参考 `Collections` 中的 `sort`, `binarySearch` 方法）。 ### Java 序列化详解 #### 什么是序列化？什么是反序列化？ 如果我们需要持久化 Java 对象比如将 Java 对象保存在文件中，或者在网络传输 Java 对象，这些场景都需要用到序列化。 * **序列化**：将数据结构或对象转换成可以存储或传输的形式，通常是二进制字节流，也可以是 JSON, XML 等文本格式。**序列化的主要目的是通过网络传输对象或者说是将对象存储到文件系统、数据库、内存中。** * **反序列化**：将在序列化过程中所生成的数据转换为原始数据结构或者对象的过程。 **序列化协议对应于 TCP/IP 4 层模型的哪一层** TCP/IP 四层模型是下面这样的，序列化协议属于哪一层呢？ 1. 应用层 2. 传输层 3. 网络层 4. 网络接口层 OSI 七层协议模型中，表示层做的事情主要就是对应用层的用户数据进行处理转换为二进制流。反过来的话，就是将二进制流转换成应用层的用户数据。因为，OSI 七层协议模型中的应用层、表示层和会话层对应的都是 TCP/IP 四层模型中的应用层，所以序列化协议属于 TCP/IP 协议应用层的一部分。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-3f827d5d7912423ec4ced21c1695bad0f34b7b26%2FPasted%20image%2020250212152313.png?alt=media) #### 常见序列化协议有哪些？ JDK 自带的序列化方式一般不会用 ，因为序列化效率低并且存在安全问题。比较常用的序列化协议有 Hessian、Kryo、Protobuf、ProtoStuff，这些都是基于二进制的序列化协议。 像 JSON 和 XML 这种属于文本类序列化方式。虽然可读性比较好，但是性能较差，一般不会选择。 #### JDK 自带的序列化方式 JDK 自带的序列化，只需实现 `java.io.Serializable`接口即可。 **serialVersionUID 有什么作用？** 序列化号 `serialVersionUID` 属于版本控制的作用。反序列化时，会检查 `serialVersionUID` 是否和当前类的 `serialVersionUID` 一致。如果 `serialVersionUID` 不一致则会抛出 `InvalidClassException` 异常。 **serialVersionUID 不是被 static 变量修饰了吗？为什么还会被“序列化”？** `static` 修饰的变量是静态变量，属于类而非类的实例，本身是不会被序列化的。然而，`serialVersionUID` 是一个特例，`serialVersionUID` 的序列化做了特殊处理。`serialVersionUID` 只是用来被 JVM 识别，实际并没有被序列化。 #### 如果有些字段不想进行序列化怎么办？ 对于不想进行序列化的变量，使用 `transient` 关键字修饰。 `transient` 关键字的作用是：阻止实例中那些用此关键字修饰的的变量序列化；当对象被反序列化时，被 `transient` 修饰的变量值不会被持久化和恢复。 * `transient` 只能修饰变量，不能修饰类和方法。 * `transient` 修饰的变量，在反序列化后变量值将会被置成类型的默认值。 * `static` 变量因为不属于任何对象（Object），所以无论有没有 `transient` 关键字修饰，均不会被序列化。 #### 为什么不推荐使用 JDK 自带的序列化？ * **不支持跨语言调用** : 如果调用的是其他语言开发的服务的时候就不支持了。 * **性能差**：相比于其他序列化框架性能更低，主要原因是序列化之后的字节数组体积较大，导致传输成本加大。 * **存在安全问题**：序列化和反序列化本身并不存在问题。但当输入的反序列化的数据可被用户控制，那么攻击者即可通过构造恶意输入，让反序列化产生非预期的对象，在此过程中执行构造的任意代码。 ### Java 反射机制详解 #### 何谓反射？ 反射之所以被称为框架的灵魂，主要是因为它赋予了我们**在运行时分析类以及执行类中方法的能力。通过反射你可以获取任意一个类的所有属性和方法，你还可以调用这些方法和属性。** #### 反射的优缺点？ 反射可以让我们的代码更加灵活、为各种框架提供开箱即用的功能提供了便利。 不过，反射让我们在运行时有了分析操作类的能力的同时，这同样也增加了安全问题，比如可以无视泛型参数的安全检查（泛型参数的安全检查发生在编译时）。另外，反射的性能也要稍差点，不过，对于框架来说实际是影响不大的。 #### 反射的应用场景？ **框架中大量使用了动态代理，而动态代理的实现也依赖反射**。另外，Java 中的一大利器 **注解** 的实现也用到了反射，基于反射分析类，然后获取到类/属性/方法/方法的参数上的注解。你获取到注解之后，就可以做进一步的处理。 #### 反射实战 **获取 Class 对象的四种方式** 1. 知道具体类的情况下可以使用 `Xxx.class` 2. 通过 `Class.forName()`传入类的全路径获取 3. 通过对象实例`instance.getClass()`获取 4. 通过类加载器`xxxClassLoader.loadClass()`传入类路径获取 **反射的一些基本操作** ### Java 语法糖详解 #### 什么是语法糖？ **语法糖（Syntactic Sugar）** 也称糖衣语法，指在计算机语言中添加的某种语法，这种语法对语言的功能并没有影响，但是更方便程序员使用。 但其实， **Java 虚拟机并不支持这些语法糖。这些语法糖在编译阶段就会被还原成简单的基础语法结构，这个过程就是解语法糖。** #### Java 中有哪些常见的语法糖？ Java 中最常用的语法糖主要有泛型、自动拆装箱、变长参数、枚举、内部类、增强 for 循环、try-with-resources 语法、lambda 表达式等。 #### switch 支持 String 与枚举 **字符串的 switch 是通过`equals()`和`hashCode()`方法来实现的。** 还好`hashCode()`方法返回的是`int`，而不是`long`。 #### 泛型 通常情况下，一个编译器处理泛型有两种方式：`Code specialization` 和 `Code sharing`。C++和 C#是使用 `Code specialization` 的处理机制，而 Java 使用的是 `Code sharing` 的机制。 Code sharing 方式为每个泛型类型创建唯一的字节码表示，并且将该泛型类型的实例都映射到这个唯一的字节码表示上。将多种泛型类形实例映射到唯一的字节码表示是通过类型擦除（`type erasue`）实现的。 也就是说，\*\*对于 Java 虚拟机来说，他根本不认识`Map map`这样的语法。需要在编译阶段通过类型擦除的方式进行解语法糖。 \*\*虚拟机中没有泛型，只有普通类和普通方法，所有泛型类的类型参数在编译时都会被擦除，泛型类并没有自己独有的`Class`类对象。比如并不存在`List.class`或是`List.class`，而只有`List.class`。 #### 自动装箱与拆箱 自动装箱就是 Java 自动将原始类型值转换成对应的对象，反之叫做拆箱。因为这里的装箱和拆箱是自动进行的非人为转换，所以就称作为自动装箱和拆箱。 **装箱过程是通过调用包装器的 valueOf 方法实现的，而拆箱过程是通过调用包装器的 xxxValue 方法实现的。** #### 可变长参数 可变参数在被使用的时候，他首先会创建一个数组，数组的长度就是调用该方法是传递的实参的个数，然后再把参数值全部放到这个数组当中，然后再把这个数组作为参数传递到被调用的方法中。 #### 枚举 **当我们使用 `enum` 来定义一个枚举类型的时候，编译器会自动帮我们创建一个 `final` 类型的类继承 `Enum` 类，所以枚举类型不能被继承。** #### 内部类 内部类之所以也是语法糖，是因为它仅仅是一个编译时的概念，`outer.java`里面定义了一个内部类`inner`，一旦编译成功，就会生成两个完全不同的`.class`文件了，分别是`outer.class`和`outer$inner.class`。所以内部类的名字完全可以和它的外部类名字相同。 **为什么内部类可以使用外部类的 private 属性** 实际上，在编译完成之后，inner 实例内部会有指向 outer 实例的引用`this$0`，但是简单的`outer.name`是无法访问 private 属性的。从反编译的结果可以看到，outer 中会有一个桥方法`static String access$000(OutterClass)`，恰好返回 String 类型，即 userName 属性。正是通过这个方法实现内部类访问外部类私有属性。 #### 条件编译 —般情况下，程序中的每一行代码都要参加编译。但有时候出于对程序代码优化的考虑，希望只对其中一部分内容进行编译，此时就需要在程序中加上条件，让编译器只对满足条件的代码进行编译，将不满足条件的代码舍弃，这就是条件编译。 Java 语法的条件编译，是通过判断条件为常量的 if 语句实现的。其原理也是 Java 语言的语法糖。根据 if 判断条件的真假，编译器直接把分支为 false 的代码块消除。通过该方式实现的条件编译，必须在方法体内实现，而无法在整个 Java 类的结构或者类的属性上进行条件编译。 #### 断言 \*\*断言的底层实现就是 if 语言，如果断言结果为 true，则什么都不做，程序继续执行，如果断言结果为 false，则程序抛出 AssertError 来打断程序的执行。 #### 数值字面量 **编译器并不认识在数字字面量中的`_`，需要在编译阶段把他去掉。** #### for-each **for-each 的实现原理其实就是使用了普通的 for 循环和迭代器。** #### try-with-resource **那些我们没有做的关闭资源的操作，编译器都帮我们做了。所以，再次印证了，语法糖的作用就是方便程序员的使用，但最终还是要转成编译器认识的语言。** #### Lambda 表达式 **Lambda 表达式不是匿名内部类的语法糖，但是他也是一个语法糖。lambda 表达式的实现其实是依赖了一些 JVM 底层的 api，在编译阶段，编译器会把 lambda 表达式进行解糖，转换成调用内部 api 的方式。** #### 可能遇到的坑 **泛型** **当泛型遇到重载** 参数 `List` 和 `List` 编译之后都被擦除了，变成了一样的原生类型 List，擦除动作导致这两个方法的特征签名变得一模一样。 **当泛型遇到 catch** 泛型的类型参数不能用在 Java 异常处理的 catch 语句中。因为异常处理是由 JVM 在运行时刻来进行的。由于类型信息被擦除，JVM 是无法区分两个异常类型。 **当泛型内包含静态变量** 由于经过类型擦除，所有的泛型类实例都关联到同一份字节码上，泛型类的静态变量是共享的。 **自动装箱与拆箱** **对象相等比较** 在 Java 5 中，在 Integer 的操作上引入了一个新功能来节省内存和提高性能。整型对象通过使用相同的对象引用实现了缓存和重用。 * 适用于整数值区间 -128 至 +127。 * 只适用于自动装箱。使用构造函数创建对象不适用。 ```java public static void main(String[] args) { Integer a = 1000; Integer b = 1000; Integer c = 100; Integer d = 100; System.out.println("a == b is " + (a == b)); System.out.println(("c == d is " + (c == d))); } a == b is false c == d is true ``` **增强 for 循环** Iterator 是工作在一个独立的线程中，并且拥有一个 mutex 锁。 Iterator 被创建之后会建立一个指向原来对象的单链索引表，当原来的对象数量发生变化时，这个索引表的内容不会同步改变，所以当索引指针往后移动的时候就找不到要迭代的对象，所以按照 fail-fast 原则 Iterator 会马上抛出`java.util.ConcurrentModificationException`异常。 所以 `Iterator` 在工作的时候是不允许被迭代的对象被改变的。但你可以使用 `Iterator` 本身的方法 `remove()` 来删除对象，`Iterator.remove()` 方法会在删除当前迭代对象的同时维护索引的一致性。 ### Java 值传递详解 #### 形参&实参 方法的定义可能会用到 **参数**（有参的方法），参数在程序语言中分为： * **实参（实际参数，Arguments）**：用于传递给函数/方法的参数，必须有确定的值。 * **形参（形式参数，Parameters）**：用于定义函数/方法，接收实参，不需要有确定的值。 #### 值传递&引用传递 程序设计语言将实参传递给方法（或函数）的方式分为两种： * **值传递**：方法接收的是实参值的拷贝，会创建副本。 * **引用传递**：方法接收的直接是实参所引用的对象在堆中的地址，不会创建副本，对形参的修改将影响到实参。 Java 中将实参传递给方法（或函数）的方式是 **值传递**： * 如果参数是基本类型的话，很简单，传递的就是基本类型的字面量值的拷贝，会创建副本。 * 如果参数是引用类型，传递的就是实参所引用的对象在堆中地址值的拷贝，同样也会创建副本。 #### 为什么 Java 不引入引用传递呢？ 出于安全考虑，方法内部对值进行的操作，对于调用者都是未知的（把方法定义为接口，调用方不关心具体实现）。 ### Java 代理模式详解 #### 代理模式 **我们使用代理对象来代替对真实对象（real object）的访问，这样就可以在不修改原目标对象的前提下，提供额外的功能操作，扩展目标对象的功能。** **代理模式的主要作用是扩展目标对象的功能，比如说在目标对象的某个方法执行前后你可以增加一些自定义的操作。** #### 静态代理 **静态代理中，我们对目标对象的每个方法的增强都是手动完成的，非常不灵活（比如接口一旦新增加方法，目标对象和代理对象都要进行修改）且麻烦(需要对每个目标类都单独写一个代理类）。** 实际应用场景非常非常少，日常开发几乎看不到使用静态代理的场景。 从 JVM 层面来说，**静态代理在编译时就将接口、实现类、代理类这些都变成了一个个实际的 class 文件。** **静态代理实现步骤** * 定义一个接口及其实现类； * 创建一个代理类同样实现这个接口 * 将目标对象注入进代理类，然后在代理类的对应方法调用目标类中的对应方法。这样的话，我们就可以通过代理类屏蔽对目标对象的访问，并且可以在目标方法执行前后做一些自己想做的事情。 #### 动态代理 相比于静态代理来说，动态代理更加灵活。我们不需要针对每个目标类都单独创建一个代理类，并且也不需要我们必须实现接口，我们可以直接代理实现类（*CGLIB 动态代理机制*）。 **从 JVM 角度来说，动态代理是在运行时动态生成类字节码，并加载到 JVM 中的。** **动态代理在我们日常开发中使用的相对较少，但是在框架中的几乎是必用的一门技术。学会了动态代理之后，对于我们理解和学习各种框架的原理也非常有帮助。** 就 Java 来说，动态代理的实现方式有很多种，比如 **JDK 动态代理**、**CGLIB 动态代理**等等。 #### JDK 动态代理机制 **介绍** **在 Java 动态代理机制中 `InvocationHandler` 接口和 `Proxy` 类是核心。** `Proxy` 类中使用频率最高的方法是：`newProxyInstance()` ，这个方法主要用来生成一个代理对象。 **JDK 动态代理类使用步骤** * 定义一个接口及其实现类； * 自定义 `InvocationHandler` 并重写`invoke`方法，在 `invoke` 方法中我们会调用原生方法（被代理类的方法）并自定义一些处理逻辑； * 通过 `Proxy.newProxyInstance(ClassLoader loader,Class[] interfaces,InvocationHandler h)` 方法创建代理对象； `invoke()` 方法: 当我们的动态代理对象调用原生方法的时候，最终实际上调用到的是 `invoke()` 方法，然后 `invoke()` 方法代替我们去调用了被代理对象的原生方法。 ```java public class DebugInvocationHandler implements InvocationHandler { /** * 代理类中的真实对象 */ private final Object target; public DebugInvocationHandler(Object target) { this.target = target; } @Override public Object invoke(Object proxy, Method method, Object[] args) throws InvocationTargetException, IllegalAccessException { //调用方法之前，我们可以添加自己的操作 System.out.println("before method " + method.getName()); Object result = method.invoke(target, args); //调用方法之后，我们同样可以添加自己的操作 System.out.println("after method " + method.getName()); return result; } } ``` #### CGLIB 动态代理机制 **介绍** **JDK 动态代理有一个最致命的问题是其只能代理实现了接口的类。为了解决这个问题，我们可以用 CGLIB 动态代理机制来避免。** CGLIB（Code Generation Library）是一个基于 ASM 的字节码生成库，它允许我们在运行时对字节码进行修改和动态生成。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; } ``` **CGLIB 动态代理类使用步骤** * 定义一个类； * 自定义 `MethodInterceptor` 并重写 `intercept` 方法，`intercept` 用于拦截增强被代理类的方法，和 JDK 动态代理中的 `invoke` 方法类似； * 通过 `Enhancer` 类的 `create()`创建代理类； **JDK 动态代理和 CGLIB 动态代理对比** * **JDK 动态代理只能代理实现了接口的类或者直接代理接口，而 CGLIB 可以代理未实现任何接口的类。** 另外， CGLIB 动态代理是通过生成一个被代理类的子类来拦截被代理类的方法调用，因此不能代理声明为 final 类型的类和方法。 * 就二者的效率来说，大部分情况都是 JDK 动态代理更优秀，随着 JDK 版本的升级，这个优势更加明显。 #### 静态代理和动态代理的对比 * **灵活性**：动态代理更加灵活，不需要必须实现接口，可以直接代理实现类，并且可以不需要针对每个目标类都创建一个代理类。另外，静态代理中，接口一旦新增加方法，目标对象和代理对象都要进行修改，这是非常麻烦的！ * **JVM 层面**：静态代理在编译时就将接口、实现类、代理类这些都变成了一个个实际的 class 文件。而动态代理是在运行时动态生成类字节码，并加载到 JVM 中的。 ### BigDecimal 详解 #### 为什么浮点数 `float` 或 `double` 运算的时候会有精度丢失的风险呢？ 这个和计算机保存浮点数的机制有很大关系。我们知道计算机是二进制的，而且计算机在表示一个数字时，宽度是有限的，无限循环的小数存储在计算机时，只能被截断，所以就会导致小数精度发生损失的情况。 #### BigDecimal 介绍 `BigDecimal` 可以实现对浮点数的运算，不会造成精度丢失。通常情况下，大部分需要浮点数精确运算结果的业务场景（比如涉及到钱的场景）都是通过 `BigDecimal` 来做的。 #### BigDecimal 常见方法 **创建** 我们在使用 `BigDecimal` 时，为了防止精度丢失，推荐使用它的`BigDecimal(String val)`构造方法或者 `BigDecimal.valueOf(double val)` 静态方法来创建对象。 **加减乘除** `add` 方法用于将两个 `BigDecimal` 对象相加，`subtract` 方法用于将两个 `BigDecimal` 对象相减。`multiply` 方法用于将两个 `BigDecimal` 对象相乘，`divide` 方法用于将两个 `BigDecimal` 对象相除。 **大小比较** `a.compareTo(b)` : 返回 -1 表示 `a` 小于 `b`，0 表示 `a` 等于 `b` ， 1 表示 `a` 大于 `b`。 **保留几位小数** 通过 `setScale`方法设置保留几位小数以及保留规则。 #### BigDecimal 等值比较问题 `equals()` 方法不仅仅会比较值的大小（value）还会比较精度（scale），而 `compareTo()` 方法比较的时候会忽略精度。 ### Java 魔法类 Unsafe 详解 #### Unsafe 介绍 `Unsafe` 是位于 `sun.misc` 包下的一个类，主要提供一些用于执行低级别、不安全操作的方法，如直接访问系统内存资源、自主管理内存资源等，这些方法在提升 Java 运行效率、增强 Java 语言底层资源操作能力方面起到了很大的作用。但由于 `Unsafe` 类使 Java 语言拥有了类似 C 语言指针一样操作内存空间的能力，这无疑也增加了程序发生相关指针问题的风险。在程序中过度、不正确使用 `Unsafe` 类会使得程序出错的概率变大，使得 Java 这种安全的语言变得不再“安全”，因此对 `Unsafe` 的使用一定要慎重。 另外，`Unsafe` 提供的这些功能的实现需要依赖**本地方法**（Native Method）。你可以将本地方法看作是 Java 中使用其他编程语言编写的方法。本地方法使用 **`native`** 关键字修饰，Java 代码中只是声明方法头，具体的实现则交给**本地代码**。 **为什么要使用本地方法呢？** * 需要用到 Java 中不具备的依赖于操作系统的特性，Java 在实现跨平台的同时要实现对底层的控制，需要借助其他语言发挥作用。 * 对于其他语言已经完成的一些现成功能，可以使用 Java 直接调用。 * 程序对时间敏感或对性能要求非常高时，有必要使用更加底层的语言，例如 C/C++甚至是汇编。 在 JUC 包的很多并发工具类在实现并发机制时，都调用了本地方法，通过它们打破了 Java 运行时的界限，能够接触到操作系统底层的某些功能。对于同一本地方法，不同的操作系统可能会通过不同的方式来实现，但是对于使用者来说是透明的，最终都会得到相同的结果。 #### Unsafe 创建 `Unsafe` 类为一单例实现，提供静态方法 `getUnsafe` 获取 `Unsafe`实例。这个看上去貌似可以用来获取 `Unsafe` 实例。但是，当我们直接调用这个静态方法的时候，会抛出 `SecurityException` 异常。 **为什么 `public static` 方法无法被直接调用呢？** 这是因为在 `getUnsafe` 方法中，会对调用者的 `classLoader` 进行检查，判断当前类是否由 `Bootstrap classLoader` 加载，如果不是的话那么就会抛出一个 `SecurityException` 异常。也就是说，只有启动类加载器加载的类才能够调用 Unsafe 类中的方法，来防止这些方法在不可信的代码中被调用。 **为什么要对 Unsafe 类进行这么谨慎的使用限制呢？** `Unsafe` 提供的功能过于底层（如直接访问系统内存资源、自主管理内存资源等），安全隐患也比较大，使用不当的话，很容易出现很严重的问题。 **如若想使用 `Unsafe` 这个类的话，应该如何获取其实例呢？** 利用反射获得 Unsafe 类中已经实例化完成的单例对象 `theUnsafe` 。 从 `getUnsafe` 方法的使用限制条件出发，通过 Java 命令行命令`-Xbootclasspath/a`把调用 Unsafe 相关方法的类 A 所在 jar 包路径追加到默认的 bootstrap 路径中，使得 A 被引导类加载器加载，从而通过`Unsafe.getUnsafe`方法安全的获取 Unsafe 实例。 #### Unsafe 功能 **内存操作** 需要注意，通过这种方式分配的内存属于堆外内存 ，是无法进行垃圾回收的，需要我们把这些内存当做一种资源去手动调用`freeMemory`方法进行释放，否则会产生内存泄漏。通用的操作内存方式是在`try`中执行对内存的操作，最终在`finally`块中进行内存的释放。 **为什么要使用堆外内存？** * 对垃圾回收停顿的改善。由于堆外内存是直接受操作系统管理而不是 JVM，所以当我们使用堆外内存时，即可保持较小的堆内内存规模。从而在 GC 时减少回收停顿对于应用的影响。 * 提升程序 I/O 操作的性能。通常在 I/O 通信过程中，会存在堆内内存到堆外内存的数据拷贝操作，对于需要频繁进行内存间数据拷贝且生命周期较短的暂存数据，都建议存储到堆外内存。 **典型应用** `DirectByteBuffer` 是 Java 用于实现堆外内存的一个重要类，通常用在通信过程中做缓冲池，如在 Netty、MINA 等 NIO 框架中应用广泛。`DirectByteBuffer` 对于堆外内存的创建、使用、销毁等逻辑均由 Unsafe 提供的堆外内存 API 来实现。 **内存屏障** 在介绍内存屏障前，需要知道编译器和 CPU 会在保证程序输出结果一致的情况下，会对代码进行重排序，从指令优化角度提升性能。**而指令重排序可能会带来一个不好的结果，导致 CPU 的高速缓存和内存中数据的不一致，而内存屏障（`Memory Barrier`）就是通过阻止屏障两边的指令重排序从而避免编译器和硬件的不正确优化情况。** 在硬件层面上，内存屏障是 CPU 为了防止代码进行重排序而提供的指令，不同的硬件平台上实现内存屏障的方法可能并不相同。在 Java8 中，引入了 3 个内存屏障的函数，它屏蔽了操作系统底层的差异，允许在代码中定义、并统一由 JVM 来生成内存屏障指令，来实现内存屏障的功能。 **内存屏障可以看做对内存随机访问的操作中的一个同步点，使得此点之前的所有读写操作都执行后才可以开始执行此点之后的操作**。以`loadFence`方法为例，它会禁止读操作重排序，保证在这个屏障之前的所有读操作都已经完成，并且将缓存数据设为无效，重新从主存中进行加载。 **如果在字段上添加了`volatile`关键字，就能够实现字段在多线程下的可见性。基于读内存屏障，我们也能实现相同的功能。** **典型应用** 在 Java 8 中引入了一种锁的新机制——`StampedLock`，它可以看成是读写锁的一个改进版本。`StampedLock` 提供了一种乐观读锁的实现，这种乐观读锁类似于无锁的操作，完全不会阻塞写线程获取写锁，从而缓解读多写少时写线程“饥饿”现象。由于 `StampedLock` 提供的乐观读锁不阻塞写线程获取读锁，当线程共享变量从主内存 load 到线程工作内存时，会存在数据不一致问题。 为了解决这个问题，`StampedLock` 的 `validate` 方法会通过 `Unsafe` 的 `loadFence` 方法加入一个 `load` 内存屏障。 **对象操作** **对象属性** Unsafe 提供了全部 8 种基础数据类型以及`Object`的`put`和`get`方法，并且所有的`put`方法都可以越过访问权限，直接修改内存中的数据。阅读 openJDK 源码中的注释发现，基础数据类型和`Object`的读写稍有不同，基础数据类型是直接操作的属性值（`value`），而`Object`的操作则是基于引用值（`reference value`）。 除了对象属性的普通读写外，`Unsafe` 还提供了 **volatile 读写**和**有序写入**方法。`volatile`读写方法的覆盖范围与普通读写相同，包含了全部基础数据类型和`Object`类型。 相对于普通读写来说，`volatile`读写具有更高的成本，因为它需要保证可见性和有序性。在执行`get`操作时，会强制从主存中获取属性值，在使用`put`方法设置属性值时，会强制将值更新到主存中，从而保证这些变更对其他线程是可见的。 **对象实例化** **常规对象实例化方式**：我们通常所用到的创建对象的方式，从本质上来讲，都是通过 new 机制来实现对象的创建。但是，new 机制有个特点就是当类只提供有参的构造函数且无显式声明无参构造函数时，则必须使用有参构造函数进行对象构造，而使用有参构造函数时，必须传递相应个数的参数才能完成对象实例化。 **非常规的实例化方式**：**而 Unsafe 中提供 allocateInstance 方法，仅通过 Class 对象就可以创建此类的实例对象**，而且不需要调用其构造函数、初始化代码、JVM 安全检查等。它抑制修饰符检测，也就是即使构造器是 private 修饰的也能通过此方法实例化，只需提类对象即可创建相应的对象。由于这种特性，allocateInstance 在 java.lang.invoke、Objenesis（提供绕过类构造器的对象生成方式）、Gson（反序列化时用到）中都有相应的应用。 **数组操作** `arrayBaseOffset` 与 `arrayIndexScale` 这两个方法配合起来使用，即可定位数组中每个元素在内存中的位置。 **CAS 操作** CAS 即比较并替换（Compare And Swap)，是实现并发算法时常用到的一种技术。CAS 操作包含三个操作数——内存位置、预期原值及新值。执行 CAS 操作的时候，将内存位置的值与预期原值比较，如果相匹配，那么处理器会自动将该位置值更新为新值，否则，处理器不做任何操作。我们都知道，CAS 是一条 CPU 的原子指令（cmpxchg 指令），不会造成所谓的数据不一致问题，`Unsafe` 提供的 CAS 方法（如 `compareAndSwapXXX`）底层实现即为 CPU 指令 `cmpxchg` 。 在 JUC 包的并发工具类中大量地使用了 CAS 操作，像在前面介绍 `synchronized` 和 `AQS` 的文章中也多次提到了 CAS，其作为乐观锁在并发工具类中广泛发挥了作用。在 `Unsafe` 类中，提供了`compareAndSwapObject`、`compareAndSwapInt`、`compareAndSwapLong`方法来实现的对`Object`、`int`、`long`类型的 CAS 操作。 **线程调度** Java 锁和同步器框架的核心类 `AbstractQueuedSynchronizer` (AQS)，就是通过调用`LockSupport.park()`和`LockSupport.unpark()`实现线程的阻塞和唤醒的，而 `LockSupport` 的 `park`、`unpark` 方法实际是调用 `Unsafe` 的 `park`、`unpark` 方式实现的。 **Class 操作** `Unsafe` 对`Class`的相关操作主要包括类加载和静态变量的操作方法。**使用 `defineClass` 方法允许程序在运行时动态地创建一个类**。使用`defineAnonymousClass`方法可以用来动态的创建一个匿名类，在`Lambda`表达式中就是使用 ASM 动态生成字节码，然后利用该方法定义实现相应的函数式接口的匿名类。 **系统信息** 在 `java.nio.Bits` 类中，在使用 `pageCount` 计算所需的内存页的数量时，调用了 `pageSize` 方法获取内存页的大小。另外，在使用 `copySwapMemory` 方法拷贝内存时，调用了 `addressSize` 方法，检测 32 位系统的情况。 ### Java SPI 机制详解 #### SPI 介绍 **何谓 SPI?** **SPI（Service Provider Interface）**，是JDK内置的一种**服务提供发现机制**，它允许在`运行时动态地加载实现`特定接口的类，而不需要在代码中显式地指定该类，从而实现`解耦和灵活性`。SPI 可以用来启用框架扩展和替换组件，主要是被框架的开发人员使用，比如java.sql.Driver接口，其他不同厂商可以针对同一接口做出不同的实现，MySQL和PostgreSQL都有不同的实现提供给用户，而Java的SPI机制可以为某个接口寻找服务实现。Java中SPI机制主要思想是将装配的控制权移到程序之外，在模块化设计中这个机制尤其重要，其核心思想就是**解耦**。 面向对象设计鼓励模块间基于接口而非具体实现编程，以降低模块间的耦合，遵循依赖倒置原则，并支持开闭原则（对扩展开放，对修改封闭）。然而，直接依赖具体实现会导致在替换实现时需要修改代码，违背了开闭原则。**为了解决这个问题，SPI 应运而生，它提供了一种服务发现机制，允许在程序外部动态指定具体实现。这与控制反转（IoC）的思想相似，将组件装配的控制权移交给了程序之外**。 SPI 机制也解决了 Java 类加载体系中双亲委派模型带来的限制。双亲委派模型虽然保证了核心库的安全性和一致性，但也限制了核心库或扩展库加载应用程序类路径上的类（通常由第三方实现）。SPI 允许核心或扩展库定义服务接口，第三方开发者提供并部署实现，SPI 服务加载机制则在运行时动态发现并加载这些实现。 **SPI 机制的具体实现本质上还是通过反射完成的**。即：**我们按照规定将要暴露对外使用的具体实现类在 `META-INF/services/` 文件下声明。** 很多框架都使用了 Java 的 SPI 机制，比如：Spring 框架、数据库加载驱动、日志接口、以及 Dubbo 的扩展实现等等。 **SPI 和 API 有什么区别？** ![SPI VS API](https://oss.javaguide.cn/github/javaguide/java/basis/spi-vs-api.png) 一般模块之间都是通过接口进行通讯，因此我们在服务调用方和服务实现方（也称服务提供者）之间引入一个“接口”。 * 当实现方提供了接口和实现，我们可以通过调用实现方的接口从而拥有实现方给我们提供的能力，这就是 **API**。这种情况下，接口和实现都是放在实现方的包中。调用方通过接口调用实现方的功能，而不需要关心具体的实现细节。 * 当接口存在于调用方这边时，这就是 **SPI** 。由接口调用方确定接口规则，然后由不同的厂商根据这个规则对这个接口进行实现，从而提供服务。 ## Java 集合 ### 集合概述 #### Java 集合概览 Java 集合，也叫作容器，主要是由两大接口派生而来：一个是 `Collection`接口，主要用于存放单一元素；另一个是 `Map` 接口，主要用于存放键值对。对于`Collection` 接口，下面又有三个主要的子接口：`List`、`Set` 、 `Queue`。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-346b0203e8838c3140232acc8abead55be71c808%2FPasted%20image%2020250221105204.png?alt=media) #### 说说 List，Set，Queue，Map 四者的区别？ * `List`（对付顺序的好帮手）：存储的元素是有序的、可重复的。 * `Set`（注重独一无二的性质）：存储的元素不可重复的。 * `Queue`（实现排队功能的叫号机）：按特定的排队规则来确定先后顺序，存储的元素是有序的、可重复的。 * `Map`（用 key 来搜索的专家）：使用键值对（key-value）存储，key 是无序的、不可重复的，value 是无序的、可重复的，每个键最多映射到一个值。 #### 集合框架底层数据结构总结 **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** * `HashMap`：JDK1.8 之前 `HashMap` 由数组+链表组成的，数组是 `HashMap` 的主体，链表则是主要为了解决哈希冲突而存在的（“拉链法”解决冲突）。JDK1.8 以后在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为 8）（将链表转换成红黑树前会判断，如果当前数组的长度小于 64，那么会选择先进行数组扩容，而不是转换为红黑树）时，将链表转化为红黑树，以减少搜索时间。 * `LinkedHashMap`：`LinkedHashMap` 继承自 `HashMap`，所以它的底层仍然是基于拉链式散列结构即由数组和链表或红黑树组成。另外，`LinkedHashMap` 在上面结构的基础上，增加了一条双向链表，使得上面的结构可以保持键值对的插入顺序。同时通过对链表进行相应的操作，实现了访问顺序相关逻辑。 * `Hashtable`：数组+链表组成的，数组是 `Hashtable` 的主体，链表则是主要为了解决哈希冲突而存在的。 * `TreeMap`：红黑树（自平衡的排序二叉树）。 #### 如何选用集合? * 我们需要根据键值获取到元素值时就选用 `Map` 接口下的集合，需要排序时选择 `TreeMap`，不需要排序时就选择 `HashMap`，需要保证线程安全就选用 `ConcurrentHashMap`。 * 我们只需要存放元素值时，就选择实现`Collection` 接口的集合，需要保证元素唯一时选择实现 `Set` 接口的集合比如 `TreeSet` 或 `HashSet`，不需要就选择实现 `List` 接口的比如 `ArrayList` 或 `LinkedList`，然后再根据实现这些接口的集合的特点来选用。 #### 为什么要使用集合？ 相较于数组，Java 集合的优势在于它们的大小可变、支持泛型、具有内建算法等。总的来说，Java 集合提高了数据的存储和处理灵活性，可以更好地适应现代软件开发中多样化的数据需求，并支持高质量的代码编写。 ### List #### ArrayList 简介 `ArrayList` 的底层是数组队列，相当于动态数组。与 Java 中的数组相比，它的容量能动态增长。在添加大量元素前，应用程序可以使用 `ensureCapacity` 操作来增加 `ArrayList` 实例的容量。这可以减少递增式再分配的数量。 `ArrayList` 继承于 `AbstractList` ，实现了 `List`，`RandomAccess`，`Cloneable`，`java.io.Serializable` 这些接口。 * `List` : 表明它是一个列表，支持添加、删除、查找等操作，并且可以通过下标进行访问。 * `RandomAccess` ：这是一个标志接口，表明实现这个接口的 `List` 集合是支持**快速随机访问** 的。在 `ArrayList` 中，我们即可以通过元素的序号快速获取元素对象，这就是快速随机访问。 * `Cloneable` ：表明它具有拷贝能力，可以进行深拷贝或浅拷贝操作。 * `Serializable` : 表明它可以进行序列化操作，也就是可以将对象转换为字节流进行持久化存储或网络传输，非常方便。 #### ArrayList 和 Array（数组）的区别？ `ArrayList` 内部基于动态数组实现，比 `Array`（静态数组） 使用起来更加灵活： * `ArrayList`会根据实际存储的元素动态地扩容或缩容，而 `Array` 被创建之后就不能改变它的长度了。 * `ArrayList` 允许你使用泛型来确保类型安全，`Array` 则不可以。 * `ArrayList` 中只能存储对象。对于基本类型数据，需要使用其对应的包装类（如 Integer、Double 等）。`Array` 可以直接存储基本类型数据，也可以存储对象。 * `ArrayList` 支持插入、删除、遍历等常见操作，并且提供了丰富的 API 操作方法，比如 `add()`、`remove()`等。`Array` 只是一个固定长度的数组，只能按照下标访问其中的元素，不具备动态添加、删除元素的能力。 * `ArrayList` 创建时不需要指定大小，而 `Array` 创建时必须指定大小。 #### ArrayList 和 Vector 的区别?（了解即可） * `ArrayList` 是 `List` 的主要实现类，底层使用 `Object[]`存储，适用于频繁的查找工作，线程不安全 。 * `Vector` 是 `List` 的古老实现类，底层使用 `Object[]` 存储，线程安全。 #### Vector 和 Stack 的区别?（了解即可） * `Vector` 和 `Stack` 两者都是线程安全的，都是使用 `synchronized` 关键字进行同步处理。 * `Stack` 继承自 `Vector`，是一个后进先出的栈，而 `Vector` 是一个列表。 随着 Java 并发编程的发展，`Vector` 和 `Stack` 已经被淘汰，推荐使用并发集合类（例如 `ConcurrentHashMap`、`CopyOnWriteArrayList` 等）或者手动实现线程安全的方法来提供安全的多线程操作支持。 #### ArrayList 可以添加 null 值吗？ `ArrayList` 中可以存储任何类型的对象，包括 `null` 值。不过，不建议向`ArrayList` 中添加 `null` 值， `null` 值无意义，会让代码难以维护比如忘记做判空处理就会导致空指针异常。 #### ArrayList 插入和删除元素的时间复杂度？ **插入** * 头部插入：由于需要将所有元素都依次向后移动一个位置，因此时间复杂度是 O(n)。 * 尾部插入：当 `ArrayList` 的容量未达到极限时，往列表末尾插入元素的时间复杂度是 O(1)，因为它只需要在数组末尾添加一个元素即可；当容量已达到极限并且需要扩容时，则需要执行一次 O(n) 的操作将原数组复制到新的更大的数组中，然后再执行 O(1) 的操作添加元素。 * 指定位置插入：需要将目标位置之后的所有元素都向后移动一个位置，然后再把新元素放入指定位置。这个过程需要移动平均 n/2 个元素，因此时间复杂度为 O(n)。 **删除** * 头部删除：由于需要将所有元素依次向前移动一个位置，因此时间复杂度是 O(n)。 * 尾部删除：当删除的元素位于列表末尾时，时间复杂度为 O(1)。 * 指定位置删除：需要将目标元素之后的所有元素向前移动一个位置以填补被删除的空白位置，因此需要移动平均 n/2 个元素，时间复杂度为 O(n)。 #### LinkedList 简介 `LinkedList` 是一个基于双向链表实现的集合类，经常被拿来和 `ArrayList` 做比较。 #### LinkedList 插入和删除元素的时间复杂度？ * 头部插入/删除：只需要修改头结点的指针即可完成插入/删除操作，因此时间复杂度为 O(1)。 * 尾部插入/删除：只需要修改尾结点的指针即可完成插入/删除操作，因此时间复杂度为 O(1)。 * 指定位置插入/删除：需要先移动到指定位置，再修改指定节点的指针完成插入/删除，不过由于有头尾指针，可以从较近的指针出发，因此需要遍历平均 n/4 个元素，时间复杂度为 O(n)。 #### LinkedList 为什么不能实现 RandomAccess 接口？ `RandomAccess` 是一个标记接口，用来表明实现该接口的类支持随机访问（即可以通过索引快速访问元素）。由于 `LinkedList` 底层数据结构是链表，内存地址不连续，只能通过指针来定位，不支持随机快速访问，所以不能实现 `RandomAccess` 接口。 #### ArrayList 与 LinkedList 区别? 我们在项目中一般是不会使用到 `LinkedList` 的，需要用到 `LinkedList` 的场景几乎都可以使用 `ArrayList` 来代替，并且，性能通常会更好！ **是否保证线程安全** `ArrayList` 和 `LinkedList` 都是不同步的，也就是不保证线程安全； **底层数据结构** `ArrayList` 底层使用的是 **`Object` 数组**；`LinkedList` 底层使用的是**双向链表**数据结构（JDK1.6 之前为循环链表，JDK1.7 取消了循环。） **插入和删除是否受元素位置的影响** `ArrayList` 采用数组存储，所以插入和删除元素的时间复杂度受元素位置的影响。执行`add(E e)`方法的时候， `ArrayList` 会默认在将指定的元素追加到此列表的末尾，这种情况时间复杂度就是 O(1)。但是如果要在指定位置 i 插入和删除元素的话（`add(int index, E element)`），时间复杂度就为 O(n)。因为在进行上述操作的时候集合中第 i 和第 i 个元素之后的(n-i)个元素都要执行向后位/向前移一位的操作。 `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 更多的空间（因为要存放直接后继和直接前驱以及数据）。 **双向链表和双向循环链表** ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-eb0974bb59971e1330ad757a5d26e51f2628e926%2FPasted%20image%2020250221111542.png?alt=media) ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-0b73bc5ae6d605058ad7347ea534d67448333d0c%2FPasted%20image%2020250221111544.png?alt=media) **RandomAccess 接口** 查看源码我们发现实际上 `RandomAccess` 接口中什么都没有定义。所以，在我看来 `RandomAccess` 接口不过是一个标识罢了。标识实现这个接口的类具有随机访问功能。 #### 说一说 ArrayList 的扩容机制吧 **一步一步分析 ArrayList 扩容机制** **add 方法** **以无参数构造方法创建 `ArrayList` 时，实际上初始化赋值的是一个空数组。当真正对数组进行添加元素操作时，才真正分配容量。即向数组中添加第一个元素时，数组容量扩为 10。** * 当我们要 `add` 进第 1 个元素到 `ArrayList` 时，`elementData.length` 为 0 （因为还是一个空的 list），因为执行了 `ensureCapacityInternal()` 方法 ，所以 `minCapacity` 此时为 10。此时，`minCapacity - elementData.length > 0`成立，所以会进入 `grow(minCapacity)` 方法。 * 当 `add` 第 2 个元素时，`minCapacity` 为 2，此时 `elementData.length`(容量)在添加第一个元素后扩容成 `10` 了。此时，`minCapacity - elementData.length > 0` 不成立，所以不会进入 （执行）`grow(minCapacity)` 方法。 * 添加第 3、4···到第 10 个元素时，依然不会执行 grow 方法，数组容量都为 10。 直到添加第 11 个元素，`minCapacity`（为 11）比 `elementData.length`（为 10）要大。进入 `grow` 方法进行扩容。 **grow 方法** **`int newCapacity = oldCapacity + (oldCapacity >> 1)`，所以 ArrayList 每次扩容之后容量都会变为原来的 1.5 倍左右（oldCapacity 为偶数就是 1.5 倍，否则是 1.5 倍左右）。** * 当 `add` 第 1 个元素时，`oldCapacity` 为 0，经比较后第一个 if 判断成立，`newCapacity = minCapacity`(为 10)。但是第二个 if 判断不会成立，即 `newCapacity` 不比 `MAX_ARRAY_SIZE` 大，则不会进入 `hugeCapacity` 方法。数组容量为 10，`add` 方法中 return true,size 增为 1。 * 当 `add` 第 11 个元素进入 `grow` 方法时，`newCapacity` 为 15，比 `minCapacity`（为 11）大，第一个 if 判断不成立。新容量没有大于数组最大 size，不会进入 `hugeCapacity` 方法。数组容量扩为 15，add 方法中 return true,size 增为 11。 **length** * Java 中的 `length` 属性是针对数组说的，比如说你声明了一个数组，想知道这个数组的长度则用到了 length 这个属性。 * Java 中的 `length()` 方法是针对字符串说的，如果想看这个字符串的长度则用到 `length()` 这个方法。 * Java 中的 `size()` 方法是针对泛型集合说的，如果想看这个泛型有多少个元素,就调用此方法来查看。 #### 说说集合中的 fail-fast 和 fail-safe 是什么 快速失败的思想即针对可能发生的异常进行提前表明故障并停止运行，通过尽早的发现和停止错误，降低故障系统级联的风险。 在 `java.util` 包下的大部分集合是不支持线程安全的，为了能够提前发现并发操作导致线程安全风险，提出通过维护一个 `modCount` 记录修改的次数，迭代期间通过比对预期修改次数 `expectedModCount` 和 `modCount` 是否一致来判断是否存在并发操作，从而实现快速失败，由此保证在避免在异常时执行非必要的复杂代码。 ### Set #### 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()`. #### 无序性和不可重复性的含义是什么 * 无序性不等于随机性 ，无序性是指存储的数据在底层数组中并非按照数组索引的顺序添加 ，而是根据数据的哈希值决定的。 * 不可重复性是指添加的元素按照 `equals()` 判断时 ，返回 false，需要同时重写 `equals()` 方法和 `hashCode()` 方法。 #### 比较 HashSet、LinkedHashSet 和 TreeSet 三者的异同 * `HashSet`、`LinkedHashSet` 和 `TreeSet` 都是 `Set` 接口的实现类，都能保证元素唯一，并且都不是线程安全的。 * `HashSet`、`LinkedHashSet` 和 `TreeSet` 的主要区别在于底层数据结构不同。`HashSet` 的底层数据结构是哈希表（基于 `HashMap` 实现）。`LinkedHashSet` 的底层数据结构是链表和哈希表，元素的插入和取出顺序满足 FIFO。`TreeSet` 底层数据结构是红黑树，元素是有序的，排序的方式有自然排序和定制排序。 * 底层数据结构不同又导致这三者的应用场景不同。`HashSet` 用于不需要保证元素插入和取出顺序的场景，`LinkedHashSet` 用于保证元素的插入和取出顺序满足 FIFO 的场景，`TreeSet` 用于支持对元素自定义排序规则的场景。 ### Queue #### Queue 与 Deque 的区别 `Queue` 是单端队列，只能从一端插入元素，另一端删除元素，实现上一般遵循 **先进先出（FIFO）** 规则。 `Queue` 扩展了 `Collection` 的接口，根据 **因为容量问题而导致操作失败后处理方式的不同** 可以分为两类方法: 一种在操作失败后会抛出异常，另一种则会返回特殊值。 `Deque` 是双端队列，在队列的两端均可以插入或删除元素。 `Deque` 扩展了 `Queue` 的接口, 增加了在队首和队尾进行插入和删除的方法，事实上，`Deque` 还提供有 `push()` 和 `pop()` 等其他方法，可用于模拟栈。 #### ArrayDeque 与 LinkedList 的区别 `ArrayDeque` 和 `LinkedList` 都实现了 `Deque` 接口，两者都具有队列的功能，但两者有什么区别呢？ * `ArrayDeque` 是基于可变长的数组和双指针来实现，而 `LinkedList` 则通过链表来实现。 * `ArrayDeque` 不支持存储 `NULL` 数据，但 `LinkedList` 支持。 * `ArrayDeque` 插入时可能存在扩容过程, 不过均摊后的插入操作依然为 O(1)。虽然 `LinkedList` 不需要扩容，但是每次插入数据时均需要申请新的堆空间，均摊性能相比更慢。 从性能的角度上，选用 `ArrayDeque` 来实现队列要比 `LinkedList` 更好。此外，`ArrayDeque` 也可以用于实现栈。 #### 说一说 PriorityQueue `PriorityQueue` 与 `Queue` 的区别在于元素出队顺序是与优先级相关的，即总是优先级最高的元素先出队。 * `PriorityQueue` 利用了二叉堆的数据结构来实现的，底层使用可变长的数组来存储数据 * `PriorityQueue` 通过堆元素的上浮和下沉，实现了在 O(logn) 的时间复杂度内插入元素和删除堆顶元素。 * `PriorityQueue` 是非线程安全的，且不支持存储 `NULL` 和 `non-comparable` 的对象。 * `PriorityQueue` 默认是小顶堆，但可以接收一个 `Comparator` 作为构造参数，从而来自定义元素优先级的先后。 `PriorityQueue` 在面试中可能更多的会出现在手撕算法的时候，典型例题包括堆排序、求第 K 大的数、带权图的遍历等，所以需要会熟练使用才行。 #### 什么是 BlockingQueue？ `BlockingQueue` （阻塞队列）是一个接口，继承自 `Queue`。`BlockingQueue` 阻塞的原因是其支持当队列没有元素时一直阻塞，直到有元素；还支持如果队列已满，一直等到队列可以放入新元素时再放入。 `BlockingQueue` 常用于生产者-消费者模型中，生产者线程会向队列中添加数据，而消费者线程会从队列中取出数据进行处理。 ### Map（重要） #### 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 的幂作为哈希表的大小。 **底层数据结构** JDK1.8 以后的 `HashMap` 在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为 8）时，将链表转化为红黑树（将链表转换成红黑树前会判断，如果当前数组的长度小于 64，那么会选择先进行数组扩容，而不是转换为红黑树），以减少搜索时间（后文中我会结合源码对这一过程进行分析）。`Hashtable` 没有这样的机制。 **哈希函数的实现** `HashMap` 对哈希值进行了高位和低位的混合扰动处理以减少冲突，而 `Hashtable` 直接使用键的 `hashCode()` 值。 #### HashMap 和 HashSet 区别 `HashSet` 底层就是基于 `HashMap` 实现的。（`HashSet` 的源码非常非常少，因为除了 `clone()`、`writeObject()`、`readObject()`是 `HashSet` 自己不得不实现之外，其他方法都是直接调用 `HashMap` 中的方法。 #### HashMap 和 TreeMap 区别 `TreeMap` 和`HashMap` 都继承自`AbstractMap` ，但是需要注意的是`TreeMap`它还实现了`NavigableMap`接口和`SortedMap` 接口。 实现 `NavigableMap` 接口让 `TreeMap` 有了对集合内元素的搜索的能力。 这些方法都是基于红黑树数据结构的属性实现的，红黑树保持平衡状态，从而保证了搜索操作的时间复杂度为 O(log n)，这让 `TreeMap` 成为了处理有序集合搜索问题的强大工具。 实现`SortedMap`接口让 `TreeMap` 有了对集合中的元素根据键排序的能力。默认是按 key 的升序排序，不过我们也可以指定排序的比较器。 **相比于`HashMap`来说， `TreeMap` 主要多了对集合中的元素根据键排序的能力以及对集合内元素的搜索的能力。** #### HashSet 如何检查重复? 当你把对象加入`HashSet`时，`HashSet` 会先计算对象的`hashcode`值来判断对象加入的位置，同时也会与其他加入的对象的 `hashcode` 值作比较，如果没有相符的 `hashcode`，`HashSet` 会假设对象没有重复出现。但是如果发现有相同 `hashcode` 值的对象，这时会调用`equals()`方法来检查 `hashcode` 相等的对象是否真的相同。如果两者相同，`HashSet` 就不会让加入操作成功。 #### HashMap 的底层实现 **JDK1.8 之前** JDK1.8 之前 `HashMap` 底层是 **数组和链表** 结合在一起使用也就是 **链表散列**。HashMap 通过 key 的 `hashcode` 经过扰动函数处理过后得到 hash 值，然后通过 `(n - 1) & hash` 判断当前元素存放的位置（这里的 n 指的是数组的长度），如果当前位置存在元素的话，就判断该元素与要存入的元素的 hash 值以及 key 是否相同，如果相同的话，直接覆盖，不相同就通过拉链法解决冲突。 `HashMap` 中的扰动函数（`hash` 方法）是用来优化哈希值的分布。通过对原始的 `hashCode()` 进行额外处理，扰动函数可以减小由于糟糕的 `hashCode()` 实现导致的碰撞，从而提高数据的分布均匀性。 所谓 **“拉链法”** 就是：将链表和数组相结合。也就是说创建一个链表数组，数组中每一格就是一个链表。若遇到哈希冲突，则将冲突的值加到链表中即可。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-141c15123f37b67c9169081da544e46380364031%2FPasted%20image%2020250221115111.png?alt=media) **JDK1.8 之后** 相比于之前的版本， JDK1.8 之后在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为 8）（将链表转换成红黑树前会判断，如果当前数组的长度小于 64，那么会选择先进行数组扩容，而不是转换为红黑树）时，将链表转化为红黑树，以减少搜索时间。 TreeMap、TreeSet 以及 JDK1.8 之后的 HashMap 底层都用到了红黑树。红黑树就是为了解决二叉查找树的缺陷，因为二叉查找树在某些情况下会退化成一个线性结构。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-c4500c11e37b468bc039f2611071979acbde0c31%2FPasted%20image%2020250221115556.png?alt=media) **类的属性** **loadFactor 负载因子** loadFactor 负载因子是控制数组存放数据的疏密程度，loadFactor 越趋近于 1，那么 数组中存放的数据（entry）也就越多，也就越密，也就是会让链表的长度增加，loadFactor 越小，也就是趋近于 0，数组中存放的数据（entry）也就越少，也就越稀疏。 **loadFactor 太大导致查找元素效率低，太小导致数组的利用率低，存放的数据会很分散。loadFactor 的默认值为 0.75f 是官方给出的一个比较好的临界值**。 给定的默认容量为 16，负载因子为 0.75。Map 在使用过程中不断的往里面存放数据，当数量超过了 16 \* 0.75 = 12 就需要将当前 16 的容量进行扩容，而扩容这个过程涉及到 rehash、复制数据等操作，所以非常消耗性能。 **threshold** **threshold = capacity \* loadFactor**，**当 Size>threshold** 的时候，那么就要考虑对数组的扩增了，也就是说，这个的意思就是 **衡量数组是否需要扩增的一个标准**。 #### HashMap 的长度为什么是 2 的幂次方 为了让 `HashMap` 存取高效并减少碰撞，我们需要确保数据尽量均匀分布。哈希值在 Java 中通常使用 `int` 表示，其范围是 `-2147483648 ~ 2147483647` 前后加起来大概 40 亿的映射空间，只要哈希函数映射得比较均匀松散，一般应用是很难出现碰撞的。但是，问题是一个 40 亿长度的数组，内存是放不下的。所以，这个散列值是不能直接拿来用的。用之前还要先做对数组的长度取模运算，得到的余数才能用来要存放的位置也就是对应的数组下标。 * **位运算效率更高**：位运算(&)比取余运算(%)更高效。当长度为 2 的幂次方时，`hash % length` 等价于 `hash & (length - 1)`。 * **可以更好地保证哈希值的均匀分布**：扩容之后，在旧数组元素 hash 值比较均匀的情况下，新数组元素也会被分配的比较均匀，最好的情况是会有一半在新数组的前半部分，一半在新数组后半部分。 * **扩容机制变得简单和高效**：扩容后只需检查哈希值高位的变化来决定元素的新位置，要么位置不变（高位为 0），要么就是移动到新位置（高位为 1，原索引位置+原容量）。 #### HashMap 多线程操作导致死循环问题 JDK1.7 及之前版本的 `HashMap` 在多线程环境下扩容操作可能存在死循环问题，这是由于当一个桶位中有多个元素需要进行扩容时，多个线程同时对链表进行操作，头插法可能会导致链表中的节点指向错误的位置，从而形成一个环形链表，进而使得查询元素的操作陷入死循环无法结束。 为了解决这个问题，JDK1.8 版本的 HashMap 采用了尾插法而不是头插法来避免链表倒置，使得插入的节点永远都是放在链表的末尾，避免了链表中的环形结构。但是还是不建议在多线程下使用 `HashMap`，因为多线程下使用 `HashMap` 还是会存在数据覆盖的问题。并发环境下，推荐使用 `ConcurrentHashMap` 。 #### HashMap 为什么线程不安全？ 在多线程环境下，`HashMap` 扩容时会造成死循环和数据丢失的问题。JDK 1.8 后，在 `HashMap` 中，多个键值对可能会被分配到同一个桶（bucket），并以链表或红黑树的形式存储。多个线程对 `HashMap` 的 `put` 操作会导致线程不安全，具体来说会有数据覆盖的风险。 #### HashMap 常见的遍历方式? **存在阻塞时 parallelStream 性能最高, 非阻塞时 parallelStream 性能最低** 。 #### ConcurrentHashMap 和 Hashtable 的区别 `ConcurrentHashMap` 和 `Hashtable` 的区别主要体现在实现线程安全的方式上不同。 在 JDK1.7 的时候，`ConcurrentHashMap` 对整个桶数组进行了分割分段(`Segment`，分段锁)，每一把锁只锁容器其中一部分数据（下面有示意图），多线程访问容器里不同数据段的数据，就不会存在锁竞争，提高并发访问率。 到了 JDK1.8 的时候，`ConcurrentHashMap` 已经摒弃了 `Segment` 的概念，而是直接用 `Node` 数组+链表+红黑树的数据结构来实现，并发控制使用 `synchronized` 和 CAS 来操作。（JDK1.6 以后 `synchronized` 锁做了很多优化） 整个看起来就像是优化过且线程安全的 `HashMap`，虽然在 JDK1.8 中还能看到 `Segment` 的数据结构，但是已经简化了属性，只是为了兼容旧版本； **`Hashtable`(同一把锁)** :使用 `synchronized` 来保证线程安全，效率非常低下。当一个线程访问同步方法时，其他线程也访问同步方法，可能会进入阻塞或轮询状态，如使用 put 添加元素，另一个线程不能使用 put 添加元素，也不能使用 get，竞争会越来越激烈效率越低。 #### ConcurrentHashMap 线程安全的具体实现方式/底层具体实现 `ConcurrentHashMap` 取消了 `Segment` 分段锁，采用 `Node + CAS + synchronized` 来保证并发安全。数据结构跟 `HashMap` 1.8 的结构类似，数组+链表/红黑二叉树。Java 8 在链表长度超过一定阈值（8）时将链表（寻址时间复杂度为 O(N)）转换为红黑树（寻址时间复杂度为 O(log(N))）。 Java 8 中，锁粒度更细，`synchronized` 只锁定当前链表或红黑二叉树的首节点，这样只要 hash 不冲突，就不会产生并发，就不会影响其他 Node 的读写，效率大幅提升。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-26cc45f68aedf34fa36dcf2b37bb3ffc56d889de%2FPasted%20image%2020250302104729.png?alt=media) #### ConcurrentHashMap 为什么 key 和 value 不能为 null？ **`ConcurrentHashMap` 的 key 和 value 不能为 null 主要是为了避免二义性**。null 是一个特殊的值，表示没有对象或没有引用。如果你用 null 作为键，那么你就无法区分这个键是否存在于 `ConcurrentHashMap` 中，还是根本没有这个键。同样，如果你用 null 作为值，那么你就无法区分这个值是否是真正存储在 `ConcurrentHashMap` 中的，还是因为找不到对应的键而返回的。 多线程环境下，存在一个线程操作该 `ConcurrentHashMap` 时，其他的线程将该 `ConcurrentHashMap` 修改的情况，所以无法通过 `containsKey(key)` 来判断否存在这个键值对，也就没办法解决二义性问题了。 与此形成对比的是，`HashMap` 可以存储 null 的 key 和 value，但 null 作为键只能有一个，null 作为值可以有多个。如果传入 null 作为参数，就会返回 hash 值为 0 的位置的值。单线程环境下，不存在一个线程操作该 HashMap 时，其他的线程将该 `HashMap` 修改的情况，所以可以通过 `contains(key)`来做判断是否存在这个键值对，从而做相应的处理，也就不存在二义性问题。 也就是说，多线程下无法正确判定键值对是否存在（存在其他线程修改的情况），单线程是可以的（不存在其他线程修改的情况）。 #### ConcurrentHashMap 能保证复合操作的原子性吗？、 `ConcurrentHashMap` 是线程安全的，意味着它可以保证多个线程同时对它进行读写操作时，不会出现数据不一致的情况，也不会导致 JDK1.7 及之前版本的 `HashMap` 多线程操作导致死循环问题。但是，这并不意味着它可以保证所有的复合操作都是原子性的。 复合操作是指由多个基本操作(如`put`、`get`、`remove`、`containsKey`等)组成的操作，例如先判断某个键是否存在`containsKey(key)`，然后根据结果进行插入或更新`put(key, value)`。这种操作在执行过程中可能会被其他线程打断，导致结果不符合预期。 **那如何保证 `ConcurrentHashMap` 复合操作的原子性呢？** `ConcurrentHashMap` 提供了一些原子性的复合操作，如 `putIfAbsent`、`compute`、`computeIfAbsent` 、`computeIfPresent`、`merge`等。这些方法都可以接受一个函数作为参数，根据给定的 key 和 value 来计算一个新的 value，并且将其更新到 map 中。 ### Collections 工具类（不重要） **`Collections` 工具类常用方法**: * 排序操作 * 查找，替换操作 * 同步控制(不推荐，需要线程安全的集合类型时请考虑使用 JUC 包下的并发集合) ### Java 集合使用注意事项总结 #### 集合判空 **判断所有集合内部的元素是否为空，使用 `isEmpty()` 方法，而不是 `size()==0` 的方式**。这是因为 `isEmpty()` 方法的可读性更好，并且时间复杂度为 `O(1)`。 #### 集合转 Map **在使用 `java.util.stream.Collectors` 类的 `toMap()` 方法转为 `Map` 集合时，一定要注意当 value 为 null 时会抛 NPE 异常。** #### 集合遍历 **不要在 foreach 循环里进行元素的 `remove/add` 操作。remove 元素请使用 `Iterator` 方式，如果并发操作，需要对 `Iterator` 对象加锁。** 通过反编译你会发现 foreach 语法底层其实还是依赖 `Iterator` 。不过， `remove/add` 操作直接调用的是集合自己的方法，而不是 `Iterator` 的 `remove/add`方法 这就导致 `Iterator` 莫名其妙地发现自己有元素被 `remove/add` ，然后，它就会抛出一个 `ConcurrentModificationException` 来提示用户发生了并发修改异常。这就是单线程状态下产生的 **fail-fast 机制**。 #### 集合去重 **可以利用 `Set` 元素唯一的特性，可以快速对一个集合进行去重操作，避免使用 `List` 的 `contains()` 进行遍历去重或者判断包含操作。** #### 集合转数组 **使用集合转数组的方法，必须使用集合的 `toArray(T[] array)`，传入的是类型完全一致、长度为 0 的空数组。** `toArray(T[] array)` 方法的参数是一个泛型数组，如果 `toArray` 方法中没有传递任何参数的话返回的是 `Object`类 型数组。 #### 数组转集合 **使用工具类 `Arrays.asList()` 把数组转换成集合时，不能使用其修改集合相关的方法， 它的 `add/remove/clear` 方法会抛出 `UnsupportedOperationException` 异常**。 ## JVM ### JVM 内存区域详解 #### 运行时数据区域 Java 虚拟机在执行的时候会把管理的内存分配成不同的区域，这些区域被称为`虚拟机内存`，同时，对于虚拟机没有直接管理的物理内存，也有一定的利用，这些被利用却不在虚拟机内存数据区的内存，我们称它为`本地内存`。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-8131151eb5915a140c0c68b5749454573acb8d78%2FPasted%20image%2020250213163515.png?alt=media) ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-608206ca7afdf7b7451117c9d37b541585964936%2FPasted%20image%2020250305154039.png?alt=media) **程序计数器** 程序计数器是一块较小的内存空间，可以看作是当前线程所执行的字节码的行号指示器。字节码解释器工作时通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等功能都需要依赖这个计数器来完成。 另外，为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各线程之间计数器互不影响，独立存储，我们称这类内存区域为“线程私有”的内存。 **Java 虚拟机栈** 与程序计数器一样，Java 虚拟机栈（后文简称栈）也是线程私有的，它的生命周期和线程相同，随着线程的创建而创建，随着线程的死亡而死亡。 栈绝对算的上是 JVM 运行时数据区域的一个核心，除了一些 Native 方法调用是通过本地方法栈实现的，其他所有的 Java 方法调用都是通过栈来实现的（也需要和其他运行时数据区域比如程序计数器配合）。 方法调用的数据需要通过栈进行传递，每一次方法调用都会有一个对应的栈帧被压入栈中，每一个方法调用结束后，都会有一个栈帧被弹出。 栈由一个个栈帧组成，而每个栈帧中都拥有：局部变量表、操作数栈、动态链接、方法返回地址。和数据结构上的栈类似，两者都是先进后出的数据结构，只支持出栈和入栈两种操作。 **局部变量表** **局部变量表** 主要存放了编译期可知的各种数据类型（boolean、byte、char、short、int、float、long、double）、对象引用（reference 类型，它不同于对象本身，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或其他与此对象相关的位置）。 **操作数栈** **操作数栈** 主要作为方法调用的中转站使用，用于存放方法执行过程中产生的中间计算结果。另外，计算过程中产生的临时变量也会放在操作数栈中。 **动态链接** **动态链接** 主要服务一个方法需要调用其他方法的场景。Class 文件的常量池里保存有大量的符号引用比如方法引用的符号引用。**当一个方法要调用其他方法，需要将常量池中指向方法的符号引用转化为其在内存地址中的直接引用**。动态链接的作用就是为了将符号引用转换为调用方法的直接引用，这个过程也被称为 **动态连接** 。 **StackOverFlowError** 栈空间虽然不是无限的，但一般正常调用的情况下是不会出现问题的。不过，如果函数调用陷入无限循环的话，就会导致栈中被压入太多栈帧而占用太多空间，导致栈空间过深。那么当线程请求栈的深度超过当前 Java 虚拟机栈的最大深度的时候，就抛出 `StackOverFlowError` 错误。 **栈帧生命周期** Java 方法有两种返回方式，一种是 return 语句正常返回，一种是抛出异常。不管哪种返回方式，都会导致栈帧被弹出。也就是说， **栈帧随着方法调用而创建，随着方法结束而销毁。无论方法正常完成还是异常完成都算作方法结束。** **OutOfMemoryError** 除了 `StackOverFlowError` 错误之外，栈还可能会出现 `OutOfMemoryError` 错误，这是因为如果栈的内存大小可以动态扩展， 如果虚拟机在动态扩展栈时无法申请到足够的内存空间，则抛出`OutOfMemoryError`异常。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-e0e34b907fbda47444dc9702e88857c07ca743f8%2FPasted%20image%2020250213163754.png?alt=media) ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-1662e095496fd95d87c92376175712afc7fcdaa0%2FPasted%20image%2020250213164015.png?alt=media) **本地方法栈** 和虚拟机栈所发挥的作用非常相似，区别是：**虚拟机栈为虚拟机执行 Java 方法 （也就是字节码）服务，而本地方法栈则为虚拟机使用到的 Native 方法服务。** 在 HotSpot 虚拟机中和 Java 虚拟机栈合二为一。 **堆** Java 虚拟机所管理的内存中最大的一块，Java 堆是所有线程共享的一块内存区域，在虚拟机启动时创建。**此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例以及数组都在这里分配内存。** 从 JDK 1.7 开始已经默认开启逃逸分析，如果某些方法中的对象引用没有被返回或者未被外面使用（也就是未逃逸出去），那么对象可以直接在栈上分配内存。 Java 堆是垃圾收集器管理的主要区域，因此也被称作 **GC 堆（Garbage Collected Heap）**。从垃圾回收的角度，由于现在收集器基本都采用分代垃圾收集算法，所以 Java 堆还可以细分为：新生代和老年代；再细致一点有：Eden、Survivor、Old 等空间。进一步划分的目的是更好地回收内存，或者更快地分配内存。 在 JDK 7 版本及 JDK 7 版本之前，堆内存被通常分为下面三部分： * 新生代内存(Young Generation) * 老生代(Old Generation) * 永久代(Permanent Generation) Eden 区、两个 Survivor 区 S0 和 S1 都属于新生代，中间一层属于老年代，最下面一层属于永久代。 **JDK 8 版本之后 PermGen（永久代）已被 Metaspace（元空间）取代，元空间使用的是本地内存。** 大部分情况，对象都会首先在 Eden 区域分配，在一次新生代垃圾回收后，如果对象还存活，则会进入 S0 或者 S1，并且对象的年龄还会加 1（Eden 区->Survivor 区后对象的初始年龄变为 1），当它的年龄增加到一定程度（默认为 15 岁），就会被晋升到老年代中。对象晋升到老年代的年龄阈值，可以通过参数 `-XX:MaxTenuringThreshold` 来设置。不过，设置的值应该在 0-15。 **为什么年龄只能是 0-15？** 在 HotSpot 虚拟机中，对象在内存中存储的布局可以分为 3 块区域：对象头（Header）、实例数据（Instance Data）和对齐填充（Padding）。其中，对象头包括两部分：标记字段（Mark Word）和类型指针（Klass Word）。 因为记录年龄的区域在标记字段中（标记字段还存放了对象自身的其他信息比如哈希码、锁状态信息等等），这个区域的大小通常是 4 位。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-5516e9a526e5d11ad4e79e29fab9f0ffc49eafef%2FPasted%20image%2020250213164319.png?alt=media) **方法区** 方法区属于是 JVM 运行时数据区域的一块**逻辑区域**，是各个线程共享的内存区域。 **当虚拟机要使用一个类时，它需要读取并解析 Class 文件获取相关信息，再将信息存入到方法区**。方法区会存储已被虚拟机加载的 **类信息、字段信息、方法信息、常量、静态变量、即时编译器编译后的代码缓存等数据**。 **方法区和永久代以及元空间是什么关系呢？** 方法区和永久代以及元空间的关系很像 Java 中接口和类的关系，类实现了接口，这里的类就可以看作是永久代和元空间，接口可以看作是方法区，也就是说永久代以及元空间是 HotSpot 虚拟机对虚拟机规范中方法区的两种实现方式。并且，永久代是 JDK 1.8 之前的方法区实现，JDK 1.8 及以后方法区的实现变成了元空间。 **为什么要将永久代 (PermGen) 替换为元空间 (MetaSpace) 呢？** * 整个永久代有一个 JVM 本身设置的固定大小上限，无法进行调整（也就是受到 JVM 内存的限制），而元空间使用的是本地内存，受本机可用内存的限制，虽然元空间仍旧可能溢出，但是比原来出现的几率会更小。 * 元空间里面存放的是类的元数据，这样加载多少类的元数据就不由 `MaxPermSize` 控制了, 而由系统的实际可用空间来控制，这样能加载的类就更多了。 * 在 JDK8，合并 HotSpot 和 JRockit 的代码时, JRockit 从来没有一个叫永久代的东西, 合并之后就没有必要额外的设置这么一个永久代的地方了。 * 永久代会为 GC 带来不必要的复杂度，并且回收效率偏低。 与永久代很大的不同就是，如果不指定大小的话，随着更多类的创建，虚拟机会耗尽所有可用的系统内存。 **运行时常量池** Class 文件中除了有类的版本、字段、方法、接口等描述信息外，还有用于存放编译期生成的各种字面量（Literal）和符号引用（Symbolic Reference）的 **常量池表(Constant Pool Table)** 。 字面量是源代码中的固定值的表示法，即通过字面我们就能知道其值的含义。字面量包括整数、浮点数和字符串字面量。常见的符号引用包括类符号引用、字段符号引用、方法符号引用、接口方法符号。 常量池表会在类加载后存放到方法区的运行时常量池中。运行时常量池的功能类似于传统编程语言的符号表，尽管它包含了比典型符号表更广泛的数据。 既然运行时常量池是方法区的一部分，自然受到方法区内存的限制，当常量池无法再申请到内存时会抛出 `OutOfMemoryError` 错误。 **字符串常量池** **字符串常量池** 是 JVM 为了提升性能和减少内存消耗针对字符串（String 类）专门开辟的一块区域，主要目的是为了避免字符串的重复创建。 JDK1.7 之前，字符串常量池存放在永久代。JDK1.7 字符串常量池和静态变量从永久代移动到了 Java 堆中。 **JDK 1.7 为什么要将字符串常量池移动到堆中？** 主要是因为永久代（方法区实现）的 GC 回收效率太低，只有在整堆收集 (Full GC）的时候才会被执行 GC。Java 程序中通常会有大量的被创建的字符串等待回收，将字符串常量池放到堆中，能够更高效及时地回收字符串内存。 **直接内存** 直接内存是一种特殊的内存缓冲区，并不在 Java 堆或方法区中分配的，而是通过 JNI 的方式在本地内存上分配的。 直接内存并不是虚拟机运行时数据区的一部分，也不是虚拟机规范中定义的内存区域，但是这部分内存也被频繁地使用。而且也可能导致 `OutOfMemoryError` 错误出现。 JDK1.4 中新加入的 **NIO（Non-Blocking I/O，也被称为 New I/O）**，引入了一种基于**通道（Channel）与缓存区（Buffer）的 I/O 方式，它可以直接使用 Native 函数库直接分配堆外内存，然后通过一个存储在 Java 堆中的 DirectByteBuffer 对象作为这块内存的引用进行操作。这样就能在一些场景中显著提高性能，因为避免了在 Java 堆和 Native 堆之间来回复制数据**。 直接内存的分配不会受到 Java 堆的限制，但是，既然是内存就会受到本机总内存大小以及处理器寻址空间的限制。 堆外内存就是把内存对象分配在堆外的内存，这些内存直接受操作系统管理（而不是虚拟机），这样做的结果就是能够在一定程度上减少垃圾回收对应用程序造成的影响。 #### HotSpot 虚拟机对象探秘 **对象的创建** **类加载检查** 虚拟机遇到一条 new 指令时，首先将去检查这个指令的参数是否能在常量池中定位到这个类的符号引用，并且检查这个符号引用代表的类是否已被加载过、解析和初始化过。如果没有，那必须先执行相应的类加载过程。 **分配内存** 在**类加载检查**通过后，接下来虚拟机将为新生对象**分配内存**。对象所需的内存大小在类加载完成后便可确定，为对象分配空间的任务等同于把一块确定大小的内存从 Java 堆中划分出来。**分配方式**有 **“指针碰撞”** 和 **“空闲列表”** 两种，**选择哪种分配方式由 Java 堆是否规整决定，而 Java 堆是否规整又由所采用的垃圾收集器是否带有压缩整理功能决定**。 **内存分配的两种方式** 指针碰撞： * 适用场合：堆内存规整（即没有内存碎片）的情况下。 * 原理：用过的内存全部整合到一边，没有用过的内存放在另一边，中间有一个分界指针，只需要向着没用过的内存方向将该指针移动对象内存大小位置即可。 * 使用该分配方式的 GC 收集器：Serial, ParNew 空闲列表： * 适用场合：堆内存不规整的情况下。 * 原理：虚拟机会维护一个列表，该列表中会记录哪些内存块是可用的，在分配的时候，找一块儿足够大的内存块儿来划分给对象实例，最后更新列表记录。 * 使用该分配方式的 GC 收集器：CMS 选择以上两种方式中的哪一种，取决于 Java 堆内存是否规整。而 Java 堆内存是否规整，取决于 GC 收集器的算法是"标记-清除"，还是"标记-整理"（也称作"标记-压缩"），值得注意的是，复制算法内存也是规整的。 **内存分配并发问题** 在创建对象的时候有一个很重要的问题，就是线程安全，因为在实际开发过程中，创建对象是很频繁的事情，作为虚拟机来说，必须要保证线程是安全的，通常来讲，虚拟机采用两种方式来保证线程安全： * **CAS+失败重试：** CAS 是乐观锁的一种实现方式。所谓乐观锁就是，每次不加锁而是假设没有冲突而去完成某项操作，如果因为冲突失败就重试，直到成功为止。**虚拟机采用 CAS 配上失败重试的方式保证更新操作的原子性。** * **TLAB：** 为每一个线程预先在 Eden 区分配一块儿内存，JVM 在给线程中的对象分配内存时，首先在 TLAB 分配，当对象大于 TLAB 中的剩余内存或 TLAB 的内存已用尽时，再采用上述的 CAS 进行内存分配 **初始化零值** 内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象头），这一步操作保证了对象的实例字段在 Java 代码中可以不赋初始值就直接使用，程序能访问到这些字段的数据类型所对应的零值。 **设置对象头** 初始化零值完成之后，虚拟机要对对象进行必要的设置，例如**这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的 GC 分代年龄等信息**。 **这些信息存放在对象头中。** 另外，根据虚拟机当前运行状态的不同，如是否启用偏向锁等，对象头会有不同的设置方式。 **执行 init 方法** 在上面工作都完成之后，从虚拟机的视角来看，一个新的对象已经产生了，但从 Java 程序的视角来看，对象创建才刚开始，`` 方法还没有执行，所有的字段都还为零。所以一般来说，执行 new 指令之后会接着执行 `` 方法，把对象按照程序员的意愿进行初始化，这样一个真正可用的对象才算完全产生出来。 **对象的内存布局** 在 Hotspot 虚拟机中，对象在内存中的布局可以分为 3 块区域：**对象头（Header）、实例数据（Instance Data）和对齐填充（Padding）**。 对象头包括两部信息： * 标记字段（Mark Word）：用于存储对象自身的运行时数据， 如哈希码（HashCode）、GC 分代年龄、锁状态标志、线程持有的锁、偏向线程 ID、偏向时间戳等等。 * 类型指针（Klass pointer）：对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。 **实例数据部分是对象真正存储的有效信息**，也是在程序中所定义的各种类型的字段内容。 **对齐填充部分不是必然存在的，也没有什么特别的含义，仅仅起占位作用。** 因为 Hotspot 虚拟机的自动内存管理系统要求对象起始地址必须是 8 字节的整数倍，换句话说就是对象的大小必须是 8 字节的整数倍 **对象的访问定位** 建立对象就是为了使用对象，我们的 Java 程序通过栈上的 reference 数据来操作堆上的具体对象。对象的访问方式由虚拟机实现而定，目前主流的访问方式有：**使用句柄**、**直接指针**。 **句柄** 如果使用句柄的话，那么 Java 堆中将会划分出一块内存来作为句柄池，reference 中存储的就是对象的句柄地址，而句柄中包含了对象实例数据与对象类型数据各自的具体地址信息。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-292e574e0d8c03164cfbb796225bb5e171dff5b5%2FPasted%20image%2020250213172445.png?alt=media) **直接指针** 如果使用直接指针访问，reference 中存储的直接就是对象的地址。 这两种对象访问方式各有优势。使用句柄来访问的最大好处是 reference 中存储的是稳定的句柄地址，在对象被移动时只会改变句柄中的实例数据指针，而 reference 本身不需要修改。使用直接指针访问方式最大的好处就是速度快，它节省了一次指针定位的时间开销。 HotSpot 虚拟机主要使用的就是这种方式来进行对象访问。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-292e574e0d8c03164cfbb796225bb5e171dff5b5%2FPasted%20image%2020250213172528.png?alt=media) ### JVM 垃圾回收详解 #### 内存分配和回收原则 **对象优先在 Eden 区分配** 大多数情况下，对象在新生代中 Eden 区分配。当 Eden 区没有足够空间进行分配时，虚拟机将发起一次 Minor GC。 **大对象直接进入老年代** 大对象就是需要大量连续内存空间的对象（比如：字符串、数组）。 大对象直接进入老年代的行为是由虚拟机动态决定的，它与具体使用的垃圾回收器和相关参数有关。大对象直接进入老年代是一种优化策略，旨在避免将大对象放入新生代，从而减少新生代的垃圾回收频率和成本。 **长期存活的对象将进入老年代** 既然虚拟机采用了分代收集的思想来管理内存，那么内存回收时就必须能识别哪些对象应放在新生代，哪些对象应放在老年代中。为了做到这一点，虚拟机给每个对象一个对象年龄（Age）计数器。 大部分情况，对象都会首先在 Eden 区域分配。如果对象在 Eden 出生并经过第一次 Minor GC 后仍然能够存活，并且能被 Survivor 容纳的话，将被移动到 Survivor 空间（s0 或者 s1）中，并将对象年龄设为 1(Eden 区->Survivor 区后对象的初始年龄变为 1)。 对象在 Survivor 中每熬过一次 MinorGC，年龄就增加 1 岁，当它的年龄增加到一定程度（默认为 15 岁），就会被晋升到老年代中。 **主要进行 gc 的区域** 针对 HotSpot VM 的实现，它里面的 GC 其实准确分类只有两大种： 部分收集 (Partial GC)： * 新生代收集（Minor GC / Young GC）：只对新生代进行垃圾收集； * 老年代收集（Major GC / Old GC）：只对老年代进行垃圾收集。需要注意的是 Major GC 在有的语境中也用于指代整堆收集； * 混合收集（Mixed GC）：对整个新生代和部分老年代进行垃圾收集。 整堆收集 (Full GC)：收集整个 Java 堆和方法区。 **空间分配担保** 空间分配担保是为了确保在 Minor GC 之前老年代本身还有容纳新生代所有对象的剩余空间。 #### 死亡对象判断方法 堆中几乎放着所有的对象实例，对堆垃圾回收前的第一步就是要判断哪些对象已经死亡（即不能再被任何途径使用的对象）。 **引用计数法** 给对象中添加一个引用计数器： * 每当有一个地方引用它，计数器就加 1； * 当引用失效，计数器就减 1； * 任何时候计数器为 0 的对象就是不可能再被使用的。 **这个方法实现简单，效率高，但是目前主流的虚拟机中并没有选择这个算法来管理内存，其最主要的原因是它很难解决对象之间循环引用的问题。** **可达性分析算法** 这个算法的基本思想就是通过一系列的称为 **“GC Roots”** 的对象作为起点，从这些节点开始向下搜索，节点所走过的路径称为引用链，当一个对象到 GC Roots 没有任何引用链相连的话，则证明此对象是不可用的，需要被回收。 **哪些对象可以作为 GC Roots 呢？** * 虚拟机栈（栈帧中的局部变量表）中引用的对象 * 本地方法栈（Native 方法）中引用的对象 * 方法区中类静态属性引用的对象 * 方法区中常量引用的对象 * 所有被同步锁持有的对象 * JNI（Java Native Interface）引用的对象 **对象可以被回收，就代表一定会被回收吗？** 即使在可达性分析法中不可达的对象，也并非是“非死不可”的，这时候它们暂时处于“缓刑阶段”，要真正宣告一个对象死亡，至少要经历两次标记过程；可达性分析法中不可达的对象被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行 `finalize` 方法。当对象没有覆盖 `finalize` 方法，或 `finalize` 方法已经被虚拟机调用过时，虚拟机将这两种情况视为没有必要执行。 被判定为需要执行的对象将会被放在一个队列中进行第二次标记，除非这个对象与引用链上的任何一个对象建立关联，否则就会被真的回收。 `Object` 类中的 `finalize` 方法一直被认为是一个糟糕的设计，成为了 Java 语言的负担，影响了 Java 语言的安全和 GC 的性能。JDK9 版本及后续版本中各个类中的 `finalize` 方法会被逐渐弃用移除。 **三色标记算法** 三色指的是白色，灰色，黑色（white，gray，black）。抽象的理解，可以认为垃圾收集器在标记阶段将对象染成不同的颜色，根据不同的颜色做不同处理。那么三种染色的对象分别指什么呢？ **白色** * 在标记开始时，堆内存中的对象都是白色的。 * 在标记结束时，仍然是白色的对象，将会被视为已死的对象而被清除。 **灰色** 灰色是由白色标记成为灰色，表示该对象Obj是根可达对象（存活的对象，不会被清理）,但Obj的所有引用的对象还没被垃圾收集器访问；灰色是一个过渡色，最终都会被标记为黑色。 **黑色** 黑色是由灰色标记成为黑色，表示该对象Obj以及Obj的所有下级引用对象都已经被垃圾收集器访问并标记，Obj不会被垃圾收集器再次访问以查看是否有引用对象；此时Obj是黑色（存活的对象，不会被清理），Obj的所有引用的对象被标记为灰色。 **引用类型总结** 无论是通过引用计数法判断对象引用数量，还是通过可达性分析法判断对象的引用链是否可达，判定对象的存活都与“引用”有关。 JDK1.2 之前，Java 中引用的定义很传统：如果 reference 类型的数据存储的数值代表的是另一块内存的起始地址，就称这块内存代表一个引用。 JDK1.2 以后，Java 对引用的概念进行了扩充，将引用分为强引用、软引用、弱引用、虚引用四种（引用强度逐渐减弱），强引用就是Java中普通的对象，而软引用、弱引用、虚引用在JDK中定义的类分别是SoftReference、WeakReference、PhantomReference。 **强引用（Strong Reference）** * **定义**：强引用是 Java 中最常见的引用类型，通过赋值操作符 `=` 创建的普通引用即为强引用。 * **特性**： * **内存优先级最高**：只要强引用存在，垃圾回收器（GC）永远不会回收引用指向的对象，即使系统内存不足，也不会回收强引用对象，直到强引用被显式地设置为 `null` 或超出其作用域。 * **容易造成内存泄漏**：如果某些不再使用的对象还存在强引用，会导致内存一直无法释放，造成内存泄漏。 * **使用场景**：强引用适合用于那些必须保留的对象，比如系统的核心对象、关键数据等。 **软引用（Soft Reference）** * **定义**：软引用是一种相对较弱的引用类型，可通过 `java.lang.ref.SoftReference` 类实现。 * **特性**： * **内存不紧张时不回收**：只有在 JVM 内存不足时，垃圾回收器才会回收软引用对象。 * **缓存实现利器**：软引用特别适合用于缓存。内存充足时保留缓存对象，内存紧张时释放缓存，以确保内存资源可以被更重要的任务使用。 * **使用场景**：适用于缓存场景。例如，在图片加载、文件缓存等场景下，利用软引用可以缓存对象，以便重复利用。如果内存不够用，缓存会自动被回收释放，减轻内存压力。 **弱引用（Weak Reference）** * **定义**：弱引用是一种比软引用更弱的引用类型，可通过 `java.lang.ref.WeakReference` 类实现。 * **特性**： * **易回收**：弱引用对象几乎总是会被及时回收，这使得它很适合存放不重要的对象。 * **避免内存泄漏**：弱引用可以有效防止内存泄漏，适合用来管理临时对象或需要动态清除的数据。 * **使用场景**：弱引用常用于存储像 `ThreadLocal` 中的键值对、某些映射中的临时对象（例如 `WeakHashMap`）等场景，确保它们在不被使用时能及时被垃圾回收。 **虚引用（Phantom Reference）** * **定义**：虚引用是一种最弱的引用类型，可通过 `java.lang.ref.PhantomReference` 类实现。虚引用不能单独使用，必须与 `ReferenceQueue` 配合使用。 * **特性**： * **无法访问引用对象**：通过虚引用无法访问对象的任何属性或方法。 * **用作回收监控**：在对象即将被 GC 回收时，虚引用会被加入 `ReferenceQueue`，可以通过 `ReferenceQueue` 来执行一些资源释放操作。 * **使用场景**：虚引用通常用于管理直接内存或文件资源的释放，尤其是那些不在 JVM 管理的内存资源。虚引用可以作为一种监控手段，确保对象被回收时，能自动清理掉相关资源。 **如何判断一个常量是废弃常量？** 假如在字符串常量池中存在字符串 "abc"，如果当前没有任何 String 对象引用该字符串常量的话，就说明常量 "abc" 就是废弃常量，如果这时发生内存回收的话而且有必要的话，"abc" 就会被系统清理出常量池了。 **如何判断一个类是无用的类？** 类需要同时满足下面 3 个条件才能算是 **“无用的类”**： * 该类所有的实例都已经被回收，也就是 Java 堆中不存在该类的任何实例。 * 加载该类的 `ClassLoader` 已经被回收。 * 该类对应的 `java.lang.Class` 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。 虚拟机可以对满足上述 3 个条件的无用类进行回收，这里说的仅仅是“可以”，而并不是和对象一样不使用了就会必然被回收。 #### 垃圾收集算法 **标记-清除算法** 标记-清除（Mark-and-Sweep）算法分为“标记（Mark）”和“清除（Sweep）”阶段：首先标记出所有不需要回收的对象，在标记完成后统一回收掉所有没有被标记的对象。 它是最基础的收集算法，后续的算法都是对其不足进行改进得到。这种垃圾收集算法会带来两个明显的问题： * **效率问题**：标记和清除两个过程效率都不高。 * **空间问题**：标记清除后会产生大量不连续的内存碎片。 **复制算法** 为了解决标记-清除算法的效率和内存碎片问题，复制（Copying）收集算法出现了。它可以将内存分为大小相同的两块，每次使用其中的一块。当这一块的内存使用完后，就将还存活的对象复制到另一块去，然后再把使用的空间一次清理掉。这样就使每次的内存回收都是对内存区间的一半进行回收。 虽然改进了标记-清除算法，但依然存在下面这些问题： * **可用内存变小**：可用内存缩小为原来的一半。 * **不适合老年代**：如果存活对象数量比较大，复制性能会变得很差。 **标记-整理算法** 标记-整理（Mark-and-Compact）算法是根据老年代的特点提出的一种标记算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象回收，而是让所有存活的对象向一端移动，然后直接清理掉端边界以外的内存。 **分代收集算法** 当前虚拟机的垃圾收集都采用分代收集算法，这种算法没有什么新的思想，只是根据对象存活周期的不同将内存分为几块。一般将 Java 堆分为新生代和老年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。 比如在新生代中，每次收集都会有大量对象死去，所以可以选择“复制”算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。而老年代的对象存活几率是比较高的，而且没有额外的空间对它进行分配担保，所以我们必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。 #### 垃圾收集器 **如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现**。直到现在为止还没有最好的垃圾收集器出现，更加没有万能的垃圾收集器，**我们能做的就是根据具体应用场景选择适合自己的垃圾收集器**。 JDK 默认垃圾收集器（使用 `java -XX:+PrintCommandLineFlags -version` 命令查看）： * JDK 8: Parallel Scavenge（新生代）+ Parallel Old（老年代） * JDK 9 \~ JDK22: G1 **CMS 收集器** **CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。它非常符合在注重用户体验的应用上使用。** **CMS（Concurrent Mark Sweep）收集器是 HotSpot 虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。** 从名字中的**Mark Sweep**这两个词可以看出，CMS 收集器是一种 **“标记-清除”算法**实现的，它的运作过程相比于前面几种垃圾收集器来说更加复杂一些。整个过程分为四个步骤： * **初始标记：** 短暂停顿，标记直接与 root 相连的对象（根对象）； * **并发标记：** 同时开启 GC 和用户线程，用一个闭包结构去记录可达对象。但在这个阶段结束，这个闭包结构并不能保证包含当前所有的可达对象。因为用户线程可能会不断的更新引用域，所以 GC 线程无法保证可达性分析的实时性。所以这个算法里会跟踪记录这些发生引用更新的地方。 * **重新标记：** 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短 * **并发清除：** 开启用户线程，同时 GC 线程开始对未标记的区域做清扫。 从它的名字就可以看出它是一款优秀的垃圾收集器，主要优点：**并发收集、低停顿**。但是它有下面三个明显的缺点： * **对 CPU 资源敏感；** * **无法处理浮动垃圾；** * **它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生。** **CMS 垃圾回收器在 Java 9 中已经被标记为过时(deprecated)，并在 Java 14 中被移除。** ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-218fe1243a5c841a09b95ff2d4b2e818e8e946f8%2FPasted%20image%2020250314150356.png?alt=media) **G1 垃圾收集器** **G1 (Garbage-First) 是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器. 以极高概率满足 GC 停顿时间要求的同时,还具备高吞吐量性能特征**。它具备以下特点： * **并行与并发**：G1 能充分利用 CPU、多核环境下的硬件优势，使用多个 CPU（CPU 或者 CPU 核心）来缩短 Stop-The-World 停顿时间。部分其他收集器原本需要停顿 Java 线程执行的 GC 动作，G1 收集器仍然可以通过并发的方式让 java 程序继续执行。 * **分代收集**：虽然 G1 可以不需要其他收集器配合就能独立管理整个 GC 堆，但是还是保留了分代的概念。 * **空间整合**：与 CMS 的“标记-清除”算法不同，G1 从整体来看是基于“标记-整理”算法实现的收集器；从局部上来看是基于“标记-复制”算法实现的。 * **可预测的停顿**：这是 G1 相对于 CMS 的另一个大优势，降低停顿时间是 G1 和 CMS 共同的关注点，但 G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为 M 毫秒的时间片段内，消耗在垃圾收集上的时间不得超过 N 毫秒。 G1 收集器的运作大致分为以下几个步骤： * **初始标记**： 短暂停顿（Stop-The-World，STW），标记从 GC Roots 可直接引用的对象，即标记所有直接可达的活跃对象 * **并发标记**：与应用并发运行，标记所有可达对象。 这一阶段可能持续较长时间，取决于堆的大小和对象的数量。 * **最终标记**： 短暂停顿（STW），处理并发标记阶段结束后残留的少量未处理的引用变更。 * **筛选回收**：根据标记结果，选择回收价值高的区域，复制存活对象到新区域，回收旧区域内存。这一阶段包含一个或多个停顿（STW），具体取决于回收的复杂度。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-70bbe51ef925a555d3bcc5658f33d1d9e6ee2b6d%2FPasted%20image%2020250314150602.png?alt=media) **G1 收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的 Region（这也就是它的名字 Garbage-First 的由来）** 。这种使用 Region 划分内存空间以及有优先级的区域回收方式，保证了 G1 收集器在有限时间内可以尽可能高的收集效率（把内存化整为零）。 G1回收无论是年轻代还是老年代主要的回收算法是复制算法，它会将要回收Region的存活对象挪到相邻的空的Region，然后清空之前的Region，这样就保证了内存碎片的减少。 G1的调优主要就是针对于 -XX:MaxGCPauseMills 最大暂停时间参数去调优的，这个参数不能太大也不能太小。 * 如果这个参数过于大，minor gc将很少发生，在它发生时有极大可能会有大量的存活对象进入Survivor区，如果Survivor放不下，就会进入老年代，就很容易触发mixed gc，不建议。 * 在触发minor gc时很难回收到垃圾，最后导致垃圾太多，空间被占，也很容易触发mixed gc。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-70bbe51ef925a555d3bcc5658f33d1d9e6ee2b6d%2FPasted%20image%2020250213193620.png?alt=media) **ZGC 收集器** 与 CMS 中的 ParNew 和 G1 类似，ZGC 也采用标记-复制算法，不过 ZGC 对该算法做了重大改进。 ZGC 可以将暂停时间控制在几毫秒以内，且暂停时间不受堆内存大小的影响，出现 Stop The World 的情况会更少，但代价是牺牲了一些吞吐量。ZGC 最大支持 16TB 的堆内存。 ### JVM 类文件结构详解 #### Class 文件结构 根据 Java 虚拟机规范，Class 文件通过 `ClassFile` 定义，类似 C 语言的结构体。 ```java ClassFile { u4 magic; //Class 文件的标志 u2 minor_version;//Class 的小版本号 u2 major_version;//Class 的大版本号 u2 constant_pool_count;//常量池的数量 cp_info constant_pool[constant_pool_count-1];//常量池 u2 access_flags;//Class 的访问标记 u2 this_class;//当前类 u2 super_class;//父类 u2 interfaces_count;//接口数量 u2 interfaces[interfaces_count];//一个类可以实现多个接口 u2 fields_count;//字段数量 field_info fields[fields_count];//一个类可以有多个字段 u2 methods_count;//方法数量 method_info methods[methods_count];//一个类可以有个多个方法 u2 attributes_count;//此类的属性表中的属性数 attribute_info attributes[attributes_count];//属性表集合 } ``` ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-97daf190c58f636c0c624be6e8446711c8de41d3%2FPasted%20image%2020250213222010.jpg?alt=media) ### JVM 类加载过程详解 #### 类的生命周期 类从被加载到虚拟机内存中开始到卸载出内存为止，它的整个生命周期可以简单概括为 7 个阶段：**加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）**。其中，验证、准备和解析这三个阶段可以统称为连接（Linking）。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-92ed5020ac20e89500a21c9581a28dfc3c021bb5%2FPasted%20image%2020250213222225.png?alt=media) #### 类加载过程 Class 文件需要加载到虚拟机中之后才能运行和使用，系统加载 Class 类型的文件主要三步：**加载->连接->初始化**。连接过程又可分为三步：**验证->准备->解析**。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-b283bfd7fe956e04d288cb10067479b26ca6f866%2FPasted%20image%2020250213223319.png?alt=media) **加载** 类加载过程主要完成下面 3 件事情： * **二进制获取**：通过全限定名（如`java.lang.String`）获取字节流，来源包括JAR包、网络、动态代理等 * **数据结构转换**：将静态存储结构转换为方法区的运行时数据结构。 * **Class对象生成**：在堆内存中创建`java.lang.Class`实例，作为访问入口。 加载这一步主要是通过 **类加载器** 完成的。类加载器有很多种，当我们想要加载一个类的时候，具体是哪个类加载器加载由 **双亲委派模型** 决定（不过，我们也能打破由双亲委派模型）。 每个 Java 类都有一个引用指向加载它的 `ClassLoader`。不过，数组类不是通过 `ClassLoader` 创建的，而是 JVM 在需要的时候自动创建的，数组类通过`getClassLoader()`方法获取 `ClassLoader` 的时候和该数组的元素类型的 `ClassLoader` 是一致的。 一个非数组类的加载阶段（加载阶段获取类的二进制字节流的动作）是可控性最强的阶段，这一步我们可以去完成还可以自定义类加载器去控制字节流的获取方式（重写一个类加载器的 `loadClass()` 方法）。 **验证** **验证是连接阶段的第一步，这一阶段的目的是确保 Class 文件的字节流中包含的信息符合《Java 虚拟机规范》的全部约束要求，保证这些信息被当作代码运行后不会危害虚拟机自身的安全。** 验证阶段主要由四个检验阶段组成： * **文件格式验证**（Class 文件格式检查）：魔数检查（是否以`0xCAFEBABE`开头）、版本号验证等 * **元数据验证**（字节码语义检查）：语义检查（是否继承final类、抽象方法实现等） * **字节码验证**（程序语义检查）：程序逻辑验证（类型转换是否合法、跳转指令正确性等） * **符号引用验证**（类的正确性检查）：确保后续解析能正常执行（检查引用的类/方法是否存在） **文件格式验证** 文件格式验证这一阶段是基于该类的二进制字节流进行的，主要目的是保证输入的字节流能正确地解析并存储于方法区之内，格式上符合描述一个 Java 类型信息的要求。除了这一阶段之外，其余三个验证阶段都是基于方法区的存储结构上进行的，不会再直接读取、操作字节流了。 **符号引用验证** 符号引用验证发生在类加载过程中的解析阶段，具体点说是 JVM 将符号引用转化为直接引用的时候（解析阶段会介绍符号引用和直接引用）,符号引用验证的主要目的是确保解析阶段能正常执行，如果无法通过符号引用验证，JVM 会抛出异常： * `java.lang.IllegalAccessError`：当类试图访问或修改它没有权限访问的字段，或调用它没有权限访问的方法时，抛出该异常。 * `java.lang.NoSuchFieldError`：当类试图访问或修改一个指定的对象字段，而该对象不再包含该字段时，抛出该异常。 * `java.lang.NoSuchMethodError`：当类试图访问一个指定的方法，而该方法不存在时，抛出该异常。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-04d61435b3f82fbea71a86c7b806f00dd2cd6db9%2FPasted%20image%2020250213223825.png?alt=media) **准备** **准备阶段是正式为类变量分配内存并设置类变量初始值的阶段**，这些内存都将在方法区中分配。对于该阶段有以下几点需要注意： * 这时候进行内存分配的仅包括类变量（ Class Variables ，即静态变量，被 `static` 关键字修饰的变量，只与类相关，因此被称为类变量），而不包括实例变量。实例变量会在对象实例化时随着对象一块分配在 Java 堆中。 * 从概念上讲，类变量所使用的内存都应当在 **方法区** 中进行分配。在 JDK 7 及之后，HotSpot 已经把原本放在永久代的字符串常量池、静态变量等移动到堆中，这个时候类变量则会随着 Class 对象一起存放在 Java 堆中。 * 这里所设置的初始值"通常情况"下是数据类型默认的零值（如 0、0L、null、false 等），非 final 变量初始化阶段才会赋值。 **解析** **解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。** 解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用限定符 7 类符号引用进行。 **初始化** **初始化阶段是执行初始化方法 ` ()`方法的过程，是类加载的最后一步，这一步 JVM 才开始真正执行类中定义的 Java 程序代码（字节码）。** 对于 ` ()` 方法的调用，虚拟机会自己确保其在多线程环境中的安全性。因为 ` ()` 方法是带锁线程安全，所以在多线程环境下进行类初始化的话可能会引起多个线程阻塞，并且这种阻塞很难被发现。 对于初始化阶段，虚拟机严格规范了有且只有 6 种情况下，必须对类进行初始化（只有主动去使用类才会初始化类）： * 当遇到 `new`、 `getstatic`、`putstatic` 或 `invokestatic` 这 4 条字节码指令时，比如 `new` 一个类，读取一个静态字段(未被 final 修饰)、或调用一个类的静态方法时。 * 使用 `java.lang.reflect` 包的方法对类进行反射调用时如 `Class.forName("...")`, `newInstance()` 等等。如果类没初始化，需要触发其初始化。 * 初始化一个类，如果其父类还未初始化，则先触发该父类的初始化。 * 当虚拟机启动时，用户需要定义一个要执行的主类 (包含 `main` 方法的那个类)，虚拟机会先初始化这个类。 * `MethodHandle` 和 `VarHandle` 可以看作是轻量级的反射调用机制，而要想使用这 2 个调用，就必须先使用 `findStaticVarHandle` 来初始化要调用的类。 * 当一个接口中定义了 JDK8 新加入的默认方法（被 default 关键字修饰的接口方法）时，如果有这个接口的实现类发生了初始化，那该接口要在其之前被初始化。 #### 类加载器 **类加载器作用** **类加载器的主要作用就是动态加载 Java 类的字节码（ `.class` 文件）到 JVM 中（在内存中生成一个代表该类的 `Class` 对象）** 。字节码可以是 Java 源程序（`.java`文件）经过 `javac` 编译得来，也可以是通过工具动态生成或者通过网络下载得来。 * 类加载器是一个负责加载类的对象，用于实现类加载过程中的加载这一步。 * 每个 Java 类都有一个引用指向加载它的 `ClassLoader`。 * 数组类不是通过 `ClassLoader` 创建的（数组类没有对应的二进制字节流），是由 JVM 直接生成的。 **类加载器加载规则** JVM 启动的时候，并不会一次性加载所有的类，而是根据需要去动态加载。也就是说，大部分类在具体用到的时候才会去加载，这样对内存更加友好。 对于已经加载的类会被放在 `ClassLoader` 中。在类加载的时候，系统会首先判断当前类是否被加载过。已经被加载的类会直接返回，否则才会尝试加载。也就是说，对于一个类加载器来说，相同二进制名称的类只会被加载一次。 **类加载器类型** JVM 中内置了三个重要的 `ClassLoader`： 1. **`BootstrapClassLoader`(启动类加载器)**：最顶层的加载类，由 C++实现，通常表示为 null，并且没有父级，主要用来加载 JDK 内部的核心类库（ `%JAVA_HOME%/lib`目录下的 `rt.jar`、`resources.jar`、`charsets.jar`等 jar 包和类）以及被 `-Xbootclasspath`参数指定的路径下的所有类。 2. **`ExtensionClassLoader`(扩展类加载器)**：主要负责加载 `%JRE_HOME%/lib/ext` 目录下的 jar 包和类以及被 `java.ext.dirs` 系统变量所指定的路径下的所有类。 3. **`AppClassLoader`(应用程序类加载器)**：面向我们用户的加载器，负责加载当前应用 classpath 下的所有 jar 包和类。 除了这三种类加载器之外，用户还可以加入自定义的类加载器来进行拓展，以满足自己的特殊需求。就比如说，我们可以对 Java 类的字节码（ `.class` 文件）进行加密，加载时再利用自定义的类加载器对其解密。 除了 `BootstrapClassLoader` 是 JVM 自身的一部分之外，其他所有的类加载器都是在 JVM 外部实现的，并且全都继承自 `ClassLoader`抽象类。这样做的好处是用户可以自定义类加载器，以便让应用程序自己决定如何去获取所需的类。 **每个 `ClassLoader` 可以通过`getParent()`获取其父 `ClassLoader`，如果获取到 `ClassLoader` 为`null`的话，那么该类是通过 `BootstrapClassLoader` 加载的**。这是因为`BootstrapClassLoader` 由 C++ 实现，由于这个 C++ 实现的类加载器在 Java 中是没有与之对应的类的，所以拿到的结果是 null。 **自定义类加载器** 如果我们要自定义自己的类加载器，需要继承 `ClassLoader`抽象类，`ClassLoader` 类有两个关键的方法： * `protected Class loadClass(String name, boolean resolve)`：加载指定二进制名称的类，实现了双亲委派机制 。`name` 为类的二进制名称，`resolve` 如果为 true，在加载时调用 `resolveClass(Class c)` 方法解析该类。如果想打破双亲委派模型则需要重写 `loadClass()` 方法。 * `protected Class findClass(String name)`：根据类的二进制名称来查找类，默认实现是空方法。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-02612d0e845c94b2e81b2ceddfba750884e352b2%2FPasted%20image%2020250213230543.png?alt=media) **类加载器应用场景** * **Web 服务器和应用容器**：不同的 Web 应用程序通过自定义类加载器加载各自的类文件，实现隔离和独立运行。 * **动态加载和更新**：允许在运行时动态加载类，如加载插件或更新应用程序。 * **安全沙箱**：为限制代码的权限，使用自定义类加载器创建隔离的环境。 * **测试框架**：在测试过程中，动态加载和卸载类，提供灵活的测试环境。 #### 双亲委派模型 **双亲委派模型** 双亲（父母辈）委派模型是一种类加载器之间的层次关系模型。在这个模型中，**当一个类加载器收到类加载请求时，它不会立即自己去加载这个类，而是把请求委托给父类加载器去完成。只有当父类加载器无法加载时，子类加载器才会尝试自己加载。这种委派机制保证了类的加载具有层次性，避免了类的重复加载和潜在的安全问题**。 * `ClassLoader` 类使用委托模型来搜索类和资源。 * 双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应有自己的父类加载器。 * `ClassLoader` 实例会在试图亲自查找类或资源之前，将搜索类或资源的任务委托给其父类加载器。 类加载器之间的父子关系一般不是以继承的关系来实现的，而是通常使用组合关系来复用父加载器的代码。在面向对象编程中，有一条非常经典的设计原则：**组合优于继承，多用组合少用继承。** **双亲委派模型流程** * 在类加载的时候，系统会首先判断当前类是否被加载过。已经被加载的类会直接返回，否则才会尝试加载（每个父类加载器都会走一遍这个流程）。 * 类加载器在进行类加载的时候，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成（调用父加载器 `loadClass()`方法来加载类）。这样的话，所有的请求最终都会传送到顶层的启动类加载器 `BootstrapClassLoader` 中。 * 只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载（调用自己的 `findClass()` 方法来加载类）。 * 如果子类加载器也无法加载这个类，那么它会抛出一个 `ClassNotFoundException` 异常。 **JVM 判定两个 Java 类是否相同的具体规则**：JVM 不仅要看类的全名是否相同，还要看加载此类的类加载器是否一样。只有两者都相同的情况，才认为两个类是相同的。即使两个类来源于同一个 `Class` 文件，被同一个虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相同。 **双亲委派模型优势** * **避免类的重复加载**：同一个类在不同的层次结构中只能由一个类加载器加载。例如，`java.lang.Object` 类的加载请求会被委派给顶层的启动类加载器 `BootstrapClassLoader`，而其他类加载器无法加载这个类，这样就避免了不同类加载器加载同一个类的情况，从而避免了多个不同版本的类出现在内存中。 * **保证了类的安全性**：它有效防止了恶意代码注入的可能性。例如，如果用户试图加载一个自定义的 `java.lang.Object` 类，双亲委派模型会确保这个类的加载请求被转交给顶层的启动类加载器 `BootstrapClassLoader`，而 `BootstrapClassLoader` 会从其内置的可信路径中加载 `java.lang.Object` 类，从而保证了核心 Java 类库的安全性。 * **实现了模块化管理**：通过不同层次的类加载器，可以将应用程序划分为不同的模块，每个模块可以有自己的类加载器，从而有效地管理类的加载和卸载。例如，在 Web 应用中，不同的 Web 应用程序可以由不同的类加载器加载，这样可以实现类的隔离和独立运行。 **打破双亲委派模型** 自定义加载器的话，需要继承 `ClassLoader` 。类加载器在进行类加载的时候，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成（调用父加载器 `loadClass()`方法来加载类）。重写 `loadClass()`方法之后，我们就可以改变传统双亲委派模型的执行流程。 Tomcat 服务器为了能够优先加载 Web 应用目录下的类，然后再加载其他目录下的类，就自定义了类加载器 `WebAppClassLoader` 来打破双亲委托机制。这也是 Tomcat 下 Web 应用之间的类实现隔离的具体原理。通过 `WebAppClassLoader`，每个 Web 应用可以加载自己目录下的类库，从而实现类的隔离。即使两个 Web 应用的类库版本不同，也不会互相干扰。 单纯依靠自定义类加载器没办法满足某些场景的要求，有些情况下，高层的类加载器需要加载低层的加载器才能加载的类。假设我们的项目中有 Spring 的 jar 包，由于其是 Web 应用之间共享的，因此会由 `SharedClassLoader` 加载（Web 服务器是 Tomcat）。我们项目中有一些用到了 Spring 的业务类，比如实现了 Spring 提供的接口、用到了 Spring 提供的注解。所以，加载 Spring 的类加载器（也就是 `SharedClassLoader`）也会用来加载这些业务类。但是业务类在 Web 应用目录下，不在 `SharedClassLoader` 的加载路径下，所以 `SharedClassLoader` 无法找到业务类，也就无法加载它们。 这个时候就需要用到 **线程上下文类加载器（`ThreadContextClassLoader`）** 了。当 Spring 需要加载业务类的时候，它不是用自己的类加载器，而是用当前线程的上下文类加载器。每个 Web 应用都会创建一个单独的 `WebAppClassLoader`，并在启动 Web 应用的线程里设置线程线程上下文类加载器为 `WebAppClassLoader`。这样就可以让高层的类加载器（`SharedClassLoader`）借助子类加载器（ `WebAppClassLoader`）来加载业务类，破坏了 Java 的类加载委托机制，让应用逆向使用类加载器。 线程上下文类加载器的原理是将一个类加载器保存在线程私有数据里，跟线程绑定，然后在需要的时候取出来使用。这个类加载器通常是由应用程序或者容器（如 Tomcat）设置的。 #### 类卸载 **卸载类即该类的 Class 对象被 GC**。要使一个类被卸载，必须满足以下条件： * **类的所有实例都被回收**：类的所有实例对象都已经被垃圾回收器回收，即没有任何活动对象引用该类。 * **类加载器不再存在**：加载该类的 `ClassLoader` 对象本身也被垃圾回收器回收。 * **类没有被其他类引用**：类不能有任何活动的引用，包括静态变量、线程等。 因此，在 JVM 生命周期内，由 jvm 自带的类加载器加载的类是不会被卸载的。但是由我们自定义的类加载器加载的类是可能被卸载的。 ### JVM 参数详解 #### 堆内存相关 与性能有关的最常见实践之一是根据应用程序要求初始化堆内存 `-Xms[unit] -Xmx[unit]`。 在堆总可用内存配置完成之后，第二大影响因素是为 `Young Generation（新生代内存）` 在堆内存所占的比例 \`-XX:NewSize=\[unit] -XX:MaxNewSize=\[unit]。 将新对象预留在新生代，由于 Full GC 的成本远高于 Minor GC，因此尽可能将对象分配在新生代是明智的做法，实际项目中根据 GC 日志分析新生代空间大小分配是否合理，适当通过“-Xmn”命令调节新生代大小，最大限度降低新对象直接进入老年代的情况。 从 Java 8 开始，如果我们没有指定 Metaspace（元空间） 的大小 `-XX:MaxMetaspaceSize`，随着更多类的创建，虚拟机会耗尽所有可用的系统内存（永久代并不会出现这种情况）。 Metaspace 由于使用不断扩容到 `-XX:MetaspaceSize` 参数指定的量，就会发生 Full GC，且之后每次 Metaspace 扩容都会发生 Full GC。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-dbffd06f5a3d46b4e90e641c5fd840e72ba9546a%2FPasted%20image%2020250214000509.png?alt=media) #### 垃圾收集相关 生产环境上，或者其他要测试 GC 问题的环境上，一定会配置上打印 GC 日志的参数，便于分析 GC 相关的问题。 ```bash # 必选 # 打印基本 GC 信息 -XX:+PrintGCDetails -XX:+PrintGCDateStamps # 打印对象分布 -XX:+PrintTenuringDistribution # 打印堆数据 -XX:+PrintHeapAtGC # 打印Reference处理信息 # 强引用/弱引用/软引用/虚引用/finalize 相关的方法 -XX:+PrintReferenceGC # 打印STW时间 -XX:+PrintGCApplicationStoppedTime # 可选 # 打印safepoint信息，进入 STW 阶段之前，需要要找到一个合适的 safepoint -XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1 # GC日志输出的文件路径 -Xloggc:/path/to/gc-%t.log # 开启日志文件分割 -XX:+UseGCLogFileRotation # 最多分割几个文件，超过之后从头文件开始写 -XX:NumberOfGCLogFiles=14 # 每个文件上限大小，超过就触发分割 -XX:GCLogFileSize=50M ``` 对于大型应用程序来说，面对内存不足错误 OOM 是非常常见的，这反过来会导致应用程序崩溃。这是一个非常关键的场景，很难通过复制来解决这个问题。这就是为什么 JVM 提供了一些参数，这些参数将堆内存转储到一个物理文件中，以后可以用来查找泄漏： ```bash -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./java_pid.hprof -XX:OnOutOfMemoryError="< cmd args >;< cmd args >" -XX:+UseGCOverheadLimit ``` ### JDK 监控和故障处理工具 #### JDK 命令行工具 这些命令在 JDK 安装目录下的 bin 目录下： * **`jps`** (JVM Process Status）: 类似 UNIX 的 `ps` 命令。用于查看所有 Java 进程的启动类、传入参数和 Java 虚拟机参数等信息； * **`jstat`**（JVM Statistics Monitoring Tool）: 用于收集 HotSpot 虚拟机各方面的运行数据; * **`jinfo`** (Configuration Info for Java) : Configuration Info for Java,显示虚拟机配置信息; * **`jmap`** (Memory Map for Java) : 生成堆转储快照; * **`jhat`** (JVM Heap Dump Browser) : 用于分析 heapdump 文件，它会建立一个 HTTP/HTML 服务器，让用户可以在浏览器上查看分析结果。JDK9 移除了 jhat； * **`jstack`** (Stack Trace for Java) : 生成虚拟机当前时刻的线程快照，线程快照就是当前虚拟机内每一条线程正在执行的方法堆栈的集合。 #### JDK 可视化分析工具 * JConsole：JConsole 是基于 JMX 的可视化监视、管理工具。可以很方便的监视本地及远程服务器的 java 进程的内存使用情况。 * Visual VM：多合一故障处理工具，VisualVM 提供在 Java 虚拟机 (Java Virtual Machine, JVM) 上运行的 Java 应用程序的详细信息。 ### JVM线上问题排查和性能调优案例 #### GC 在进行 JVM 性能优化时，观察垃圾回收（Garbage Collection，GC）的频率和停顿时间是关键步骤。通过这两个指标，可以判断应用的内存利用效率，并据此调整 JVM 的内存参数，以提高性能。 如果一个应用的 GC 频率只有 0.02，即每秒 GC 0.02 次，那么需要 50 秒才 GC 一次，那么其 GC 频率是很低的。这时候很可能是分配了较大的新生代空间，这使得其很久才需要 GC 一次。这时候我们再看看其停顿时间，如果停顿时间也很短的话，那我们就可以判定该应用的内存有优化的空间。 在这种情况下，一般都是缩小分配的新生代的空间。新生代空间一旦变小了，那么其分配完的时间就会缩减。一旦空间被分配完，那么就会启动进行 GC 操作。**我们就是通过调整 JVM 的内存空间，来提高 GC 的频率，从而使其处于一个合理的空间。** **在进行内存空间调整的时候，为了避免内存剧烈波动导致的问题，一般我们都是小步快跑地一点点调整。先调整一点试一试，没太大问题之后再调整到目标值**。接下来无非就是调整 JVM 内存空间的三个参数（-Xmx -Xms -Xmn），使 GC 频率与 GC 停顿时间处于合理的区间。 对于接口类型的系统来说，很多请求都是 1 秒中之内就结束。对于这种类型的请求，他们进入应用时会分配内存，结束时内存就会立刻被回收，留存下来的对象很少。这种应用的 JVM 内存情况大概是这样的：新生代消耗比较大，并且随着周期性回收内存，但老年代的内存消耗则更小。对于那些持续性处理的应用，例如持续时间长的应用处理。因为其存活时间较久，所以可能会有更多的对象晋升到老年代，因此老年代的内存消耗就比较大。如果应用某个地方每次都会存储大量的临时数据到内容中，这样就造成了 JVM 可能爆发 GC，从而导致应用卡顿。 ## Java 新特性概览 ### Java 8 新特性概览 #### Interface 接口 为了解决接口的修改与现有的实现不兼容的问题。新 interface 的方法可以用`default` 或 `static`修饰，这样就可以有方法体，实现类也不必重写此方法。 * `default`修饰的方法，是普通实例方法，可以用`this`调用，可以被子类继承、重写。 * `static`修饰的方法，使用上和一般类静态方法一样。但它不能被子类继承，只能用`Interface`调用。 **在 Java 8 ，接口和抽象类有什么区别的？** | 特性 | 接口（Interface） | 抽象类（Abstract Class） | | -------- | ------------------------------------------------------------------------------------- | ------------------------------- | | **关键字** | `interface` | `abstract class` | | **方法实现** |

Java 8 之前 只能是抽象方法
Java 8 及以上 可包含默认方法和静态方法

| 可以有抽象方法和普通方法 | | **成员变量** | 所有成员变量默认为 `public static final`，且必须赋初值 | 可以有多种类型的成员变量 | | **实现方式** | 用 `implements` 关键字实现，可实现多个接口 | 用 `extends` 关键字继承，只能继承一个抽象类（或类） | | **设计意图** | 定义规范，不关心具体实现 | 提供部分实现和规范，适合有共同逻辑的子类 | | **使用场景** | 为不同类提供统一接口，如 `Comparable`、`Runnable` | 为子类提供通用行为和属性，如 `Animal` 抽象类 | | | | | #### functional interface 函数式接口 也称 SAM 接口，即 Single Abstract Method interfaces，有且只有一个抽象方法，但可以有多个非抽象方法的接口。 在 java 8 中专门有一个包放函数式接口`java.util.function`，该包下的所有接口都有 `@FunctionalInterface` 注解，提供函数式编程。 在其他包中也有函数式接口，其中一些没有`@FunctionalInterface` 注解，但是只要符合函数式接口的定义就是函数式接口，与是否有`@FunctionalInterface`注解无关，注解只是在编译时起到强制规范定义的作用。其在 Lambda 表达式中有广泛的应用。 #### Lambda 表达式 Lambda 表达式是一个匿名函数，java 8 允许把函数作为参数传递进方法中。Lambda 表达式是推动 Java 8 发布的最重要新特性。是继泛型(`Generics`)和注解(`Annotation`)以来最大的变化。使用 Lambda 表达式可以使代码变的更加简洁紧凑。让 java 也能支持简单的函数式编程。 **Lambda 语法格式** ```java (parameters) -> expression // 或 (parameters) -> { statements; } ``` * **参数列表**：可以有一个或多个参数，若只有一个参数，可以省略括号。 * **箭头符号**：`->` 是 Lambda 表达式的箭头符号，用于将参数与 Lambda 主体分开。 * **主体**：可以是单一表达式或一个代码块。如果是单一表达式，返回值会自动推断；如果是代码块，必须显式地使用 `return` 来返回结果。 **Lambda 作用** * **简化代码**：Lambda 表达式可以将匿名内部类或回调函数的代码大大简化。过去给方法传动态参数的唯一方法是使用内部类（**`Runnable` 接口**、**`Comparator` 接口**、**`Listener` 接口**）。这些匿名内部类只重写了接口的一个方法，也就是**函数式接口**。只要方法的参数是函数式接口都可以用 Lambda 表达式。 * **函数式编程**：支持函数式接口（一个只包含一个抽象方法的接口），Java 8 提供了多个内置的函数式接口，如 `Consumer`、`Supplier`、`Function` 和 `Predicate`。 **Lambda 使用场景** * **集合操作**：与 Java 8 的 Stream API 配合使用，对集合进行过滤、排序、映射等操作。 * **多线程编程**：将行为作为参数传递给线程池或定时器。 * **事件处理**：简化 GUI 编程中的事件监听器代码。 **Lambda 实战** ```java @FunctionalInterface public interface LambdaInterface { void f(); } public class LambdaClass { public static void forEg() { lambdaInterfaceDemo(()-> System.out.println("自定义函数式接口")); } //函数式接口参数 static void lambdaInterfaceDemo(LambdaInterface i){ i.f(); } } ``` **Lambda 注意事项** Java 8 允许使用 `::` 关键字来传递方法或者构造函数引用，无论如何，表达式返回的类型必须是 functional-interface。 ```java strings.forEach((s) -> System.out.println(s)); strings.forEach(System.out::println); ``` lambda 表达式可以引用外部变量，但是该变量默认拥有 final 属性，不能被修改。 ```java Collections.sort(strings, (Integer o1, Integer o2) -> o1 - i); ``` #### Stream 流 **Stream（流）** 是一种用于处理数据集合的高级迭代器，它提供了一种声明式、函数式的编程方式，使得对数据的操作更加简洁和高效。Stream API 是 Java 8 引入的一个重要特性，但它也存在于其他编程语言中（如 Python 的迭代器、C# 的 LINQ 等）。 `Stream` 不是一种数据结构，而是对数据源（如集合、数组等）进行操作的一种抽象（流）。它允许开发者以声明式的方式对数据进行处理（如筛选、排序、聚合），而无需显式地编写循环和条件语句。 * **数据源**：Stream 的数据来源可以是集合（如 `List`、`Set`）、数组、I/O 通道等。 * **操作**：Stream 提供了一系列操作（如过滤、映射、排序、聚合等），这些操作可以分为中间操作（Intermediate Operations）和终端操作（Terminal Operations）。 **Stream 操作** * **中间操作**：每次返回一个新的流，可以有多个，允许链式调用（筛选`filter`、映射`map|flatmap`、排序`sorted`、去重组合`skip|limit`）。 * **终端操作**：每个流只能进行一次终端操作，终端操作结束后流无法再次使用。终端操作会产生一个新的集合或值（遍历`foreach`、匹配`find|match`、规约`reduce`、聚合`max|min|count`、收集`collect`）。 **`map()` 和 `flatMap()` 有什么区别的？** `map` 和 `flatMap` 都将一个函数应用于集合中的每个元素，但不同的是`map`返回一个新的集合，`flatMap` 是将每个元素都映射为一个集合，最后再将这个集合展平。 在`Optional`里面，当使用`map()`时，如果映射函数返回的是一个普通值，它会将这个值包装在一个新的`Optional`中。而使用`flatMap`时，如果映射函数返回的是一个`Optional`，它会将这个返回的`Optional`展平，不再包装成嵌套的`Optional`。 **Stream 特性** * **声明式编程**：通过 Stream，开发者只需描述“要做什么”，而无需关心“如何实现”。 * **函数式编程风格**：Stream 支持函数式编程，允许使用 Lambda 表达式和方法引用。 * **惰性求值**：Stream 的中间操作是惰性求值的，只有在执行终端操作时，才会真正触发数据处理。 * **不可变性**：Stream 本身是不可变的，所有操作都会返回一个新的 Stream，而不会修改原始数据源。 * **短路操作**：某些终端操作（如 `findFirst`、`anyMatch`）可以在满足条件时提前终止流的处理。 **stream 实战** ```java // 过滤数据并提取信息 List employees = Arrays.asList( new Employee("Alice", 5000), new Employee("Bob", 6000), new Employee("Charlie", 4500) ); // 过滤工资高于5000的员工，并提取名字 List highSalaryNames = employees.stream() .filter(e -> e.getSalary() > 5000) .map(Employee::getName) .collect(Collectors.toList()); System.out.println(highSalaryNames); // 输出: [Bob] // 对数据进行排序和收集 List names = Arrays.asList("Charlie", "Alice", "Bob"); // 按字母顺序排序并收集 List sortedNames = names.stream() .sorted() .collect(Collectors.toList()); System.out.println(sortedNames); // 输出: [Alice, Bob, Charlie] // 并发处理 List numbers = new ArrayList<>(); // 假设有大量元素 // 并行流处理 numbers.parallelStream() .map(n -> n * 2) .forEach(System.out::println); ``` **Stream 优势** * **代码更简洁**：通过 Stream，可以将复杂的循环和条件逻辑简化为一行代码。 * **可读性高**：Stream 的声明式风格使得代码更易于理解和维护。 * **性能优化**：Stream 的惰性求值和短路操作可以提高性能。 * **并行处理**：Stream 支持并行操作（`parallelStream()`），可以充分利用多核 CPU。 **Stream 局限性** * **不适用于所有场景**：对于需要显式控制循环和索引的场景，Stream 可能不够灵活。 * **性能开销**：对于小规模数据，Stream 的性能可能不如传统的循环。 * **不可变性**：Stream 本身是不可变的，无法直接修改原始数据源。 #### Optional **`Optional`** 是 Java 8 引入的一个容器类，用于表示可能存在也可能不存在的值。它的主要目的是解决 `null` 引发的问题（NPE `java.lang.NullPointerException`），避免空指针异常（`NullPointerException`），并提供一种更优雅的方式来处理可能为空的值。 **Optional 特性** * **避免 `null`**：`Optional` 是一个容器类，它可以包含一个值，或者不包含值（即“空”）。 * **不可变性**：`Optional` 是不可变的，一旦创建，它的值无法被修改。 * **函数式编程支持**：`Optional` 提供了许多方法，支持函数式编程风格的操作，如 `map`、`filter` 和 `orElse`。 **Optional 用法** **创建 `Optional` 对象** `ofNullable` 方法和`of`方法唯一区别就是当 value 为 null 时，`ofNullable` 返回的是`EMPTY`，of 会抛出 `NullPointerException` 异常。如果需要把 `NullPointerException` 暴漏出来就用 `of`，否则就用 `ofNullable`。 ```java Optional optional = Optional.of("Hello"); Optional optional = Optional.ofNullable(null); Optional emptyOptional = Optional.empty(); ``` **判断 value 是否为 null** ```java /** * value是否为null */ public boolean isPresent() { return value != null; } /** * 如果value不为null执行consumer.accept */ public void ifPresent(Consumer consumer) { if (value != null) consumer.accept(value); } ``` **获取 value** ```java /** * Return the value if present, otherwise invoke {@code other} and return * the result of that invocation. * 如果value != null 返回value，否则返回other的执行结果 */ public T orElseGet(Supplier other) { return value != null ? value : other.get(); } /** * 如果value != null 返回value，否则返回T */ public T orElse(T other) { return value != null ? value : other; } /** * 如果value != null 返回value，否则抛出参数返回的异常 */ public T orElseThrow(Supplier exceptionSupplier) throws X { if (value != null) { return value; } else { throw exceptionSupplier.get(); } } /** * value为null抛出NoSuchElementException，不为空返回value。 */ public T get() { if (value == null) { throw new NoSuchElementException("No value present"); } return value; } ``` **过滤值** ```java /** * 1. 如果是empty返回empty * 2. predicate.test(value)==true 返回this，否则返回empty */ public Optional filter(Predicate predicate) { Objects.requireNonNull(predicate); if (!isPresent()) return this; else return predicate.test(value) ? this : empty(); } ``` **Optional 实战** ```java Optional.ofNullable(zoo) .map(o -> o.getDog()) .map(d -> d.getAge()) .filter(v -> v == 1) .orElse(3); ``` #### Date-Time API **Java 8 Date-Time API** 是 Java 8 引入的重大改进之一，旨在解决旧版日期时间 API（如 `java.util.Date` 和 `java.util.Calendar`）存在的许多问题。 **Date-Time API 优势** * **可读性**：清晰易懂，易于开发和维护。 * **不可变性**：线程安全，避免了并发问题。 * **易用性**：提供了丰富的方法，简化了开发流程。 * **国际化支持**：更好地支持不同时区和语言环境。 **Date-Time API 的主要核心类** Java 8 提供了多个核心类，涵盖了日期、时间、时区和周期等方面： * **`LocalDate`**：表示不带时间的日期（如 `2024-10-01`）。 * **`LocalTime`**：表示不带日期的时间（如 `14:30:45`）。 * **`LocalDateTime`**：表示不带时区的日期和时间（如 `2024-10-01T14:30:45`）。 **Java 8 之前**字符串日期格式转换都需要借助 `SimpleDateFormat` 类，而**Java 8 之后**只需要 `LocalDate`、`LocalTime`、`LocalDateTime`的 `of` 或 `parse` 方法。 ### Java 17 新特性概览 #### JEP 356:增强的伪随机数生成器 Java 17 为伪随机数生成器 （pseudorandom number generator，PRNG，又称为确定性随机位生成器）增加了新的接口类型和实现，使得开发者更容易在应用程序中互换使用各种 PRNG 算法。 #### JEP 410:删除实验性的 AOT 和 JIT 编译器 ### Java 21 新特性概览 #### JEP 430：字符串模板（预览） String Templates 提供了一种更简洁、更直观的方式来动态构建字符串。通过使用占位符`${}`，我们可以将变量的值直接嵌入到字符串中，而不需要手动处理。在运行时，Java 编译器会将这些占位符替换为实际的变量值。并且，表达式支持局部变量、静态/非静态字段甚至方法、计算结果等特性。 #### JEP 431：序列化集合 JDK 21 引入了一种新的集合类型：**Sequenced Collections（序列化集合，也叫有序集合）**，这是一种具有确定出现顺序（encounter order）的集合（无论我们遍历这样的集合多少次，元素的出现顺序始终是固定的）。序列化集合提供了处理集合的第一个和最后一个元素以及反向视图（与原始集合相反的顺序）的简单方法。 #### JEP 439：分代 ZGC JDK21 中对 ZGC 进行了功能扩展，增加了分代 GC 功能。不过，默认是关闭的，需要通过配置打开。 #### JEP 441：switch 的模式匹配 增强 Java 中的 switch 表达式和语句，允许在 case 标签中使用模式。当模式匹配时，执行 case 标签对应的代码。 ```java static String formatterPatternSwitch(Object obj) { return switch (obj) { case Integer i -> String.format("int %d", i); case Long l -> String.format("long %d", l); case Double d -> String.format("double %f", d); case String s -> String.format("String %s", s); default -> obj.toString(); }; } ``` #### JEP 444：虚拟线程 虚拟线程是 Java 21 中引入的一种轻量级线程，旨在解决传统线程（也称为平台线程）的资源消耗问题。虚拟线程是 Java 并发模型的重大改进，特别适合高并发场景或者 I/O 密集型c场景。 **背景** * **传统线程的局限性**： * 每个传统线程（平台线程）都会占用操作系统资源，包括栈空间（通常为 1MB）。 * 创建和销毁线程的开销较大。 * 在高并发场景下（如 Web 服务器处理大量请求），线程数量过多会导致性能下降（上下文切换开销增加）。 * **虚拟线程的优势**： * 虚拟线程是轻量级的，创建和销毁的开销很小。 * 虚拟线程的栈空间是动态分配的，只有在需要时才会分配内存。 * 虚拟线程可以支持数万甚至数十万个并发线程，而不会显著增加资源消耗。 **虚拟线程的工作原理** * **线程分层模型**： * **平台线程（Platform Threads）**：直接映射到操作系统的线程，负责实际的 CPU 执行。 * **虚拟线程（Virtual Threads）**：运行在平台线程之上，由 JVM 管理和调度。 * 虚拟线程的执行由平台线程驱动，一个平台线程可以同时管理多个虚拟线程。 * **执行模型**： * 虚拟线程的执行是**协作式多任务**，即虚拟线程在执行过程中会主动让出控制权（例如，遇到 I/O 阻塞或显式调用 `yield()`）。 * JVM 通过一个调度器（Scheduler）将虚拟线程分配到可用的平台线程上执行。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-03701373b8aec071ac36b855de0bff81cf485716%2FPasted%20image%2020250213200121.png?alt=media) **使用方法** 官方为了降低虚拟线程的门槛，尽力复用原有的 `Thread` 线程类，这样可以平滑的过渡到虚拟线程的使用。 ```java // 1、通过 Thread.ofVirtual() 创建 Runnable fn = () -> { // your code here }; Thread thread = Thread.ofVirtual(fn) .start(); // 2、通过 Thread.startVirtualThread() 、创建 Thread thread = Thread.startVirtualThread(() -> { // your code here }); // 3、通过 Executors.newVirtualThreadPerTaskExecutor() 创建 var executorService = Executors.newVirtualThreadPerTaskExecutor(); executorService.submit(() -> { // your code here }); class CustomThread implements Runnable { @Override public void run() { System.out.println("CustomThread run"); } } //4、通过 ThreadFactory 创建 CustomThread customThread = new CustomThread(); // 获取线程工厂类 ThreadFactory factory = Thread.ofVirtual().factory(); // 创建虚拟线程 Thread thread = factory.newThread(customThread); // 启动线程 thread.start(); ``` ## Java 并发编程 ### 线程 #### 什么是线程和进程? 进程是程序的一次执行过程，是系统运行程序的基本单位，因此进程是动态的。系统运行一个程序即是一个进程从创建，运行到消亡的过程。 在 Java 中，当我们启动 main 函数时其实就是启动了一个 JVM 的进程，而 main 函数所在的线程就是这个进程中的一个线程，也称主线程。 线程与进程相似，但线程是一个比进程更小的执行单位。一个进程在其执行的过程中可以产生多个线程。与进程不同的是同类的多个线程共享进程的**堆**和**方法区**资源，但每个线程有自己的**程序计数器**、**虚拟机栈**和**本地方法栈**，所以系统在产生一个线程，或是在各个线程之间做切换工作时，负担要比进程小得多，也正因为如此，线程也被称为轻量级进程。 #### Java 线程和操作系统的线程有什么区别？ 在 JDK 1.2 及以后，Java 线程改为基于原生线程（Native Threads）实现，也就是说 JVM 直接使用操作系统原生的内核级线程（内核线程）来实现 Java 线程，由操作系统内核进行线程的调度和管理。 * 用户线程：由用户空间程序管理和调度的线程，运行在用户空间（专门给应用程序使用）。 * 内核线程：由操作系统内核管理和调度的线程，运行在内核空间（只有内核程序可以访问）。 用户线程创建和切换成本低，但不可以利用多核。内核态线程，创建和切换成本高，可以利用多核。 **Java 线程模型** 线程模型是用户线程和内核线程之间的关联方式，常见的线程模型有三种： * 一对一（一个用户线程对应一个内核线程） * 多对一（多个用户线程映射到一个内核线程） * 多对多（多个用户线程映射到多个内核线程） 在 Windows 和 Linux 等主流操作系统中，Java 线程采用的是一对一的线程模型，也就是一个 Java 线程对应一个系统内核线程。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-e81e3aae7a18559cbaad39ee38961735e55442f5%2FPasted%20image%2020250214121456.png?alt=media) #### 请简要描述线程与进程的关系，区别及优缺点？ 线程是进程划分成的更小的运行单位。线程和进程最大的不同在于基本上各进程是独立的，而各线程则不一定，因为同一进程中的线程极有可能会相互影响。线程执行开销小，但不利于资源的管理和保护；而进程正相反。 **程序计数器为什么是私有的?** 程序计数器主要有下面两个作用： * 字节码解释器通过改变程序计数器来依次读取指令，从而实现代码的流程控制，如：顺序执行、选择、循环、异常处理。 * 在多线程的情况下，程序计数器用于记录当前线程执行的位置，从而当线程被切换回来的时候能够知道该线程上次运行到哪儿了。 需要注意的是，如果执行的是 native 方法，那么程序计数器记录的是 undefined 地址，只有执行的是 Java 代码时程序计数器记录的才是下一条指令的地址。 所以，程序计数器私有主要是为了**线程切换后能恢复到正确的执行位置**。 **虚拟机栈和本地方法栈为什么是私有的?** * **虚拟机栈：** 每个 Java 方法在执行之前会创建一个栈帧用于存储局部变量表、操作数栈、常量池引用等信息。从方法调用直至执行完成的过程，就对应着一个栈帧在 Java 虚拟机栈中入栈和出栈的过程。 * **本地方法栈：** 和虚拟机栈所发挥的作用非常相似，区别是：**虚拟机栈为虚拟机执行 Java 方法 （也就是字节码）服务，而本地方法栈则为虚拟机使用到的 Native 方法服务。** 在 HotSpot 虚拟机中和 Java 虚拟机栈合二为一。 所以，为了**保证线程中的局部变量不被别的线程访问到**，虚拟机栈和本地方法栈是线程私有的。 #### 如何创建线程？ 一般来说，创建线程有很多种方式，例如继承`Thread`类、实现`Runnable`接口、实现`Callable`接口、使用线程池、使用`CompletableFuture`类等等。不过，这些方式其实并没有真正创建出线程。准确点来说，这些都属于是在 Java 代码中使用多线程的方法。 严格来说，Java 就只有一种方式可以创建线程，那就是通过`new Thread().start()`创建。不管是哪种方式，最终还是依赖于`new Thread().start()`。 #### 说说线程的生命周期和状态? Java 线程在运行的生命周期中的指定时刻只可能处于下面 6 种不同状态的其中一个状态： * NEW: 初始状态，线程被创建出来但没有被调用 `start()` 。 * RUNNABLE: 运行状态，线程被调用了 `start()`等待运行的状态。 * BLOCKED：阻塞状态，需要等待锁释放。 * WAITING：等待状态，表示该线程需要等待其他线程做出一些特定动作（通知或中断）。 * TIME\_WAITING：超时等待状态，可以在指定的时间后自行返回而不是像 WAITING 那样一直等待。 线程创建之后它将处于 **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（终止）** 状态。 **为什么 JVM 没有区分 READY 和 RUNNING 状态呢？** 现在的时分（time-sharing）多任务（multi-task）操作系统架构通常都是用所谓的“时间分片（time quantum or time slice）”方式进行抢占式（preemptive）轮转调度（round-robin 式）。这个时间分片通常是很小的，一个线程一次最多只能在 CPU 上运行比如 10-20ms 的时间（此时处于 running 状态），也即大概只有 0.01 秒这一量级，时间片用后就要被切换下来放入调度队列的末尾等待再次调度。（也即回到 ready 状态）。线程切换的如此之快，区分这两种状态就没什么意义了。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-658ead4b6f3d7fd33504ee82ced2c6f8fd2d99de%2FPasted%20image%2020250214121734.png?alt=media) #### 什么是线程上下文切换? 线程在执行过程中会有自己的运行条件和状态（也称上下文），比如上文所说到过的程序计数器，栈信息等。当出现如下情况的时候，线程会从占用 CPU 状态中退出。 * 主动让出 CPU，比如调用了 `sleep()`，`wait()` 等。 * 时间片用完，因为操作系统要防止一个线程或者进程长时间占用 CPU 导致其他线程或者进程饿死。 * 调用了阻塞类型的系统中断，比如请求 IO，线程被阻塞。 * 被终止或结束运行 这其中前三种都会发生线程切换，线程切换意味着需要保存当前线程的上下文，留待线程下次占用 CPU 的时候恢复现场。并加载下一个将要占用 CPU 的线程上下文。这就是所谓的 **上下文切换**。 上下文切换是现代操作系统的基本功能，因其每次需要保存信息恢复信息，这将会占用 CPU，内存等系统资源进行处理，也就意味着效率会有一定损耗，如果频繁切换就会造成整体效率低下。 #### Thread.sleep() 方法和 Object.wait() 方法对比 **共同点**：两者都可以暂停线程的执行。 **区别**： * **`sleep()` 方法没有释放锁，而 `wait()` 方法释放了锁** 。 * `wait()` 通常被用于线程间交互/通信，`sleep()`通常被用于暂停执行。 * `wait()` 方法被调用后，线程不会自动苏醒，需要别的线程调用同一个对象上的 `notify()` 或者 `notifyAll()` 方法。`sleep()` 方法执行完成后，线程会自动苏醒，或者也可以使用 `wait(long timeout)` 超时后线程会自动苏醒。 * `sleep()` 是 `Thread` 类的静态本地方法，`wait()` 则是 `Object` 类的本地方法。 #### 为什么 wait() 方法不定义在 Thread 中？ `wait()` 是让获得对象锁的线程实现等待，会自动释放当前线程占有的对象锁。每个对象（`Object`）都拥有对象锁，既然要释放当前线程占有的对象锁并让其进入 WAITING 状态，自然是要操作对应的对象（`Object`）而非当前的线程（`Thread`）。 #### 可以直接调用 Thread 类的 run 方法吗？ new 一个 `Thread`，线程进入了新建状态。调用 `start()`方法，会启动一个线程并使线程进入了就绪状态，当分配到时间片后就可以开始运行了。 `start()` 会执行线程的相应准备工作，然后自动执行 `run()` 方法的内容，这是真正的多线程工作。 但是，直接执行 `run()` 方法，会把 `run()` 方法当成一个 main 线程下的普通方法去执行，并不会在某个线程中执行它，所以这并不是多线程工作。 ### 多线程 #### 并发与并行的区别 * **并发**：两个及两个以上的作业在同一 **时间段** 内执行。 * **并行**：两个及两个以上的作业在同一 **时刻** 执行。 #### 同步和异步的区别 * **同步**：发出一个调用之后，在没有得到结果之前， 该调用就不可以返回，一直等待。 * **异步**：调用在发出之后，不用等待返回结果，该调用直接返回。 #### 为什么要使用多线程? 从总体上来说： * **从计算机底层来说：** 线程可以比作是轻量级的进程，是程序执行的最小单位，线程间的切换和调度的成本远远小于进程。另外，多核 CPU 时代意味着多个线程可以同时运行，这减少了线程上下文切换的开销。 * **从当代互联网发展趋势来说：** 现在的系统动不动就要求百万级甚至千万级的并发量，而多线程并发编程正是开发高并发系统的基础，利用好多线程机制可以大大提高系统整体的并发能力以及性能。 再深入到计算机底层： * **单核时代**：在单核时代多线程主要是为了提高单进程利用 CPU 和 IO 系统的效率。 假设只运行了一个 Java 进程的情况，当我们请求 IO 的时候，如果 Java 进程中只有一个线程，此线程被 IO 阻塞则整个进程被阻塞。CPU 和 IO 设备只有一个在运行，那么可以简单地说系统整体效率只有 50%。当使用多线程的时候，一个线程被 IO 阻塞，其他线程还可以继续使用 CPU。从而提高了 Java 进程利用系统资源的整体效率。 * **多核时代**: 多核时代多线程主要是为了提高进程利用多核 CPU 的能力。假如我们要计算一个复杂的任务，我们只用一个线程的话，不论系统有几个 CPU 核心，都只会有一个 CPU 核心被利用到。而创建多个线程，这些线程可以被映射到底层多个 CPU 核心上执行，在任务中的多个线程没有资源竞争的情况下，任务执行的效率会有显著性的提高，约等于（单核时执行时间/CPU 核心数）。 #### 单核 CPU 支持 Java 多线程吗？ 单核 CPU 是支持 Java 多线程的。操作系统通过时间片轮转的方式，将 CPU 的时间分配给不同的线程。尽管单核 CPU 一次只能执行一个任务，但通过快速在多个线程之间切换，可以让用户感觉多个任务是同时进行的。 操作系统主要通过两种线程调度方式来管理多线程的执行： * **抢占式调度（Preemptive Scheduling）**：操作系统决定何时暂停当前正在运行的线程，并切换到另一个线程执行。这种切换通常是由系统时钟中断（时间片轮转）或其他高优先级事件（如 I/O 操作完成）触发的。这种方式存在上下文切换开销，但公平性和 CPU 资源利用率较好，不易阻塞。 * **协同式调度（Cooperative Scheduling）**：线程执行完毕后，主动通知系统切换到另一个线程。这种方式可以减少上下文切换带来的性能开销，但公平性较差，容易阻塞。 Java 使用的线程调度是抢占式的。也就是说，JVM 本身不负责线程的调度，而是将线程的调度委托给操作系统。操作系统通常会基于线程优先级和时间片来调度线程的执行，高优先级的线程通常获得 CPU 时间片的机会更多。 #### 单核 CPU 上运行多个线程效率一定会高吗？ 单核 CPU 同时运行多个线程的效率是否会高，取决于线程的类型和任务的性质。一般来说，有两种类型的线程： * **CPU 密集型**：CPU 密集型的线程主要进行计算和逻辑处理，需要占用大量的 CPU 资源。 * **IO 密集型**：IO 密集型的线程主要进行输入输出操作，如读写文件、网络通信等，需要等待 IO 设备的响应，而不占用太多的 CPU 资源。 在单核 CPU 上，同一时刻只能有一个线程在运行，其他线程需要等待 CPU 的时间片分配。如果线程是 CPU 密集型的，那么多个线程同时运行会导致频繁的线程切换，增加了系统的开销，降低了效率。如果线程是 IO 密集型的，那么多个线程同时运行可以利用 CPU 在等待 IO 时的空闲时间，提高了效率。 因此，对于单核 CPU 来说，如果任务是 CPU 密集型的，那么开很多线程会影响效率；如果任务是 IO 密集型的，那么开很多线程会提高效率。当然，这里的“很多”也要适度，不能超过系统能够承受的上限。 #### 使用多线程可能带来什么问题？ 并发编程的目的就是为了能提高程序的执行效率进而提高程序的运行速度，但是并发编程并不总是能提高程序运行速度的，而且并发编程可能会遇到很多问题，比如：内存泄漏、死锁、线程不安全等等。 #### 如何理解线程安全和不安全？ 线程安全和不安全是在多线程环境下对于同一份数据的访问是否能够保证其正确性和一致性的描述。 * 线程安全指的是在多线程环境下，对于同一份数据，不管有多少个线程同时访问，都能保证这份数据的正确性和一致性。 * 线程不安全则表示在多线程环境下，对于同一份数据，多个线程同时访问时可能会导致数据混乱、错误或者丢失。 ### 死锁 #### 什么是线程死锁? 线程死锁描述的是这样一种情况：多个线程同时被阻塞，它们中的一个或者全部都在等待某个资源被释放。由于线程被无限期地阻塞，因此程序不可能正常终止。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-a17e2cec256b17c81a97b40580e51b53a823a1c2%2FPasted%20image%2020250214143015.png?alt=media) 线程 A 通过 `synchronized (resource1)` 获得 `resource1` 的监视器锁，然后通过`Thread.sleep(1000);`让线程 A 休眠 1s 为的是让线程 B 得到执行然后获取到 resource2 的监视器锁。线程 A 和线程 B 休眠结束了都开始企图请求获取对方的资源，然后这两个线程就会陷入互相等待的状态，这也就产生了死锁。 ```java public class DeadLockDemo { private static Object resource1 = new Object();//资源 1 private static Object resource2 = new Object();//资源 2 public static void main(String[] args) { new Thread(() -> { synchronized (resource1) { System.out.println(Thread.currentThread() + "get resource1"); try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println(Thread.currentThread() + "waiting get resource2"); synchronized (resource2) { System.out.println(Thread.currentThread() + "get resource2"); } } }, "线程 1").start(); new Thread(() -> { synchronized (resource2) { System.out.println(Thread.currentThread() + "get resource2"); try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println(Thread.currentThread() + "waiting get resource1"); synchronized (resource1) { System.out.println(Thread.currentThread() + "get resource1"); } } }, "线程 2").start(); } } ``` #### 产生死锁的四个必要条件 **互斥** 该资源任意一个时刻只由一个线程占用。 **请求与保持** 一个线程因请求资源而阻塞时，对已获得的资源保持不放。 **不可剥夺** 线程已获得的资源在未使用完之前不能被其他线程强行剥夺，只有自己使用完毕后才释放资源。 **循环等待** 若干线程之间形成一种头尾相接的循环等待资源关系。 #### 如何检测死锁？ * 使用`jmap`、`jstack`等命令查看 JVM 线程栈和堆内存的情况。如果有死锁，`jstack` 的输出中通常会有 `Found one Java-level deadlock:`的字样，后面会跟着死锁相关的线程信息。另外，实际项目中还可以搭配使用`top`、`df`、`free`等命令查看操作系统的基本情况，出现死锁可能会导致 CPU、内存等资源消耗过高。 * 采用 VisualVM、JConsole 等工具进行排查。 #### 如何预防死锁? 破坏死锁的产生的必要条件即可： * **破坏请求与保持条件**：一次性申请所有的资源。 * **破坏不可剥夺条件**：占用部分资源的线程进一步申请其他资源时，如果申请不到，可以主动释放它占有的资源。 * **破坏循环等待条件**：靠按序申请资源来预防。按某一顺序申请资源，释放资源则反序释放。破坏循环等待条件。 #### 如何避免死锁? 避免死锁就是在资源分配时，借助于算法（比如银行家算法）对资源分配进行计算评估，使其进入安全状态。 **安全状态** 指的是系统能够按照某种线程推进顺序（P1、P2、P3……Pn）来为每个线程分配所需资源，直到满足每个线程对资源的最大需求，使每个线程都可顺利完成。称 `` 序列为安全序列。 ### volatile 关键字 #### 如何保证变量的可见性？ 在 Java 中，`volatile` 关键字可以保证变量的可见性，如果我们将变量声明为 **`volatile`** ，这就指示 JVM，这个变量是共享且不稳定的，每次使用它都到主存中进行读取。 `volatile` 关键字其实并非是 Java 语言特有的，在 C 语言里也有，它最原始的意义就是禁用 CPU 缓存。如果我们将一个变量使用 `volatile` 修饰，这就**指示编译器，这个变量是共享且不稳定的，每次使用它都到主存中进行读取**。 **volatile 关键字与 synchronized 关键字的区别？** `volatile` 关键字能保证数据的可见性，但不能保证数据的原子性。`synchronized` 关键字两者都能保证。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-5b85d60c75ebdd926ce005db02093a16fc48f276%2FPasted%20image%2020250214150034.png?alt=media) #### 如何禁止指令重排序？ **在 Java 中，`volatile` 关键字除了可以保证变量的可见性，还有一个重要的作用就是防止 JVM 的指令重排序。** 如果我们将变量声明为 **`volatile`** ，在对这个变量进行读写操作的时候，会通过插入特定的 **内存屏障** 的方式来禁止指令重排序。 **双重校验锁实现对象单例（线程安全）**： ```java public class Singleton { private volatile static Singleton uniqueInstance; private Singleton() { } public static Singleton getUniqueInstance() { //先判断对象是否已经实例过，没有实例化过才进入加锁代码 if (uniqueInstance == null) { //类对象加锁 synchronized (Singleton.class) { if (uniqueInstance == null) { uniqueInstance = new Singleton(); } } } return uniqueInstance; } } ``` `uniqueInstance` 采用 `volatile` 关键字修饰也是很有必要的， `uniqueInstance = new Singleton();` 这段代码其实是分为三步执行： * 为 `uniqueInstance` 分配内存空间 * 初始化 `uniqueInstance` * 将 `uniqueInstance` 指向分配的内存地址 但是由于 JVM 具有指令重排的特性，执行顺序有可能变成 1->3->2。指令重排在单线程环境下不会出现问题，但是在多线程环境下会导致一个线程获得还没有初始化的实例。 #### volatile 可以保证原子性么？ **`volatile` 关键字能保证变量的可见性，但不能保证对变量的操作是原子性的。** 很多人会误认为自增操作 `inc++` 是原子性的，实际上，`inc++` 其实是一个复合操作，包括三步： * 读取 inc 的值。 * 对 inc 加 1。 * 将 inc 的值写回内存。 `volatile` 是无法保证这三个操作是具有原子性的，有可能导致下面这种情况出现： * 线程 1 对 `inc` 进行读取操作之后，还未对其进行修改。线程 2 又读取了 `inc`的值并对其进行修改（+1），再将`inc` 的值写回内存。 * 线程 2 操作完毕后，线程 1 对 `inc`的值进行修改（+1），再将`inc` 的值写回内存。 这也就导致两个线程分别对 `inc` 进行了一次自增操作后，`inc` 实际上只增加了 1。如果想要保证代码运行正确只需要用 `synchronized`、`Lock`或者`AtomicInteger`。 ```java public class VolatileAtomicityDemo { public volatile static int inc = 0; public void increase() { inc++; } // 使用 synchronized 改进 public synchronized void increase() { inc++; } public static void main(String[] args) throws InterruptedException { ExecutorService threadPool = Executors.newFixedThreadPool(5); VolatileAtomicityDemo volatileAtomicityDemo = new VolatileAtomicityDemo(); for (int i = 0; i < 5; i++) { threadPool.execute(() -> { for (int j = 0; j < 500; j++) { volatileAtomicityDemo.increase(); } }); } // 等待1.5秒，保证上面程序执行完成 Thread.sleep(1500); System.out.println(inc); threadPool.shutdown(); } } ``` ### 乐观锁和悲观锁 #### 什么是悲观锁？ 悲观锁（Pessimistic Lock）总是假设最坏的情况，认为共享资源每次被访问的时候就会出现问题(比如共享数据被修改)，所以每次在获取资源操作的时候都会上锁，这样其他线程想拿到这个资源就会阻塞直到锁被上一个持有者释放。也就是说，**共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程**。 **悲观锁的实现** 像 Java 中 `synchronized` 和 `ReentrantLock` 等独占锁就是悲观锁思想的实现。 **悲观锁的缺点** 高并发的场景下，激烈的锁竞争会造成线程阻塞，大量阻塞线程会导致系统的上下文切换，增加系统的性能开销。并且，悲观锁还可能会存在死锁问题，影响代码的正常运行。 #### 什么是乐观锁？ 乐观锁（Optimistic Lock）总是假设最好的情况，认为共享资源每次被访问的时候不会出现问题，线程可以不停地执行，无需加锁也无需等待，只是在提交修改的时候去验证对应的资源（也就是数据）是否被其它线程修改了（使用版本号机制或 CAS 算法）。 **乐观锁的实现** 在 Java 中`java.util.concurrent.atomic`包下面的原子变量类（比如`AtomicInteger`、`LongAdder`）就是使用了乐观锁的一种实现方式 **CAS** 实现的。 **乐观锁的缺点** 高并发的场景下，乐观锁相比悲观锁来说，不存在锁竞争造成线程阻塞，也不会有死锁的问题，在性能上往往会更胜一筹。 但是，如果冲突频繁发生（写占比非常多的情况），会频繁失败和重试，这样同样会非常影响性能，导致 CPU 飙升。 #### 如何选择乐观锁和悲观锁？ 悲观锁通常多用于写比较多的情况（多写场景，竞争激烈），这样可以避免频繁失败和重试影响性能，悲观锁的开销是固定的。不过，如果乐观锁解决了频繁失败和重试这个问题的话（比如`LongAdder`），也是可以考虑使用乐观锁的，要视实际情况而定。 乐观锁通常多用于写比较少的情况（多读场景，竞争较少），这样可以避免频繁加锁影响性能。不过，乐观锁主要针对的对象是单个共享变量（参考`java.util.concurrent.atomic`包下面的原子变量类） #### 如何实现乐观锁？ 乐观锁一般会使用版本号机制或 CAS 算法实现，CAS 算法相对来说更多一些。 **版本号机制** 一般是在数据表中加上一个数据版本号 `version` 字段，表示数据被修改的次数。当数据被修改时，`version` 值会加一。 当线程 A 要更新数据值时，在读取数据的同时也会读取 `version` 值，在提交更新时，若刚才读取到的 version 值为当前数据库中的 `version` 值相等时才更新，否则重试更新操作，直到更新成功。 **CAS 算法** CAS 的全称是 **Compare And Swap（比较与交换）** ，用于实现乐观锁，被广泛应用于各大框架中。CAS 的思想很简单，就是用一个预期值和要更新的变量值进行比较，两值相等才会进行更新。 CAS 是一个原子操作，底层依赖于一条 CPU 的原子指令。**原子操作** 即最小不可拆分的操作，也就是说操作一旦开始，就不能被打断，直到操作完成。 CAS 涉及到三个操作数： * **V**：要更新的变量值(Var) * **E**：预期值(Expected) * **N**：拟写入的新值(New) 当且仅当 V 的值等于 E 时，CAS 通过原子方式用新值 N 来更新 V 的值。如果不等，说明已经有其它线程更新了 V，则当前线程放弃更新。 当多个线程同时使用 CAS 操作一个变量时，只有一个会胜出，并成功更新，其余均会失败，但失败的线程并不会被挂起，仅是被告知失败，并且允许再次尝试，当然也允许失败的线程放弃操作。 #### Java 中 CAS 是如何实现的？ 在 Java 中，实现 CAS（Compare-And-Swap, 比较并交换）操作的一个关键类是`Unsafe`。 `Unsafe`类位于`sun.misc`包下，是一个提供低级别、不安全操作的类。由于其强大的功能和潜在的危险性，它通常用于 JVM 内部或一些需要极高性能和底层访问的库中，而不推荐普通开发者在应用程序中使用。 `Unsafe`类中的 CAS 方法是`native`方法。`native`关键字表明这些方法是用本地代码（通常是 C 或 C++）实现的，而不是用 Java 实现的。这些方法直接调用底层的硬件指令来实现原子操作。也就是说，Java 语言并没有直接用 Java 实现 CAS，而是通过 C++ 内联汇编的形式实现的（通过 Java Native Interface 调用）。因此，CAS 的具体实现与操作系统以及 CPU 密切相关。 `java.util.concurrent.atomic` 包提供了一些用于原子操作的类。这些类利用底层的原子指令，确保在多线程环境下的操作是线程安全的。Atomic 类依赖于 CAS 乐观锁来保证其方法的原子性，而不需要使用传统的锁机制（如 `synchronized` 块或 `ReentrantLock`）。 `AtomicInteger`是 Java 的原子类之一，主要用于对 `int` 类型的变量进行原子操作，它利用`Unsafe`类提供的低级别原子操作方法实现无锁的线程安全性。 `Unsafe#getAndAddInt` 使用了 `do-while` 循环：在 `compareAndSwapInt` 操作失败时，会不断重试直到成功。也就是说，`getAndAddInt`方法会通过 `compareAndSwapInt` 方法来尝试更新 `value` 的值，如果更新失败（当前值在此期间被其他线程修改），它会重新获取当前值并再次尝试更新，直到操作成功。 **由于 CAS 操作可能会因为并发冲突而失败，因此通常会与 `while` 循环搭配使用，在失败后不断重试，直到操作成功。这就是自旋锁机制** 。 ```java // 原子地获取并增加整数值 public final int getAndAddInt(Object o, long offset, int delta) { int v; do { // 以 volatile 方式获取对象 o 在内存偏移量 offset 处的整数值 v = getIntVolatile(o, offset); } while (!compareAndSwapInt(o, offset, v, v + delta)); // 返回旧值 return v; } ``` #### CAS 算法存在哪些问题？ **ABA 问题** 如果一个变量 V 初次读取的时候是 A 值，并且在准备赋值的时候检查到它仍然是 A 值，那我们就能说明它的值没有被其他线程修改过了吗？很明显是不能的，因为在这段时间它的值可能被改为其他值，然后又改回 A，那 CAS 操作就会误认为它从来没有被修改过。这个问题被称为 CAS 操作的 **"ABA"问题。** ABA 问题的解决思路是在变量前面追加上**版本号或者时间戳**。JDK 1.5 以后的 `AtomicStampedReference` 类就是用来解决 ABA 问题的，其中的 `compareAndSet()` 方法就是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。 **循环时间长开销大** CAS 经常会用到自旋操作来进行重试，也就是不成功就一直循环执行直到成功。如果长时间不成功，会给 CPU 带来非常大的执行开销。 如果 JVM 能够支持处理器提供的`pause`指令，那么自旋操作的效率将有所提升。`pause`指令有两个重要作用： * **延迟流水线执行指令**：`pause`指令可以延迟指令的执行，从而减少 CPU 的资源消耗。具体的延迟时间取决于处理器的实现版本，在某些处理器上，延迟时间可能为零。 * **避免内存顺序冲突**：在退出循环时，`pause`指令可以避免由于内存顺序冲突而导致的 CPU 流水线被清空，从而提高 CPU 的执行效率。 **只能保证一个共享变量的原子操作** CAS 操作仅能对单个共享变量有效。当需要操作多个共享变量时，CAS 就显得无能为力。不过，从 JDK 1.5 开始，Java 提供了`AtomicReference`类，这使得我们能够保证引用对象之间的原子性。通过将多个变量封装在一个对象中，我们可以使用`AtomicReference`来执行 CAS 操作。 除了 `AtomicReference` 这种方式之外，还可以利用加锁来保证。 ### synchronized 关键字 #### synchronized 是什么？有什么用？ `synchronized` 是 Java 中的一个关键字，翻译成中文是同步的意思，主要解决的是多个线程之间访问资源的同步性，可以保证被它修饰的方法或者代码块在任意时刻只能有一个线程执行。 在 Java 6 之后， `synchronized` 引入了大量的优化如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销，这些优化让 `synchronized` 锁的效率提升了很多。因此， `synchronized` 还是可以在实际项目中使用的，像 JDK 源码、很多开源框架都大量使用了 `synchronized` 。 #### 如何使用 synchronized？ `synchronized` 关键字的使用方式主要有下面 3 种： * 修饰实例方法（锁当前对象实例）：给当前对象实例加锁，进入同步代码前要获得 **当前对象实例的锁** 。 * 修饰静态方法（锁当前类）：给当前类加锁，会作用于类的所有对象实例 ，进入同步代码前要获得 **当前 class 的锁**。 * 修饰代码块（锁指定对象/类）： * `synchronized(object)` 表示进入同步代码库前要获得 **给定对象的锁**。 * `synchronized(类.class)` 表示进入同步代码前要获得 **给定 Class 的锁**。 尽量不要使用 `synchronized(String a)` 因为 JVM 中，字符串常量池具有缓存功能。 #### 构造方法可以用 synchronized 修饰么？ 构造方法不能使用 synchronized 关键字修饰。不过，可以在构造方法内部使用 synchronized 代码块。 另外，构造方法本身是线程安全的，但如果在构造方法中涉及到共享资源的操作，就需要采取适当的同步措施来保证整个构造过程的线程安全。 #### synchronized 底层原理了解吗？ synchronized锁定的基本原理是通过对对象或类的监视器（Monitor）进行加锁和解锁操作来实现线程同步。当一个线程尝试进入synchronized代码块或方法时，它会首先尝试获取对象或类的锁。如果锁已经被其他线程持有，则该线程将被阻塞，直到锁被释放。synchronized锁的运作机制包括偏向锁、轻量级锁和重量级锁三种状态。偏向锁适用于单线程访问的情况，轻量级锁适用于多线程竞争不激烈的情况，而重量级锁则用于处理高竞争场景。通过这三种状态的转换，synchronized锁能够根据不同的并发场景动态调整锁策略，以实现高效的线程同步。 在 Java 虚拟机（HotSpot）中，Monitor 是基于 C++实现的，由 `ObjectMonitor` 实现的。每个对象中都内置了一个 `ObjectMonitor` 对象。另外，`wait/notify`等方法也依赖于`monitor`对象，这就是为什么只有在同步的块或者方法中才能调用`wait/notify`等方法，否则会抛出`java.lang.IllegalMonitorStateException`的异常的原因。 在执行`monitorenter`时，会尝试获取对象的锁，如果锁的计数器为 0 则表示锁可以被获取，获取后将锁计数器设为 1 也就是加 1。对象锁的的拥有者线程才可以执行 `monitorexit` 指令来释放锁。在执行 `monitorexit` 指令后，将锁计数器设为 0，表明锁被释放，其他线程可以尝试获取锁。如果获取对象锁失败，那当前线程就要阻塞等待，直到锁被另外一个线程释放为止。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-3e9f62ef7dc43f98f8ef581213d8d8fbdcd7dd42%2FPasted%20image%2020250214160030.png?alt=media) **锁升级** 锁升级的主要目的是为了提升并发性能，减少不必要的线程上下文切换和内存消耗。线程上下文切换是一个相对昂贵的操作，因为它涉及到保存当前线程的状态、恢复另一个线程的状态等一系列操作。通过优化锁策略，JVM可以减少这种切换的频率，从而提高系统的整体性能。 另外，锁升级也有助于减少内存消耗。相较于重量级锁需要创建额外的Monitor对象并在操作系统层面进行线程调度，偏向锁和轻量级锁在一定程度上降低了内存消耗，特别是对于大量短生命周期的锁请求场景。 当我们使用`synchronized`时，Java虚拟机（JVM）会为每个被同步的对象维护一个锁（或称为监视器锁）。这个锁有四种状态：从级别由低到高依次是：**无锁、偏向锁，轻量级锁，重量级锁**，用于控制多线程对共享资源的访问。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-e43501ea652bcf6c060aa78ddb40d72b1574c854%2F2d63c3d347544990b33dc7d340a6eba2~tplv-k3u1fbpfcp-jj-mark_3024_0_0_0_q75.webp?alt=media) **无锁** 无锁状态是对象初始化后的默认锁状态，表示对象当前未被任何线程锁定。在这种状态下，对象头的锁标志位通常为空或特定的无锁标识，表明对象不受任何同步控制，任何线程都能够无障碍地访问该对象。 无锁的标志位为**01**，即如果是否偏向锁标识为0时是无锁状态，为1时是偏向锁。在这个状态下，没有线程拥有锁，并且存储了对象的hashcode、对象的分代年龄以及是否为偏向锁的标志（0表示不是偏向锁）。 当一个线程首次尝试获取锁时，JVM会检查这个锁是否处于无锁状态。如果是，JVM会尝试将锁偏向给这个线程，也就是将锁标记为偏向这个线程，并且将这个线程的ID记录在锁的标记中。这样，当这个线程再次尝试获取锁时，就可以避免一些昂贵的操作，因为JVM可以直接检查锁是否仍然偏向这个线程。 **偏向锁** 当一个线程首次成功获取一个锁时，锁就进入了偏向锁状态。在偏向锁状态下，只有持有偏向锁的线程才能再次获取这个锁，而不会引起竞争。如果其他线程尝试获取这个锁，偏向锁就会升级为轻量级锁。 偏向锁主要是为了解决在一个线程连续多次获取同一锁的情况，降低不必要的同步操作开销。当首次获取锁的线程再次进入同步代码块时，会检查对象头中存储的线程ID是否与当前线程一致。如果一致，则直接获得锁；如果不一致，则需要撤销偏向锁，重新进行锁竞争，可能升级为轻量级锁。 **轻量级锁** 当一个线程尝试获取一个已经被其他线程持有的偏向锁时，偏向锁会升级为轻量级锁。轻量级锁是一种用于处理线程之间轻量级竞争的机制。当一个线程尝试获取轻量级锁时，它会先自旋一段时间，尝试等待锁被释放。如果在这段时间内锁被释放了，那么这个线程就可以成功获取锁。如果自旋结束后锁仍然被持有，那么这个线程就会尝试将锁升级为重量级锁。 轻量级锁利用CAS操作尝试将对象头的Mark Word替换为指向线程栈中锁记录的指针，如果CAS操作成功，则表示线程成功获取锁。获取锁失败的线程会进入自旋状态，不断循环尝试获取锁，直到获取成功或升级为重量级锁。在自旋期间，线程不会立即进入阻塞状态，而是不断循环检查锁是否可用。这种机制可以减少线程上下文切换的开销，但如果自旋次数过多或者竞争加剧，自旋就会失去意义，JVM会选择升级为重量级锁。 **重量级锁** 当轻量级锁的自旋尝试达到一定阈值，或者检测到多个线程竞争激烈时，JVM会将轻量级锁升级为重量级锁。升级过程中，会取消当前线程的自旋操作，并在对象头中设置重量级锁标志。 在重量级锁状态下，线程在获取锁失败时会被操作系统挂起，放入到该对象关联的监视器（Monitor）的等待队列中，由操作系统进行线程调度，当锁被释放时，操作系统会选择合适的线程将其唤醒并授予锁。 尽管重量级锁的开销较大，涉及到线程上下文切换和内核态用户态的切换等，但它在高竞争场景下能提供稳定的互斥性和公平性，确保数据的一致性和线程的安全执行。因此，即使性能损耗较高，也是在特定情况下必要的权衡措施。 #### synchronized 和 volatile 有什么区别？ `synchronized` 关键字和 `volatile` 关键字是两个互补的存在。 * `volatile` 关键字是线程同步的轻量级实现，所以 `volatile`性能肯定比`synchronized`关键字要好 。但是 `volatile` 关键字只能用于变量而 `synchronized` 关键字可以修饰方法以及代码块 。 * `volatile` 关键字能保证数据的可见性，但不能保证数据的原子性。`synchronized` 关键字两者都能保证。 * `volatile`关键字主要用于解决变量在多个线程之间的可见性，而 `synchronized` 关键字解决的是多个线程之间访问资源的同步性。 ### ReentrantLock #### ReentrantLock 是什么？ `ReentrantLock` 实现了 `Lock` 接口，是一个可重入且独占式的锁，和 `synchronized` 关键字类似。不过，`ReentrantLock` 更灵活、更强大，增加了轮询、超时、中断、公平锁和非公平锁等高级功能。 `ReentrantLock` 里面有一个内部类 `Sync`，`Sync` 继承 AQS（`AbstractQueuedSynchronizer`），添加锁和释放锁的大部分操作实际上都是在 `Sync` 中实现的。`Sync` 有公平锁 `FairSync` 和非公平锁 `NonfairSync` 两个子类。 #### 公平锁和非公平锁有什么区别？ * **公平锁** : 锁被释放之后，先申请的线程先得到锁。性能较差一些，因为公平锁为了保证时间上的绝对顺序，上下文切换更频繁。 * **非公平锁**：锁被释放之后，后申请的线程可能会先获取到锁，是随机或者按照其他优先级排序的。性能更好，但可能会导致某些线程永远无法获取到锁。 #### synchronized 和 ReentrantLock 有什么区别？ **两者都是可重入锁** **可重入锁** 也叫递归锁，指的是线程可以再次获取自己的内部锁。比如一个线程获得了某个对象的锁，此时这个对象锁还没有释放，当其再次想要获取这个对象的锁的时候还是可以获取的，如果是不可重入锁的话，就会造成死锁。JDK 提供的所有现成的 `Lock` 实现类，包括 `synchronized` 关键字锁都是可重入的。 **synchronized 依赖于 JVM 而 ReentrantLock 依赖于 API** * `synchronized` 是依赖于 JVM 实现的，并没有直接暴露给我们。 * `ReentrantLock` 是 JDK 层面实现的（也就是 API 层面，需要 lock() 和 unlock() 方法配合 try/finally 语句块来完成）。 **ReentrantLock 比 synchronized 增加了一些高级功能** **等待可中断** `ReentrantLock`提供了一种能够中断等待锁的线程的机制，通过 `lock.lockInterruptibly()` 来实现这个机制。也就是说当前线程在等待获取锁的过程中，如果其他线程中断当前线程「 `interrupt()` 」，当前线程就会抛出 `InterruptedException` 异常，可以捕捉该异常进行相应处理。 **可实现公平锁** `ReentrantLock`可以指定是公平锁还是非公平锁。而`synchronized`只能是非公平锁。所谓的公平锁就是先等待的线程先获得锁。`ReentrantLock`默认情况是非公平的，可以通过 `ReentrantLock`类的`ReentrantLock(boolean fair)`构造方法来指定是否是公平的。 **可实现选择性通知（锁可以绑定多个条件）** `synchronized`关键字与`wait()`和`notify()`/`notifyAll()`方法相结合可以实现等待/通知机制。`ReentrantLock`类当然也可以实现，但是需要借助于`Condition`接口与`newCondition()`方法。 **支持超时** `ReentrantLock` 提供了 `tryLock(timeout)` 的方法，可以指定等待获取锁的最长等待时间，如果超过了等待时间，就会获取锁失败，不会一直等待。 **可中断锁和不可中断锁有什么区别？** * **可中断锁**：获取锁的过程中可以被中断，不需要一直等到获取锁之后 才能进行其他逻辑处理。`ReentrantLock` 就属于是可中断锁。 * **不可中断锁**：一旦线程申请了锁，就只能等到拿到锁以后才能进行其他的逻辑处理。 `synchronized` 就属于是不可中断锁。 #### ReentrantReadWriteLock **ReentrantReadWriteLock 是什么？** `ReentrantReadWriteLock` 实现了 `ReadWriteLock` ，是一个可重入的读写锁，既可以保证多个线程同时读的效率，同时又可以保证有写入操作时的线程安全。 * 一般锁进行并发控制的规则：读读互斥、读写互斥、写写互斥。 * 读写锁进行并发控制的规则：读读不互斥、读写互斥、写写互斥（只有读读不互斥）。 `ReentrantReadWriteLock` 其实是两把锁，一把是 `WriteLock` (写锁)，一把是 `ReadLock`（读锁） 。读锁是共享锁，写锁是独占锁。读锁可以被同时读，可以同时被多个线程持有，而写锁最多只能同时被一个线程持有。 和 `ReentrantLock` 一样，`ReentrantReadWriteLock` 底层也是基于 AQS 实现的。 **ReentrantReadWriteLock 适合什么场景？** 由于 `ReentrantReadWriteLock` 既可以保证多个线程同时读的效率，同时又可以保证有写入操作时的线程安全。因此，在读多写少的情况下，使用 `ReentrantReadWriteLock` 能够明显提升系统性能。 **共享锁和独占锁有什么区别？** * **共享锁**：一把锁可以被多个线程同时获得。 * **独占锁**：一把锁只能被一个线程获得。 **线程持有读锁还能获取写锁吗？** * 在线程持有读锁的情况下，该线程不能取得写锁(因为获取写锁的时候，如果发现当前的读锁被占用，就马上获取失败，不管读锁是不是被当前线程持有)。 * 在线程持有写锁的情况下，该线程可以继续获取读锁（获取读锁时如果发现写锁被占用，只有写锁没有被当前线程占用的情况才会获取失败）。 **读锁为什么不能升级为写锁？** 写锁可以降级为读锁，但是读锁却不能升级为写锁。这是因为读锁升级为写锁会引起线程的争夺，毕竟写锁属于是独占锁，这样的话，会影响性能。另外，还可能会有死锁问题发生。 #### StampedLock **StampedLock 是什么？** `StampedLock` 是 JDK 1.8 引入的性能更好的读写锁，不可重入且不支持条件变量 `Condition`。 不同于一般的 `Lock` 类，`StampedLock` 并不是直接实现 `Lock`或 `ReadWriteLock`接口，而是基于 **CLH 锁** 独立实现的（AQS 也是基于这玩意）。 `StampedLock` 提供了三种模式的读写控制模式：读锁、写锁和乐观读。 * **写锁**：独占锁，一把锁只能被一个线程获得。当一个线程获取写锁后，其他请求读锁和写锁的线程必须等待。类似于 `ReentrantReadWriteLock` 的写锁，不过这里的写锁是不可重入的。 * **读锁** （悲观读）：共享锁，没有线程获取写锁的情况下，多个线程可以同时持有读锁。如果己经有线程持有写锁，则其他线程请求获取该读锁会被阻塞。类似于 `ReentrantReadWriteLock` 的读锁，不过这里的读锁是不可重入的。 * **乐观读**：允许多个线程获取乐观读以及读锁。同时允许一个写线程获取写锁。 **StampedLock 的性能为什么更好？** 相比于传统读写锁多出来的乐观读是`StampedLock`比 `ReadWriteLock` 性能更好的关键原因。`StampedLock` 的乐观读允许一个写线程获取写锁，所以不会导致所有写线程阻塞，也就是当读多写少的时候，写线程有机会获取写锁，减少了线程饥饿的问题，吞吐量大大提高。 **StampedLock 适合什么场景？** 和 `ReentrantReadWriteLock` 一样，`StampedLock` 同样适合读多写少的业务场景，可以作为 `ReentrantReadWriteLock`的替代品，性能更好。 不过，需要注意的是`StampedLock`不可重入，不支持条件变量 `Condition`，对中断操作支持也不友好（使用不当容易导致 CPU 飙升）。如果你需要用到 `ReentrantLock` 的一些高级性能，就不太建议使用 `StampedLock` 了。 **StampedLock 的底层原理了解吗？** `StampedLock` 不是直接实现 `Lock`或 `ReadWriteLock`接口，而是基于 **CLH 锁** 实现的（AQS 也是基于这玩意），CLH 锁是对自旋锁的一种改良，是一种隐式的链表队列。`StampedLock` 通过 CLH 队列进行线程的管理，通过同步状态值 `state` 来表示锁的状态和类型。 ### ThreadLocal #### ThreadLocal 有什么用？ 通常情况下，我们创建的变量可以被任何一个线程访问和修改。这在多线程环境中可能导致数据竞争和线程安全问题。那么，**如果想让每个线程都有自己的专属本地变量，该如何实现呢？** JDK 中提供的 `ThreadLocal` 类正是为了解决这个问题。**`ThreadLocal` 类允许每个线程绑定自己的值**，可以将其形象地比喻为一个“存放数据的盒子”。每个线程都有自己独立的盒子，用于存储私有数据，确保不同线程之间的数据互不干扰。 当你创建一个 `ThreadLocal` 变量时，每个访问该变量的线程都会拥有一个独立的副本。这也是 `ThreadLocal` 名称的由来。线程可以通过 `get()` 方法获取自己线程的本地副本，或通过 `set()` 方法修改该副本的值，从而避免了线程安全问题。 #### ThreadLocal 原理了解吗？ **最终的变量是放在了当前线程的 `ThreadLocalMap` 中，并不是存在 `ThreadLocal` 上，`ThreadLocal` 可以理解为只是`ThreadLocalMap`的封装，传递了变量值。** `ThrealLocal` 类中可以通过`Thread.currentThread()`获取到当前线程对象后，直接通过`getMap(Thread t)`可以访问到该线程的`ThreadLocalMap`对象。 **每个`Thread`中都具备一个`ThreadLocalMap`，而`ThreadLocalMap`可以存储以`ThreadLocal`为 key ，Object 对象为 value 的键值对。** ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-df4c99467b9ace85b58627e08f54df10bc226c81%2FPasted%20image%2020250221143508.png?alt=media) #### ThreadLocal 内存泄露问题是怎么导致的？ `ThreadLocal` 内存泄漏的根本原因在于其内部实现机制。 每个线程维护一个名为 `ThreadLocalMap` 的 map。 当你使用 `ThreadLocal` 存储值时，实际上是将值存储在当前线程的 `ThreadLocalMap` 中，其中 `ThreadLocal` 实例本身作为 key，而你要存储的值作为 value。 * **key 是弱引用**：`ThreadLocalMap` 中的 key 是 `ThreadLocal` 的弱引用 (`WeakReference>`)。 这意味着，如果 `ThreadLocal` 实例不再被任何强引用指向，垃圾回收器会在下次 GC 时回收该实例，导致 `ThreadLocalMap` 中对应的 key 变为 `null`。 * **value 是强引用**：`ThreadLocalMap` 中的 value 是强引用。 即使 key 被回收（变为 `null`），value 仍然存在于 `ThreadLocalMap` 中，被强引用，不会被回收。 当 `ThreadLocal` 实例失去强引用后，其对应的 value 仍然存在于 `ThreadLocalMap` 中，因为 `Entry` 对象强引用了它。如果线程持续存活（例如线程池中的线程），`ThreadLocalMap` 也会一直存在，导致 key 为 `null` 的 entry 无法被垃圾回收，机会造成内存泄漏。 也就是说，内存泄漏的发生需要同时满足两个条件： 1. `ThreadLocal` 实例不再被强引用； 2. 线程持续存活，导致 `ThreadLocalMap` 长期存在。 虽然 `ThreadLocalMap` 在 `get()`, `set()` 和 `remove()` 操作时会尝试清理 key 为 null 的 entry，但这种清理机制是被动的，并不完全可靠。 **如何避免内存泄漏的发生？** * 在使用完 `ThreadLocal` 后，务必调用 `remove()` 方法。 这是最安全和最推荐的做法。 `remove()` 方法会从 `ThreadLocalMap` 中显式地移除对应的 entry，彻底解决内存泄漏的风险。 即使将 `ThreadLocal` 定义为 `static final`，也强烈建议在每次使用后调用 `remove()`。 * 在线程池等线程复用的场景下，使用 `try-finally` 块可以确保即使发生异常，`remove()` 方法也一定会被执行。 #### 如何跨线程传递 ThreadLocal 的值？ 由于 `ThreadLocal` 的变量值存放在 `Thread` 里，而父子线程属于不同的 `Thread` 的。因此在异步场景下，父子线程的 `ThreadLocal` 值无法进行传递。 如果想要在异步场景下传递 `ThreadLocal` 值，有两种解决方案： * `InheritableThreadLocal` ：`InheritableThreadLocal` 是 JDK1.2 提供的工具，继承自 `ThreadLocal` 。使用 `InheritableThreadLocal` 时，会在创建子线程时，令子线程继承父线程中的 `ThreadLocal` 值，但是无法支持线程池场景下的 `ThreadLocal` 值传递。 * `TransmittableThreadLocal` ： `TransmittableThreadLocal` （简称 TTL） 是阿里巴巴开源的工具类，继承并加强了`InheritableThreadLocal`类，可以在线程池的场景下支持 `ThreadLocal` 值传递。 **应用场景** * **压测流量标记**： 在压测场景中，使用 `ThreadLocal` 存储压测标记，用于区分压测流量和真实流量。如果标记丢失，可能导致压测流量被错误地当成线上流量处理。 * **上下文传递**：在分布式系统中，传递链路追踪信息（如 Trace ID）或用户上下文信息。 ### 线程池 #### 什么是线程池? 线程池就是管理一系列线程的资源池。当有任务要处理时，直接从线程池中获取线程来处理，处理完之后线程并不会立即被销毁，而是等待下一个任务。 #### 为什么要用线程池？ 线程池、数据库连接池、HTTP 连接池等等都是对池化技术的应用。池化技术的思想主要是为了减少每次获取资源的消耗，提高对资源的利用率。 **线程池**提供了一种限制和管理资源（包括执行一个任务）的方式。 每个**线程池**还维护一些基本统计信息，例如已完成任务的数量。 * **降低资源消耗**。通过重复利用已创建的线程降低线程创建和销毁造成的消耗。 * **提高响应速度**。当任务到达时，任务可以不需要等到线程创建就能立即执行。 * **提高线程的可管理性**。线程是稀缺资源，如果无限制的创建，不仅会消耗系统资源，还会降低系统的稳定性，使用线程池可以进行统一的分配，调优和监控。 #### Executor 框架介绍 `Executor` 框架是 Java5 之后引进的，在 Java 5 之后，通过 `Executor` 来启动线程比使用 `Thread` 的 `start` 方法更好，除了更易管理，效率更好（用线程池实现，节约开销）外，还有关键的一点：有助于避免 this 逃逸问题。 this 逃逸是指在构造函数返回之前其他线程就持有该对象的引用，调用尚未构造完全的对象的方法可能引发令人疑惑的错误。 `Executor` 框架不仅包括了线程池的管理，还提供了线程工厂、队列以及拒绝策略等，`Executor` 框架让并发编程变得更加简单。 **Executor 框架结构** `Executor` 框架结构主要由三大部分组成： **任务(`Runnable` /`Callable`)** 执行任务需要实现的 **`Runnable` 接口** 或 **`Callable`接口**。**`Runnable` 接口**或 **`Callable` 接口** 实现类都可以被 **`ThreadPoolExecutor`** 或 **`ScheduledThreadPoolExecutor`** 执行。 **任务的执行(`Executor`)** 包括任务执行机制的核心接口 **`Executor`** ，以及继承自 `Executor` 接口的 **`ExecutorService` 接口。`ThreadPoolExecutor`** 和 **`ScheduledThreadPoolExecutor`** 这两个关键类实现了 **`ExecutorService`** 接口。 **异步计算的结果(`Future`)** **`Future`** 接口以及 `Future` 接口的实现类 **`FutureTask`** 类都可以代表异步计算的结果。 当我们把 **`Runnable`接口** 或 **`Callable` 接口** 的实现类提交给 **`ThreadPoolExecutor`** 或 **`ScheduledThreadPoolExecutor`** 执行。（调用 `submit()` 方法时会返回一个 **`FutureTask`** 对象） **`Executor` 框架的使用** * 主线程首先要创建实现 `Runnable` 或者 `Callable` 接口的任务对象。 * 把创建完成的实现 `Runnable`/`Callable`接口的 对象直接交给 `ExecutorService` 执行: `ExecutorService.execute（Runnable command）`）或者也可以把 `Runnable` 对象或`Callable` 对象提交给 `ExecutorService` 执行（`ExecutorService.submit（Runnable task）`或 `ExecutorService.submit（Callable task）`）。 * 如果执行 `ExecutorService.submit（…）`，`ExecutorService` 将返回一个实现`Future`接口的对象（我们刚刚也提到过了执行 `execute()`方法和 `submit()`方法的区别，`submit()`会返回一个 `FutureTask` 对象）。由于 `FutureTask` 实现了 `Runnable`，我们也可以创建 `FutureTask`，然后直接交给 `ExecutorService` 执行。 * 最后，主线程可以执行 `FutureTask.get()`方法来等待任务执行完成。主线程也可以执行 `FutureTask.cancel（boolean mayInterruptIfRunning）`来取消此任务的执行。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-c6d135b6c525dca2f8651397c45f36d41434b09c%2FPasted%20image%2020250221223618.png?alt=media) #### ThreadPoolExecutor 类介绍（重要） 线程池实现类 `ThreadPoolExecutor` 是 `Executor` 框架最核心的类。 **线程池参数分析** `ThreadPoolExecutor` 3 个最重要的参数： * `corePoolSize`：任务队列未达到队列容量时，最大可以同时运行的线程数量。 * `maximumPoolSize`：任务队列中存放的任务达到队列容量的时候，当前可以同时运行的线程数量变为最大线程数。 * `workQueue`：新任务来的时候会先判断当前运行的线程数量是否达到核心线程数，如果达到的话，新任务就会被存放在队列中。 `ThreadPoolExecutor`其他常见参数： * `keepAliveTime`：当线程池中的线程数量大于 `corePoolSize` ，即有非核心线程（线程池中核心线程以外的线程）时，这些非核心线程空闲后不会立即销毁，而是会等待，直到等待的时间超过了 `keepAliveTime`才会被回收销毁。 * `unit`：`keepAliveTime` 参数的时间单位。 * `threadFactory` :executor 创建新线程的时候会用到。 * `handler`：拒绝策略。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-2534b55267ac52dc78b6d645eb64517ffb5a74b9%2FPasted%20image%2020250221224040.jpg?alt=media) **拒绝策略** 如果当前同时运行的线程数量达到最大线程数量并且队列也已经被放满了任务时，`ThreadPoolExecutor` 定义一些策略: * `ThreadPoolExecutor.AbortPolicy`：抛出 `RejectedExecutionException`来拒绝新任务的处理。 * `ThreadPoolExecutor.CallerRunsPolicy`：调用执行自己的线程运行任务，也就是直接在调用`execute`方法的线程中运行(`run`)被拒绝的任务，如果执行程序已关闭，则会丢弃该任务。因此这种策略会降低对于新任务提交速度，影响程序的整体性能。如果您的应用程序可以承受此延迟并且你要求任何一个任务请求都要被执行的话，你可以选择这个策略。 * `ThreadPoolExecutor.DiscardPolicy`：不处理新任务，直接丢弃掉。 * `ThreadPoolExecutor.DiscardOldestPolicy`：此策略将丢弃最早的未处理的任务请求。 **如果不允许丢弃任务任务，应该选择哪个拒绝策略？** 默认使用的是 `AbortPolicy`。在这种拒绝策略下，如果队列满了，`ThreadPoolExecutor` 将抛出 `RejectedExecutionException` 异常来拒绝新来的任务 ，这代表你将丢失对这个任务的处理。如果不想丢弃任务的话，可以使用`CallerRunsPolicy`。`CallerRunsPolicy` 和其他的几个策略不同，它既不会抛弃任务，也不会抛出异常，而是将任务回退给调用者，使用调用者的线程来执行任务。 **CallerRunsPolicy 拒绝策略有什么风险？如何解决？** 如果走到`CallerRunsPolicy`的任务是个非常耗时的任务，且处理提交任务的线程是主线程，可能会导致主线程阻塞，进而导致后续任务无法及时执行，严重的情况下很可能导致 OOM。 我们从问题的本质入手，调用者采用`CallerRunsPolicy`是希望所有的任务都能够被执行，暂时无法处理的任务又被保存在阻塞队列`BlockingQueue`中。这样的话，在内存允许的情况下，我们可以增加阻塞队列`BlockingQueue`的大小并调整堆内存以容纳更多的任务，确保任务能够被准确执行。 为了充分利用 CPU，我们还可以调整线程池的`maximumPoolSize` （最大线程数）参数，这样可以提高任务处理速度，避免累计在 `BlockingQueue`的任务过多导致内存用完。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-171bd7abed3dd19db5d91f1a03eaac6299faef67%2FPasted%20image%2020250221145248.png?alt=media) 这里提供的一种**任务持久化**的思路，这里所谓的任务持久化，包括但不限于: 1. 设计一张任务表将任务存储到 MySQL 数据库中。 2. Redis 缓存任务。 3. 将任务提交到消息队列中。 这里以方案一为例，简单介绍一下实现逻辑： 1. 实现`RejectedExecutionHandler`接口自定义拒绝策略，自定义拒绝策略负责将线程池暂时无法处理（此时阻塞队列已满）的任务入库（保存到 MySQL 中）。注意：线程池暂时无法处理的任务会先被放在阻塞队列中，阻塞队列满了才会触发拒绝策略。 2. 继承`BlockingQueue`实现一个混合式阻塞队列，该队列包含 JDK 自带的`ArrayBlockingQueue`。另外，该混合式阻塞队列需要修改取任务处理的逻辑，也就是重写`take()`方法，取任务时优先从数据库中读取最早的任务，数据库中无任务时再从 `ArrayBlockingQueue`中去取任务。 当然，对于这个问题，我们也可以参考其他主流框架的做法，以 Netty 为例，它的拒绝策略则是直接创建一个线程池以外的线程处理这些任务，为了保证任务的实时处理，这种做法可能需要良好的硬件设备且临时创建的线程无法做到准确的监控： **线程池创建的两种方式** * **方式一：通过 `ThreadPoolExecutor` 构造函数来创建（推荐）。** * **方式二：通过 `Executor` 框架的工具类 `Executors` 来创建。** 《阿里巴巴 Java 开发手册》强制线程池不允许使用 `Executors` 去创建，而是通过 `ThreadPoolExecutor` 构造函数的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险 **为什么不允许在应用中自行显式创建线程** 使用线程池的好处是减少在创建和销毁线程上所消耗的时间以及系统资源开销，解决资源不足的问题。如果不使用线程池，有可能会造成系统创建大量同类线程而导致消耗完内存或者“过度切换”的问题。 **线程池常用的阻塞队列总结** 新任务来的时候会先判断当前运行的线程数量是否达到核心线程数，如果达到的话，新任务就会被存放在队列中。 * 容量为 `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`，所以最多只能创建核心线程数的线程。 #### 线程池原理分析（重要） **线程池原理分析** * 如果当前运行的线程数小于核心线程数，那么就会新建一个线程来执行任务。 * 如果当前运行的线程数等于或大于核心线程数，但是小于最大线程数，那么就把该任务放入到任务队列里等待执行。 * 如果向任务队列投放任务失败（任务队列已经满了），但是当前运行的线程数是小于最大线程数的，就新建一个线程来执行任务。 * 如果当前运行的线程数已经等同于最大线程数了，新建线程将会使当前运行的线程超出最大线程数，那么当前任务会被拒绝，拒绝策略会调用`RejectedExecutionHandler.rejectedExecution()`方法。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-a79758e5fc5252f36cc753c3ad38eed3cc6617c2%2FPasted%20image%2020250221224548.png?alt=media) **线程池的核心线程会被回收吗？** `ThreadPoolExecutor` 默认不会回收核心线程，即使它们已经空闲了。这是为了减少创建线程的开销，因为核心线程通常是要长期保持活跃的。但是，如果线程池是被用于周期性使用的场景，且频率不高（周期之间有明显的空闲时间），可以考虑将 `allowCoreThreadTimeOut(boolean value)` 方法的参数设置为 `true`，这样就会回收空闲（时间间隔由 `keepAliveTime` 指定）的核心线程了。 **线程池在提交任务前，可以提前创建线程吗？** `ThreadPoolExecutor` 提供了两个方法帮助我们在提交任务之前，完成核心线程的创建，从而实现线程池预热的效果： * `prestartCoreThread()`：启动一个线程，等待任务，如果已达到核心线程数，这个方法返回 false，否则返回 true； * `prestartAllCoreThreads()`：启动所有的核心线程，并返回启动成功的核心线程数。 **线程池中线程异常后，销毁还是复用？** * **使用`execute()`提交任务**：当任务通过`execute()`提交到线程池并在执行过程中抛出异常时，如果这个异常没有在任务内被捕获，那么该异常会导致当前线程终止，并且异常会被打印到控制台或日志文件中。线程池会检测到这种线程终止，并创建一个新线程来替换它，从而保持配置的线程数不变。 * **使用`submit()`提交任务**：对于通过`submit()`提交的任务，如果在任务执行中发生异常，这个异常不会直接打印出来。相反，异常会被封装在由`submit()`返回的`Future`对象中。当调用`Future.get()`方法时，可以捕获到一个`ExecutionException`。在这种情况下，线程不会因为异常而终止，它会继续存在于线程池中，准备执行后续的任务。 **几个常见的对比** **`Runnable` vs `Callable`** `Runnable`自 Java 1.0 以来一直存在，但`Callable`仅在 Java 1.5 中引入,目的就是为了来处理`Runnable`不支持的用例。`Runnable` 接口不会返回结果或抛出检查异常，但是 `Callable` 接口可以。所以，如果任务不需要返回结果或抛出异常推荐使用 `Runnable` 接口，这样代码看起来会更加简洁。 工具类 `Executors` 可以实现将 `Runnable` 对象转换成 `Callable` 对象。（`Executors.callable(Runnable task)` 或 `Executors.callable(Runnable task, Object result)`）。 **`execute()` vs `submit()`** `execute()` 和 `submit()`是两种提交任务到线程池的方法，有一些区别： **返回值**：`execute()` 方法用于提交不需要返回值的任务。通常用于执行 `Runnable` 任务，无法判断任务是否被线程池成功执行。`submit()` 方法用于提交需要返回值的任务。可以提交 `Runnable` 或 `Callable` 任务。`submit()` 方法返回一个 `Future` 对象，通过这个 `Future` 对象可以判断任务是否执行成功，并获取任务的返回值（`get()`方法会阻塞当前线程直到任务完成， `get（long timeout，TimeUnit unit）`多了一个超时时间，如果在 `timeout` 时间内任务还没有执行完，就会抛出 `java.util.concurrent.TimeoutException`）。 **异常处理**：在使用 `submit()` 方法时，可以通过 `Future` 对象处理任务执行过程中抛出的异常；而在使用 `execute()` 方法时，异常处理需要通过自定义的 `ThreadFactory` （在线程工厂创建线程的时候设置`UncaughtExceptionHandler`对象来 处理异常）或 `ThreadPoolExecutor` 的 `afterExecute()` 方法来处理 **`shutdown()`VS`shutdownNow()`** * **`shutdown（）`** :关闭线程池，线程池的状态变为 `SHUTDOWN`。线程池不再接受新任务了，但是队列里的任务得执行完毕。 * **`shutdownNow（）`** :关闭线程池，线程池的状态变为 `STOP`。线程池会终止当前正在运行的任务，并停止处理排队的任务并返回正在等待执行的 List。 #### 如何设计一个能够根据任务的优先级来执行的线程池？ 假如我们需要实现一个优先级任务线程池的话，那可以考虑使用 `PriorityBlockingQueue` （优先级阻塞队列）作为任务队列（`ThreadPoolExecutor` 的构造函数有一个 `workQueue` 参数可以传入任务队列）。 `PriorityBlockingQueue` 是一个支持优先级的无界阻塞队列，可以看作是线程安全的 `PriorityQueue`，两者底层都是使用小顶堆形式的二叉堆，即值最小的元素优先出队。不过，`PriorityQueue` 不支持阻塞操作。 要想让 `PriorityBlockingQueue` 实现对任务的排序，传入其中的任务必须是具备排序能力的，方式有两种： * 提交到线程池的任务实现 `Comparable` 接口，并重写 `compareTo` 方法来指定任务之间的优先级比较规则。 * 创建 `PriorityBlockingQueue` 时传入一个 `Comparator` 对象来指定任务之间的排序规则(推荐)。 #### Java 线程池最佳实践 **正确声明线程池** **线程池必须手动通过 `ThreadPoolExecutor` 的构造函数来声明，避免使用 `Executors` 类创建线程池，会有 OOM 风险。** * **`FixedThreadPool` 和 `SingleThreadExecutor`**：使用的是有界阻塞队列 `LinkedBlockingQueue`，任务队列的默认长度和最大长度为 `Integer.MAX_VALUE`，可能堆积大量的请求，从而导致 OOM。 * **`CachedThreadPool`**：使用的是同步队列 `SynchronousQueue`，允许创建的线程数量为 `Integer.MAX_VALUE` ，可能会创建大量线程，从而导致 OOM。 * **`ScheduledThreadPool` 和 `SingleThreadScheduledExecutor`** : 使用的无界的延迟阻塞队列`DelayedWorkQueue`，任务队列最大长度为 `Integer.MAX_VALUE`，可能堆积大量的请求，从而导致 OOM。 除了避免 OOM 的原因之外，不推荐使用 `Executors` 提供的两种快捷的线程池的原因还有： * 实际使用中需要根据自己机器的性能、业务场景来手动配置线程池的参数比如核心线程数、使用的任务队列、饱和策略等等。 * 我们应该显示地给我们的线程池命名，这样有助于我们定位问题。 **监测线程池运行状态** 你可以通过一些手段来检测线程池的运行状态比如 SpringBoot 中的 Actuator 组件。 **建议不同类别的业务用不同的线程池** 一般建议是不同的业务使用不同的线程池，配置线程池的时候根据当前业务的情况对当前线程池进行配置，因为不同的业务的并发以及对资源的使用情况都不同，重心优化系统性能瓶颈相关的业务。 **别忘记给线程池命名** 初始化线程池的时候需要显示命名（设置线程池名称前缀），有利于定位问题。 * 利用 guava 的 `ThreadFactoryBuilder`。 * 自己实现 `public final class NamingThreadFactory implements ThreadFactory`。 **正确配置线程池参数** 对于多线程这个场景来说线程数量过多主要是增加了**上下文切换**成本。 多线程编程中一般线程的个数都大于 CPU 核心的个数，而一个 CPU 核心在任意时刻只能被一个线程使用，为了让这些线程都能得到有效执行，CPU 采取的策略是为每个线程分配时间片并轮转的形式。当一个线程的时间片用完的时候就会重新处于就绪状态让给其他线程使用，这个过程就属于一次上下文切换。当前任务在执行完 CPU 时间片切换到另一个任务之前会先保存自己的状态，以便下次再切换回这个任务时，可以再加载这个任务的状态。**任务从保存到再加载的过程就是一次上下文切换**。 上下文切换通常是计算密集型的。也就是说，它需要相当可观的处理器时间，在每秒几十上百次的切换中，每次切换都需要纳秒量级的时间。所以，上下文切换对系统来说意味着消耗大量的 CPU 时间，事实上，可能是操作系统中时间消耗最大的操作。 * 如果我们设置的线程池数量太小的话，如果同一时间有大量任务/请求需要处理，可能会导致大量的请求/任务在任务队列中排队等待执行，甚至会出现任务队列满了之后任务/请求无法处理的情况，或者大量任务堆积在任务队列导致 OOM。这样很明显是有问题的，CPU 根本没有得到充分利用。 * 如果我们设置线程数量太大，大量线程可能会同时在争取 CPU 资源，这样会导致大量的上下文切换，从而增加线程的执行时间，影响了整体执行效率。 有一个简单并且适用面比较广的公式： * **CPU 密集型任务(N+1)：** 这种任务消耗的主要是 CPU 资源，可以将线程数设置为 N（CPU 核心数）+1。比 CPU 核心数多出来的一个线程是为了防止线程偶发的缺页中断，或者其它原因导致的任务暂停而带来的影响。一旦任务暂停，CPU 就会处于空闲状态，而在这种情况下多出来的一个线程就可以充分利用 CPU 的空闲时间。 * **I/O 密集型任务(2N)：** 这种任务应用起来，系统会用大部分的时间来处理 I/O 交互，而线程在处理 I/O 的时间段内不会占用 CPU 来处理，这时就可以将 CPU 交出给其它线程使用。因此在 I/O 密集型任务的应用中，我们可以多配置一些线程，具体的计算方法是 2N。 **如何判断是 CPU 密集任务还是 IO 密集任务？** CPU 密集型简单理解就是利用 CPU 计算能力的任务比如你在内存中对大量数据进行排序。但凡涉及到网络读取，文件读取这类都是 IO 密集型，这类任务的特点是 CPU 计算耗费时间相比于等待 IO 操作完成的时间来说很少，大部分时间都花在了等待 IO 操作完成上。 线程数更严谨的计算的方法应该是：`最佳线程数 = N（CPU 核心数）∗（1+WT（线程等待时间）/ST（线程计算时间））`，其中 `WT（线程等待时间）=线程运行总时间 - ST（线程计算时间）`。 线程等待时间所占比例越高，需要越多线程。线程计算时间所占比例越高，需要越少线程。 我们可以通过 JDK 自带的工具 VisualVM 来查看 `WT/ST` 比例。CPU 密集型任务的 `WT/ST` 接近或者等于 0，因此， 线程数可以设置为 N（CPU 核心数）∗（1+0）= N。 IO 密集型任务下，几乎全是线程等待时间，从理论上来说，你就可以将线程数设置为 2N（按道理来说，WT/ST 的结果应该比较大，这里选择 2N 的原因应该是为了避免创建过多线程吧）。 **别忘记关闭线程池** 当线程池不再需要使用时，应该显式地关闭线程池，释放线程资源。线程池提供了两个关闭方法： * **`shutdown（）`** :关闭线程池，线程池的状态变为 `SHUTDOWN`。线程池不再接受新任务了，但是队列里的任务得执行完毕。 * **`shutdownNow（）`** :关闭线程池，线程池的状态变为 `STOP`。线程池会终止当前正在运行的任务，停止处理排队的任务并返回正在等待执行的 List。 调用完 `shutdownNow` 和 `shuwdown` 方法后，并不代表线程池已经完成关闭操作，它只是异步的通知线程池进行关闭处理。如果要同步等待线程池彻底关闭后才继续往下执行，需要调用`awaitTermination`方法进行同步等待。 在调用 `awaitTermination()` 方法时，应该设置合理的超时时间，以避免程序长时间阻塞而导致性能问题。另外。由于线程池中的任务可能会被取消或抛出异常，因此在使用 `awaitTermination()` 方法时还需要进行异常处理。`awaitTermination()` 方法会抛出 `InterruptedException` 异常，需要捕获并处理该异常，以避免程序崩溃或者无法正常退出。 **线程池尽量不要放耗时任务** 线程池本身的目的是为了提高任务执行效率，避免因频繁创建和销毁线程而带来的性能开销。如果将耗时任务提交到线程池中执行，可能会导致线程池中的线程被长时间占用，无法及时响应其他任务，甚至会导致线程池崩溃或者程序假死。 因此，在使用线程池时，我们应该尽量避免将耗时任务提交到线程池中执行。对于一些比较耗时的操作，如网络请求、文件读写等，可以采用 `CompletableFuture` 等其他异步操作的方式来处理，以避免阻塞线程池中的线程。 **线程池使用的一些小坑** **线程池和 ThreadLocal 共用的坑** 线程池和 `ThreadLocal`共用，可能会导致线程从`ThreadLocal`获取到的是旧值/脏数据。这是因为线程池会复用线程对象，与线程对象绑定的类的静态属性 `ThreadLocal` 变量也会被重用，这就导致一个线程可能获取到其他线程的`ThreadLocal` 值。 ### Future #### Future 类有什么用？ `Future` 类是异步思想的典型运用，主要用在一些需要执行耗时任务的场景，避免程序一直原地等待耗时任务执行完成，执行效率太低。具体来说是这样的：当我们执行某一耗时的任务时，可以将这个耗时任务交给一个子线程去异步执行，同时我们可以干点其他事情，不用傻傻等待耗时任务执行完成。等我们的事情干完后，我们再通过 `Future` 类获取到耗时任务的执行结果。这样一来，程序的执行效率就明显提高了。 这其实就是多线程中经典的 **Future 模式**，你可以将其看作是一种设计模式，核心思想是异步调用，主要用在多线程领域，并非 Java 语言独有。 在 Java 中，`Future` 类只是一个泛型接口，位于 `java.util.concurrent` 包下，其中定义了 5 个方法，主要包括下面这 4 个功能： * 取消任务； * 判断任务是否被取消; * 判断任务是否已经执行完成; * 获取任务执行结果。 #### Callable 和 Future 有什么关系？ `FutureTask` 提供了 `Future` 接口的基本实现，常用来封装 `Callable` 和 `Runnable`，具有取消任务、查看任务是否执行完成以及获取任务执行结果的方法。`ExecutorService.submit()` 方法返回的其实就是 `Future` 的实现类 `FutureTask` 。 `FutureTask` 不光实现了 `Future`接口，还实现了`Runnable` 接口，因此可以作为任务直接被线程执行。 `FutureTask` 有两个构造函数，可传入 `Callable` 或者 `Runnable` 对象。实际上，传入 `Runnable` 对象也会在方法内部转换为`Callable` 对象。 #### CompletableFuture 类有什么用？ `Future` 在实际使用过程中存在一些局限性比如不支持异步任务的编排组合、获取计算结果的 `get()` 方法为阻塞调用。 Java 8 才被引入`CompletableFuture` 类可以解决`Future` 的这些缺陷。`CompletableFuture` 除了提供了更为好用和强大的 `Future` 特性之外，还提供了函数式编程、异步任务编排组合（可以将多个异步任务串联起来，组成一个完整的链式调用）等能力。 `CompletableFuture` 同时实现了 `Future` 和 `CompletionStage` 接口。 `CompletionStage` 接口描述了一个异步计算的阶段。很多计算可以分成多个阶段或步骤，此时可以通过它将所有步骤组合起来，形成异步计算的流水线。`CompletableFuture` 的函数式能力就是这个接口赋予的。 #### CompletableFuture 常见操作 **创建 CompletableFuture** 常见的创建 `CompletableFuture` 对象的方法如下： 1. 通过 new 关键字。通过 new 关键字创建 `CompletableFuture` 对象这种使用方式可以看作是将 `CompletableFuture` 当做 `Future` 来使用。 2. 基于 `CompletableFuture` 自带的静态工厂方法：`runAsync()`、`supplyAsync()` 。 **静态工厂方法** `runAsync()` 方法接受的参数是 `Runnable` ，这是一个函数式接口，不允许返回值。当你需要异步操作且不关心返回结果的时候可以使用 `runAsync()` 方法。 `supplyAsync()` 方法接受的参数是 `Supplier` ，这也是一个函数式接口，`U` 是返回结果值的类型。当你需要异步操作且关心返回结果的时候,可以使用 `supplyAsync()` 方法。 ```java static CompletableFuture supplyAsync(Supplier supplier); // 使用自定义线程池(推荐) static CompletableFuture supplyAsync(Supplier supplier, Executor executor); static CompletableFuture runAsync(Runnable runnable); // 使用自定义线程池(推荐) static CompletableFuture runAsync(Runnable runnable, Executor executor); ``` **处理异步结算的结果** 当我们获取到异步计算的结果之后，还可以对其进行进一步的处理，比较常用的方法有下面几个： * `thenApply()` * `thenAccept()` * `thenRun()` * `whenComplete()` **如果你不需要从回调函数中获取返回结果，可以使用 `thenAccept()` 或者 `thenRun()`。这两个方法的区别在于 `thenRun()` 不能访问异步计算的结果。** **异常处理** 你可以通过 `handle()` 方法来处理任务执行过程中可能出现的抛出异常的情况。 **组合 CompletableFuture** 你可以使用 `thenCompose()` 按顺序链接两个 `CompletableFuture` 对象，实现异步的任务链。它的作用是将前一个任务的返回结果作为下一个任务的输入参数，从而形成一个依赖关系。 和 `thenCompose()` 方法类似的还有 `thenCombine()` 方法， 它同样可以组合两个 `CompletableFuture` 对象。 **那 `thenCompose()` 和 `thenCombine()` 有什么区别呢？** * `thenCompose()` 可以链接两个 `CompletableFuture` 对象，并将前一个任务的返回结果作为下一个任务的参数，它们之间存在着先后顺序。 * `thenCombine()` 会在两个任务都执行完成后，把两个任务的结果合并。两个任务是并行执行的，它们之间并没有先后依赖顺序。 **并行运行多个 CompletableFuture** 你可以通过 `CompletableFuture` 的 `allOf()`这个静态方法来并行运行多个 `CompletableFuture` 。 **`anyOf()` 方法不会等待所有的 `CompletableFuture` 都运行完成之后再返回，只要有一个执行完成即可。** #### 一个任务需要依赖另外两个任务执行完之后再执行，怎么设计？ ```java // T1 CompletableFuture futureT1 = CompletableFuture.runAsync(() -> { System.out.println("T1 is executing. Current time：" + DateUtil.now()); // 模拟耗时操作 ThreadUtil.sleep(1000); }); // T2 CompletableFuture futureT2 = CompletableFuture.runAsync(() -> { System.out.println("T2 is executing. Current time：" + DateUtil.now()); ThreadUtil.sleep(1000); }); // 使用allOf()方法合并T1和T2的CompletableFuture，等待它们都完成 CompletableFuture bothCompleted = CompletableFuture.allOf(futureT1, futureT2); // 当T1和T2都完成后，执行T3 bothCompleted.thenRunAsync(() -> System.out.println("T3 is executing after T1 and T2 have completed.Current time：" + DateUtil.now())); // 等待所有任务完成，验证效果 ThreadUtil.sleep(3000); ``` #### 使用 CompletableFuture，有一个任务失败，如何处理异常？ * 使用 `whenComplete` 方法可以在任务完成时触发回调函数，并正确地处理异常，而不是让异常被吞噬或丢失。 * 使用 `exceptionally` 方法可以处理异常并重新抛出，以便异常能够传播到后续阶段，而不是让异常被忽略或终止。 * 使用 `handle` 方法可以处理正常的返回结果和异常，并返回一个新的结果，而不是让异常影响正常的业务逻辑。 * 使用 `CompletableFuture.allOf` 方法可以组合多个 `CompletableFuture`，并统一处理所有任务的异常，而不是让异常处理过于冗长或重复。 #### 在使用 CompletableFuture 的时候为什么要自定义线程池？ `CompletableFuture` 默认使用全局共享的 `ForkJoinPool.commonPool()` 作为执行器，所有未指定执行器的异步任务都会使用该线程池。这意味着应用程序、多个库或框架（如 Spring、第三方库）若都依赖 `CompletableFuture`，默认情况下它们都会共享同一个线程池。 虽然 `ForkJoinPool` 效率很高，但当同时提交大量任务时，可能会导致资源竞争和线程饥饿，进而影响系统性能。 为避免这些问题，建议为 `CompletableFuture` 提供自定义线程池，带来以下优势： * 隔离性：为不同任务分配独立的线程池，避免全局线程池资源争夺。 * 资源控制：根据任务特性调整线程池大小和队列类型，优化性能表现。 * 异常处理：通过自定义 `ThreadFactory` 更好地处理线程中的异常情况。 ### AQS #### AQS 是什么？ AQS 的全称为 `AbstractQueuedSynchronizer` ，翻译过来的意思就是抽象队列同步器。这个类在 `java.util.concurrent.locks` 包下面。 #### AQS 原理 **AQS 的作用是什么？** AQS 解决了开发者在实现同步器时的复杂性问题。它提供了一个通用框架，用于实现各种同步器，例如 **可重入锁**（`ReentrantLock`）、**信号量**（`Semaphore`）和 **倒计时器**（`CountDownLatch`）。通过封装底层的线程同步机制，AQS 将复杂的线程管理逻辑隐藏起来，使开发者只需专注于具体的同步逻辑。 简单来说，AQS 是一个抽象类，为同步器提供了通用的 **执行框架**。它定义了 **资源获取和释放的通用流程**，而具体的资源获取逻辑则由具体同步器通过重写模板方法来实现。 因此，可以将 AQS 看作是同步器的 **基础“底座”**，而同步器则是基于 AQS 实现的 **具体“应用”**。 **AQS 核心思想** AQS 核心思想是，如果被请求的共享资源空闲，则将当前请求资源的线程设置为有效的工作线程，并且将共享资源设置为锁定状态。如果被请求的共享资源被占用，那么就需要一套线程阻塞等待以及被唤醒时锁分配的机制，这个机制 AQS 是基于 **CLH 锁** （Craig, Landin, and Hagersten locks） 进一步优化实现的。 CLH 锁是一种基于 **自旋锁** 的优化实现。自旋锁通过线程不断对一个原子变量执行 `compareAndSet`（简称 `CAS`）操作来尝试获取锁。在高并发场景下，多个线程会同时竞争同一个原子变量，容易造成某个线程的 `CAS` 操作长时间失败，从而导致 **“饥饿”问题**（某些线程可能永远无法获取锁）。 **CLH 锁** 对自旋锁进行了改进，是基于单链表的自旋锁。在多线程场景下，会将请求获取锁的线程组织成一个单向队列，每个等待的线程会通过自旋访问前一个线程节点的状态，前一个节点释放锁之后，当前节点才可以获取锁。 * 每个线程会作为一个节点加入到队列中，并通过自旋监控前一个线程节点的状态，而不是直接竞争共享变量。 * 线程按顺序排队，确保公平性，从而避免了 “饥饿” 问题。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-247176c23204405288d51e972dbfd9bb34272662%2FPasted%20image%2020250221233707.png?alt=media) AQS 中使用的 **等待队列** 是 CLH 锁队列的变体（接下来简称为 CLH 变体队列）。 AQS 的 CLH 变体队列是一个双向队列，会暂时获取不到锁的线程将被加入到该队列中，CLH 变体队列和原本的 CLH 锁队列的区别主要有两点： * 由 **自旋** 优化为 **自旋 + 阻塞** ：自旋操作的性能很高，但大量的自旋操作比较占用 CPU 资源，因此在 CLH 变体队列中会先通过自旋尝试获取锁，如果失败再进行阻塞等待。 * 由 **单向队列** 优化为 **双向队列** ：**在 CLH 变体队列中，会对等待的线程进行阻塞操作，当队列前边的线程释放锁之后，需要对后边的线程进行唤醒**，因此增加了 `next` 指针，成为了双向队列。 AQS 将每条请求共享资源的线程封装成一个 CLH 变体队列的一个结点（Node）来实现锁的分配。在 CLH 变体队列中，一个节点表示一个线程，它保存着线程的引用（thread）、 当前节点在队列中的状态（waitStatus）、前驱节点（prev）、后继节点（next）。 AQS 使用 **int 成员变量 `state` 表示同步状态**，通过内置的 **FIFO 线程等待/等待队列** 来完成获取资源线程的排队工作。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-3cdf4dc534241f5c0113cc06acbbfc0953303558%2FPasted%20image%2020250221233718.png?alt=media) 以可重入的互斥锁 `ReentrantLock` 为例，它的内部维护了一个 `state` 变量，用来表示锁的占用状态。`state` 的初始值为 0，表示锁处于未锁定状态。当线程 A 调用 `lock()` 方法时，会尝试通过 `tryAcquire()` 方法独占该锁，并让 `state` 的值加 1。如果成功了，那么线程 A 就获取到了锁。如果失败了，那么线程 A 就会被加入到一个等待队列（CLH 变体队列）中，直到其他线程释放该锁。假设线程 A 获取锁成功了，释放锁之前，A 线程自己是可以重复获取此锁的（`state` 会累加）。这就是可重入性的体现：一个线程可以多次获取同一个锁而不会被阻塞。但是，这也意味着，一个线程必须释放与获取的次数相同的锁，才能让 `state` 的值回到 0，也就是让锁恢复到未锁定状态。只有这样，其他等待的线程才能有机会获取该锁。 **AQS 的性能比较好，原因是什么？** 因为 AQS 里使用了 `CAS` + `线程阻塞/唤醒` 。 在 AQS 的实现里，大量使用了 `CAS` 操作，`CAS` 基于内存地址直接进行数据修改，保证并发安全的同时，性能也很好。 但是如果一直通过 `CAS` 操作来更新数据，会比较占用 CPU。因此 AQS 同时结合了 `CAS` 和 `线程的阻塞/唤醒` 机制，当 `CAS` 没有成功获取资源时，会对线程进行阻塞，避免一直空转占用 CPU 资源。 **AQS 中为什么 Node 节点需要不同的状态？** AQS 中的 `waitStatus` 状态类似于 **状态机** ，通过不同状态来表明 Node 节点的不同含义，并且根据不同操作，来控制状态之间的流转。 在 AQS 中，一个节点加入队列之后，初始状态为 `0` 。 当有新的节点加入队列，此时新节点的前继节点状态就会由 `0` 更新为 `SIGNAL` ，表示前继节点释放锁之后，需要对新节点进行唤醒操作。 如果一个节点在队列中等待获取锁锁时，因为某种原因失败了，该节点的状态就会变为 `CANCELLED` ，表明取消获取锁，这种状态的节点是异常的，无法被唤醒，也无法唤醒后继节点。 #### 常见同步工具类 **Semaphore（信号量）** **Semaphore 有什么用？** `synchronized` 和 `ReentrantLock` 都是一次只允许一个线程访问某个资源，而`Semaphore`(信号量)可以用来控制同时访问特定资源的线程数量。 当初始的资源个数为 1 的时候，`Semaphore` 退化为排他锁。 `Semaphore` 有两种模式：。 * **公平模式：** 调用 `acquire()` 方法的顺序就是获取许可证的顺序，遵循 FIFO； * **非公平模式：** 抢占式的。 `Semaphore` 通常用于那些资源有明确访问数量限制的场景比如限流（仅限于单机模式，实际项目中推荐使用 Redis +Lua 来做限流）。 **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` 则获取令牌成功，否则重新进入阻塞队列，挂起线程。 **CountDownLatch（倒计时器）** **CountDownLatch 有什么用？** `CountDownLatch` 允许 `count` 个线程阻塞在一个地方，直至所有线程的任务都执行完毕。 `CountDownLatch` 是一次性的，计数器的值只能在构造方法中初始化一次，之后没有任何机制再次对其设置值，当 `CountDownLatch` 使用完毕后，它不能再次被使用。 **CountDownLatch 的原理是什么？** `CountDownLatch` 是共享锁的一种实现,它默认构造 AQS 的 `state` 值为 `count`。当线程使用 `countDown()` 方法时,其实使用了`tryReleaseShared`方法以 CAS 的操作来减少 `state`，直至 `state` 为 0 。当调用 `await()` 方法的时候，如果 `state` 不为 0，那就证明任务还没有执行完毕，`await()` 方法就会一直阻塞，也就是说 `await()` 方法之后的语句不会被执行。直到`count` 个线程调用了`countDown()`使 state 值被减为 0，或者调用`await()`的线程被中断，该线程才会从阻塞中被唤醒，`await()` 方法之后的语句得到执行。 **用过 CountDownLatch 么？什么场景下用的？** `CountDownLatch` 的作用就是 允许 count 个线程阻塞在一个地方，直至所有线程的任务都执行完毕。之前在项目中，有一个使用多线程读取多个文件处理的场景，我用到了 `CountDownLatch` 。具体场景是下面这样的： 我们要读取处理 6 个文件，这 6 个任务都是没有执行顺序依赖的任务，但是我们需要返回给用户的时候将这几个文件的处理的结果进行统计整理。 为此我们定义了一个线程池和 count 为 6 的`CountDownLatch`对象 。使用线程池处理读取任务，每一个线程处理完之后就将 count-1，调用`CountDownLatch`对象的 `await()`方法，直到所有文件读取完之后，才会接着执行后面的逻辑。 实现多个线程开始执行任务的最大并行性：注意是并行性，不是并发，强调的是多个线程在某一时刻同时开始执行。类似于赛跑，将多个线程放到起点，等待发令枪响，然后同时开跑。做法是初始化一个共享的 `CountDownLatch` 对象，将其计数器初始化为 1 （`new CountDownLatch(1)`），多个线程在开始执行任务前首先 `coundownlatch.await()`，当主线程调用 `countDown()` 时，计数器变为 0，多个线程同时被唤醒。 **有没有可以改进的地方呢？** 可以使用 `CompletableFuture` 类来改进！Java8 的 `CompletableFuture` 提供了很多对多线程友好的方法，使用它可以很方便地为我们编写多线程程序，什么异步、串行、并行或者等待所有线程执行完任务什么的都非常方便。 **CyclicBarrier（循环栅栏）** **CyclicBarrier 有什么用？** `CyclicBarrier` 和 `CountDownLatch` 非常类似，它也可以实现线程间的技术等待，但是它的功能比 `CountDownLatch` 更加复杂和强大。主要应用场景和 `CountDownLatch` 类似。 `CountDownLatch` 的实现是基于 AQS 的，而 `CycliBarrier` 是基于 `ReentrantLock`(`ReentrantLock` 也属于 AQS 同步器)和 `Condition` 的。 `CyclicBarrier` 的字面意思是可循环使用（Cyclic）的屏障（Barrier）。它要做的事情是：让一组线程到达一个屏障（也可以叫同步点）时被阻塞，直到最后一个线程到达屏障时，屏障才会开门，所有被屏障拦截的线程才会继续干活。 **CyclicBarrier 的原理是什么？** `CyclicBarrier` 内部通过一个 `count` 变量作为计数器，`count` 的初始值为 `parties` 属性的初始化值，每当一个线程到了栅栏这里了，那么就将计数器减 1。如果 count 值为 0 了，表示这是这一代最后一个线程到达栅栏，就尝试执行我们构造方法中输入的任务。 ### Atomic #### Atomic 原子类介绍 `Atomic` 翻译成中文是“原子”的意思。在化学上，原子是构成物质的最小单位，在化学反应中不可分割。在编程中，`Atomic` 指的是一个操作具有原子性，即该操作不可分割、不可中断。即使在多个线程同时执行时，该操作要么全部执行完成，要么不执行，不会被其他线程看到部分完成的状态。 原子类简单来说就是具有原子性操作特征的类。`java.util.concurrent.atomic` 包中的 `Atomic` 原子类提供了一种线程安全的方式来操作单个变量。 `Atomic` 类依赖于 CAS（Compare-And-Swap，比较并交换）乐观锁来保证其方法的原子性，而不需要使用传统的锁机制（如 `synchronized` 块或 `ReentrantLock`）。 ### JMM JMM(Java 内存模型)主要定义了对于一个共享变量，当另一个线程对这个共享变量执行写操作后，这个线程对这个共享变量的可见性。 #### 从 CPU 缓存模型说起 **为什么要弄一个 CPU 高速缓存呢？CPU Cache 缓存的是内存数据用于解决 CPU 处理速度和内存不匹配的问题，内存缓存的是硬盘数据用于解决硬盘访问速度过慢的问题。** **CPU Cache 的工作方式：** 先复制一份数据到 CPU Cache 中，当 CPU 需要用到的时候就可以直接从 CPU Cache 中读取数据，当运算完成后，再将运算得到的数据写回 Main Memory 中。但是，这样存在 **内存缓存不一致性的问题** ！ **CPU 为了解决内存缓存不一致性问题可以通过制定缓存一致协议或者其他手段来解决。** 这个缓存一致性协议指的是在 CPU 高速缓存与主内存交互的时候需要遵守的原则和规范。不同的 CPU 中，使用的缓存一致性协议通常也会有所不同。 我们的程序运行在操作系统之上，操作系统屏蔽了底层硬件的操作细节，将各种硬件资源虚拟化。于是，操作系统也就同样需要解决内存缓存不一致性问题。 操作系统通过 **内存模型（Memory Model）** 定义一系列规范来解决这个问题。无论是 Windows 系统，还是 Linux 系统，它们都有特定的内存模型。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-114054e1849d1958a8a58aabbc7928ec72991d32%2FPasted%20image%2020250221191854.png?alt=media) #### 指令重排序 为了提升执行速度/性能，计算机在执行程序代码的时候，会对指令进行重排序。 常见的指令重排序有下面 2 种情况： * **编译器优化重排**：编译器（包括 JVM、JIT 编译器等）在不改变单线程程序语义的前提下，重新安排语句的执行顺序。 * **指令并行重排**：现代处理器采用了指令级并行技术(Instruction-Level Parallelism，ILP)来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。 另外，内存系统也会有“重排序”，但又不是真正意义上的重排序。在 JMM 里表现为主存和本地内存的内容可能不一致，进而导致程序在多线程下执行可能出现问题。 Java 源代码会经历 **编译器优化重排 —> 指令并行重排 —> 内存系统重排** 的过程，最终才变成操作系统可执行的指令序列。 **指令重排序可以保证串行语义一致，但是没有义务保证多线程间的语义也一致** ，所以在多线程下，指令重排序可能会导致一些问题。 对于编译器优化重排和处理器的指令重排序（指令并行重排和内存系统重排都属于是处理器级别的指令重排序），处理该问题的方式不一样。 * 对于编译器，通过禁止特定类型的编译器重排序的方式来禁止重排序。 * 对于处理器，通过插入内存屏障（Memory Barrier，或有时叫做内存栅栏，Memory Fence）的方式来禁止特定类型的处理器重排序。 #### JMM **什么是 JMM？为什么需要 JMM？** **Java 内存模型（JMM）** 抽象了线程和主内存之间的关系，就比如说线程之间的共享变量必须存储在主内存中。 在当前的 Java 内存模型下，线程可以把变量保存 **本地内存** （比如机器的寄存器）中，而不是直接在主存中进行读写。这就可能造成一个线程在主存中修改了一个变量的值，而另外一个线程还继续使用它在寄存器中的变量值的拷贝，造成数据的不一致。 **什么是主内存？什么是本地内存？** * **主内存**：所有线程创建的实例对象都存放在主内存中，不管该实例对象是成员变量，还是局部变量，类信息、常量、静态变量都是放在主内存中。为了获取更好的运行速度，虚拟机及硬件系统可能会让工作内存优先存储于寄存器和高速缓存中。 * **本地内存**：每个线程都有一个私有的本地内存，本地内存存储了该线程以读 / 写共享变量的副本。每个线程只能操作自己本地内存中的变量，无法直接访问其他线程的本地内存。如果线程间需要通信，必须通过主内存来进行。本地内存是 JMM 抽象出来的一个概念，并不真实存在，它涵盖了缓存、写缓冲区、寄存器以及其他的硬件和编译器优化。 **Java 内存模型** 从上图来看，线程 1 与线程 2 之间如果要进行通信的话，必须要经历下面 2 个步骤： 1. 线程 1 把本地内存中修改过的共享变量副本的值同步到主内存中去。 2. 线程 2 到主存中读取对应的共享变量的值。 也就是说，JMM 为共享变量提供了可见性的保障。不过，多线程下，对主内存中的一个共享变量进行操作有可能诱发线程安全问题： 1. 线程 1 和线程 2 分别对同一个共享变量进行操作，一个执行修改，一个执行读取。 2. 线程 2 读取到的是线程 1 修改之前的值还是修改后的值并不确定，都有可能，因为线程 1 和线程 2 都是先将共享变量从主内存拷贝到对应线程的工作内存中。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-b958950b1d0a21d3df4719c4ff7de55c7b56cac9%2FPasted%20image%2020250221192436.png?alt=media) **Java 内存区域和 JMM 有何区别？** **Java 内存区域和内存模型是完全不一样的两个东西**： * JVM 内存结构和 Java 虚拟机的运行时区域相关，定义了 JVM 在运行时如何分区存储程序数据，就比如说堆主要用于存放对象实例。 * Java 内存模型和 Java 的并发编程相关，抽象了线程和主内存之间的关系就比如说线程之间的共享变量必须存储在主内存中，规定了从 Java 源代码到 CPU 可执行指令的这个转化过程要遵守哪些和并发相关的原则和规范，其主要目的是为了简化多线程编程，增强程序可移植性的。 **happens-before 原则是什么？** happens-before 原则的诞生是为了程序员和编译器、处理器之间的平衡。程序员追求的是易于理解和编程的强内存模型，遵守既定规则编码即可。编译器和处理器追求的是较少约束的弱内存模型，让它们尽己所能地去优化性能，让性能最大化。happens-before 原则的设计思想其实非常简单： * 为了对编译器和处理器的约束尽可能少，只要不改变程序的执行结果（单线程程序和正确执行的多线程程序），编译器和处理器怎么进行重排序优化都行。 * 对于会改变程序执行结果的重排序，JMM 要求编译器和处理器必须禁止这种重排序。 happens-before 原则表达的意义其实并不是一个操作发生在另外一个操作的前面，虽然这从程序员的角度上来说也并无大碍。更准确地来说，它更想表达的意义是前一个操作的结果对于后一个操作是可见的，无论这两个操作是否在同一个线程里。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-bb13b62971557060f5c53a452764650a98f6551f%2FPasted%20image%2020250314151159.png?alt=media) **happens-before 常见规则有哪些？谈谈你的理解？** happens-before 的规则就 8 条，说多不多，重点了解下面列举的 5 条即可。 1. **程序顺序规则**：一个线程内，按照代码顺序，书写在前面的操作 happens-before 于书写在后面的操作； 2. **解锁规则**：解锁 happens-before 于加锁； 3. **volatile 变量规则**：对一个 volatile 变量的写操作 happens-before 于后面对这个 volatile 变量的读操作。说白了就是对 volatile 变量的写操作的结果对于发生于其后的任何操作都是可见的。 4. **传递规则**：如果 A happens-before B，且 B happens-before C，那么 A happens-before C； 5. **线程启动规则**：Thread 对象的 `start()`方法 happens-before 于此线程的每一个动作。 **happens-before 和 JMM 什么关系？** ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-0d0e6a9a38f2b5074c31d8fae29df593b2e5ae7f%2FPasted%20image%2020250221192926.png?alt=media) #### 再看并发编程三个重要特性 **原子性** 一次操作或者多次操作，要么所有的操作全部都得到执行并且不会受到任何因素的干扰而中断，要么都不执行。 在 Java 中，可以借助 `synchronized`、各种 `Lock` 以及各种原子类实现原子性。 `synchronized` 和各种 `Lock` 可以保证任一时刻只有一个线程访问该代码块，因此可以保障原子性。各种原子类是利用 CAS (compare and swap) 操作（可能也会用到 `volatile`或者`final`关键字）来保证原子操作。 **可见性** 当一个线程对共享变量进行了修改，那么另外的线程都是立即可以看到修改后的最新值。 如果我们将变量声明为 `volatile` ，这就指示 JVM，这个变量是共享且不稳定的，每次使用它都到主存中进行读取。 **有序性** 由于指令重排序问题，代码的执行顺序未必就是编写代码时候的顺序。 **指令重排序可以保证串行语义一致，但是没有义务保证多线程间的语义也一致** ，所以在多线程下，指令重排序可能会导致一些问题。 在 Java 中，`volatile` 关键字可以禁止指令进行重排序优化。 ## Java IO ### Java IO 基础知识 #### IO 流简介 IO 即 `Input/Output`，输入和输出。数据输入到计算机内存的过程即输入，反之输出到外部存储（比如数据库，文件，远程主机）的过程即输出。数据传输过程类似于水流，因此称为 IO 流。IO 流在 Java 中分为输入流和输出流，而根据数据的处理方式又分为字节流和字符流。 Java IO 流的 40 多个类都是从如下 4 个抽象类基类中派生出来的。 * `InputStream`/`Reader`: 所有的输入流的基类，前者是字节输入流，后者是字符输入流。 * `OutputStream`/`Writer`: 所有输出流的基类，前者是字节输出流，后者是字符输出流。 #### 字节流 **InputStream（字节输入流）** `InputStream`用于从源头（通常是文件）读取数据（字节信息）到内存中，`java.io.InputStream`抽象类是所有字节输入流的父类。 **常用方法** * `read()`：返回输入流中下一个字节的数据。返回的值介于 0 到 255 之间。如果未读取任何字节，则代码返回 `-1` ，表示文件结束。 * `read(byte b[ ])` : 从输入流中读取一些字节存储到数组 `b` 中。如果数组 `b` 的长度为零，则不读取。如果没有可用字节读取，返回 `-1`。如果有可用字节读取，则最多读取的字节数最多等于 `b.length` ， 返回读取的字节数。这个方法等价于 `read(b, 0, b.length)`。 * `read(byte b[], int off, int len)`：在`read(byte b[ ])` 方法的基础上增加了 `off` 参数（偏移量）和 `len` 参数（要读取的最大字节数）。 * `skip(long n)`：忽略输入流中的 n 个字节 ,返回实际忽略的字节数。 * `available()`：返回输入流中可以读取的字节数。 * `close()`：关闭输入流释放相关的系统资源。 `ObjectInputStream` 用于从输入流中读取 Java 对象（反序列化），`ObjectOutputStream` 用于将对象写入到输出流(序列化)。另外，用于序列化和反序列化的类必须实现 `Serializable` 接口，对象中如果有属性不想被序列化，使用 `transient` 修饰。 **OutputStream（字节输出流）** `OutputStream`用于将数据（字节信息）写入到目的地（通常是文件），`java.io.OutputStream`抽象类是所有字节输出流的父类。 **常用方法** * `write(int b)`：将特定字节写入输出流。 * `write(byte b[ ])` : 将数组`b` 写入到输出流，等价于 `write(b, 0, b.length)` 。 * `write(byte[] b, int off, int len)` : 在`write(byte b[ ])` 方法的基础上增加了 `off` 参数（偏移量）和 `len` 参数（要读取的最大字节数）。 * `flush()`：刷新此输出流并强制写出所有缓冲的输出字节。 * `close()`：关闭输出流释放相关的系统资源。 `ObjectInputStream` 用于从输入流中读取 Java 对象（`ObjectInputStream`,反序列化），`ObjectOutputStream`将对象写入到输出流(`ObjectOutputStream`，序列化)。 #### 字符流 不管是文件读写还是网络发送接收，信息的最小存储单元都是字节。 **那为什么 I/O 流操作要分为字节流操作和字符流操作呢？** * 字符流是由 Java 虚拟机将字节转换得到的，这个过程还算是比较耗时。 * 如果我们不知道编码类型就很容易出现乱码问题。 字符流默认采用的是 `Unicode` 编码，我们可以通过构造方法自定义编码。 Unicode 本身只是一种字符集，它为每个字符分配一个唯一的数字编号，并没有规定具体的存储方式。UTF-8、UTF-16、UTF-32 都是 Unicode 的编码方式，它们使用不同的字节数来表示 Unicode 字符。 **Reader（字符输入流）** `Reader`用于从源头（通常是文件）读取数据（字符信息）到内存中，`java.io.Reader`抽象类是所有字符输入流的父类。 `Reader` 用于读取文本， `InputStream` 用于读取原始字节。 **常用方法** * `read()` : 从输入流读取一个字符。 * `read(char[] cbuf)` : 从输入流中读取一些字符，并将它们存储到字符数组 `cbuf`中，等价于 `read(cbuf, 0, cbuf.length)` 。 * `read(char[] cbuf, int off, int len)`：在`read(char[] cbuf)` 方法的基础上增加了 `off` 参数（偏移量）和 `len` 参数（要读取的最大字符数）。 * `skip(long n)`：忽略输入流中的 n 个字符 ,返回实际忽略的字符数。 * `close()` : 关闭输入流并释放相关的系统资源。 `InputStreamReader` 是字节流转换为字符流的桥梁，其子类 `FileReader` 是基于该基础上的封装，可以直接操作字符文件。 **Writer（字符输出流）** `Writer`用于将数据（字符信息）写入到目的地（通常是文件），`java.io.Writer`抽象类是所有字符输出流的父类。 **常用方法** * `write(int c)` : 写入单个字符。 * `write(char[] cbuf)`：写入字符数组 `cbuf`，等价于`write(cbuf, 0, cbuf.length)`。 * `write(char[] cbuf, int off, int len)`：在`write(char[] cbuf)` 方法的基础上增加了 `off` 参数（偏移量）和 `len` 参数（要读取的最大字符数）。 * `write(String str)`：写入字符串，等价于 `write(str, 0, str.length())` 。 * `write(String str, int off, int len)`：在`write(String str)` 方法的基础上增加了 `off` 参数（偏移量）和 `len` 参数（要读取的最大字符数）。 * `append(CharSequence csq)`：将指定的字符序列附加到指定的 `Writer` 对象并返回该 `Writer` 对象。 * `append(char c)`：将指定的字符附加到指定的 `Writer` 对象并返回该 `Writer` 对象。 * `flush()`：刷新此输出流并强制写出所有缓冲的输出字符。 * `close()`:关闭输出流释放相关的系统资源。 `OutputStreamWriter` 是字符流转换为字节流的桥梁，其子类 `FileWriter` 是基于该基础上的封装，可以直接将字符写入到文件。 #### 字节缓冲流 IO 操作是很消耗性能的，缓冲流将数据加载至缓冲区，一次性读取/写入多个字节，从而避免频繁的 IO 操作，提高流的传输效率。 字节缓冲流这里采用了装饰器模式来增强 `InputStream` 和`OutputStream`子类对象的功能。 我们可以通过 `BufferedInputStream`（字节缓冲输入流）来增强 `FileInputStream` 的功能。 字节流和字节缓冲流的性能差别主要体现在我们使用两者的时候都是调用 `write(int b)` 和 `read()` 这两个一次只读取一个字节的方法的时候。由于字节缓冲流内部有缓冲区（字节数组），因此，字节缓冲流会先将读取到的字节存放在缓存区，大幅减少 IO 次数，提高读取效率。 **BufferedInputStream（字节缓冲输入流）** `BufferedInputStream` 从源头（通常是文件）读取数据（字节信息）到内存的过程中不会一个字节一个字节的读取，而是会先将读取到的字节存放在缓存区，并从内部缓冲区中单独读取字节。这样大幅减少了 IO 次数，提高了读取效率。 `BufferedInputStream` 内部维护了一个缓冲区，这个缓冲区实际就是一个字节数组。 **BufferedOutputStream（字节缓冲输出流）** `BufferedOutputStream` 将数据（字节信息）写入到目的地（通常是文件）的过程中不会一个字节一个字节的写入，而是会先将要写入的字节存放在缓存区，并从内部缓冲区中单独写入字节。这样大幅减少了 IO 次数，提高了读取效率 #### 字符缓冲流 `BufferedReader` （字符缓冲输入流）和 `BufferedWriter`（字符缓冲输出流）类似于 `BufferedInputStream`（字节缓冲输入流）和`BufferedOutputStream`（字节缓冲输入流），内部都维护了一个字节数组作为缓冲区。不过，前者主要是用来操作字符信息。 #### 打印流 `System.out` 实际是用于获取一个 `PrintStream` 对象，`print`方法实际调用的是 `PrintStream` 对象的 `write` 方法。 `PrintStream` 属于字节打印流，与之对应的是 `PrintWriter` （字符打印流）。`PrintStream` 是 `OutputStream` 的子类，`PrintWriter` 是 `Writer` 的子类。 #### 随机访问流 这里要介绍的随机访问流指的是支持随意跳转到文件的任意位置进行读写的 `RandomAccessFile` 。 `RandomAccessFile` 中有一个文件指针用来表示下一个将要被写入或者读取的字节所处的位置。我们可以通过 `RandomAccessFile` 的 `seek(long pos)` 方法来设置文件指针的偏移量（距文件开头 `pos` 个字节处）。 `RandomAccessFile` 比较常见的一个应用就是实现大文件的 **断点续传** 。何谓断点续传？简单来说就是上传文件中途暂停或失败（比如遇到网络问题）之后，不需要重新上传，只需要上传那些未成功上传的文件分片即可。分片（先将文件切分成多个文件分片）上传是断点续传的基础。 ### Java IO 设计模式 #### 装饰器模式 **装饰器（Decorator）模式** 可以在不改变原有对象的情况下拓展其功能。 装饰器模式通过组合替代继承来扩展原始类的功能，在一些继承关系比较复杂的场景（IO 这一场景各种类的继承关系就比较复杂）更加实用。 对于字节流来说， `FilterInputStream` （对应输入流）和`FilterOutputStream`（对应输出流）是装饰器模式的核心，分别用于增强 `InputStream` 和`OutputStream`子类对象的功能。 为了实现这一效果，装饰器类需要跟原始类继承相同的抽象类或者实现相同的接口。上面介绍到的这些 IO 相关的装饰类和原始类共同的父类是 `InputStream` 和`OutputStream`。 #### 适配器模式 **适配器（Adapter Pattern）模式** 主要用于接口互不兼容的类的协调工作。适配器模式中存在被适配的对象或者类称为 适配者(Adaptee) ，作用于适配者的对象或者类称为适配器(Adapter) 。适配器分为对象适配器和类适配器。类适配器使用继承关系来实现，对象适配器使用组合关系来实现。 IO 流中的字符流和字节流的接口不同，它们之间可以协调工作就是基于适配器模式来做的，更准确点来说是对象适配器。通过适配器，我们可以将字节流对象适配成一个字符流对象，这样我们可以直接通过字节流对象来读取或者写入字符数据。 `InputStreamReader` 和 `OutputStreamWriter` 就是两个适配器(Adapter)， 同时，它们两个也是字节流和字符流之间的桥梁。`InputStreamReader` 使用 `StreamDecoder` （流解码器）对字节进行解码，**实现字节流到字符流的转换，** `OutputStreamWriter` 使用`StreamEncoder`（流编码器）对字符进行编码，实现字符流到字节流的转换。 `InputStream` 和 `OutputStream` 的子类是被适配者， `InputStreamReader` 和 `OutputStreamWriter`是适配器。 **适配器模式和装饰器模式有什么区别呢？** **装饰器模式** 更侧重于动态地增强原始类的功能，装饰器类需要跟原始类继承相同的抽象类或者实现相同的接口。并且，装饰器模式支持对原始类嵌套使用多个装饰器。 **适配器模式** 更侧重于让接口不兼容而不能交互的类可以一起工作，当我们调用适配器对应的方法时，适配器内部会调用适配者类或者和适配类相关的类的方法，这个过程透明的。 适配器和适配者两者不需要继承相同的抽象类或者实现相同的接口。`FutureTask` 类使用了适配器模式，`Executors` 的内部类 `RunnableAdapter` 实现属于适配器，用于将 `Runnable` 适配成 `Callable`。 #### 工厂模式 工厂模式用于创建对象，NIO 中大量用到了工厂模式，比如 `Files` 类的 `newInputStream` 方法用于创建 `InputStream` 对象（静态工厂）。 #### 观察者模式 NIO 中的文件目录监听服务基于 `WatchService` 接口和 `Watchable` 接口。`WatchService` 属于观察者，`Watchable` 属于被观察者。 `Watchable` 接口定义了一个用于将对象注册到 `WatchService`（监控服务） 并绑定监听事件的方法 `register` 。 ### Java IO 模型 #### I/O **何为 I/O?** I/O（**I**nput/**O**utput） 即**输入／输出** 。根据冯.诺依曼结构，计算机结构分为 5 大部分：运算器、控制器、存储器、输入设备、输出设备。 **从应用程序的视角来看的话，我们的应用程序对操作系统的内核发起 IO 调用（系统调用），操作系统负责的内核执行具体的 IO 操作。也就是说，我们的应用程序实际上只是发起了 IO 操作的调用而已，具体 IO 的执行是由操作系统的内核来完成的**。当应用程序发起 I/O 调用后，会经历两个步骤： 1. 内核等待 I/O 设备准备好数据 2. 内核将数据从内核空间拷贝到用户空间。 **有哪些常见的 IO 模型?** UNIX 系统下， IO 模型一共有 5 种：**同步阻塞 I/O**、**同步非阻塞 I/O**、**I/O 多路复用**、**信号驱动 I/O** 和**异步 I/O**。 #### Java 中 3 种常见 IO 模型 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-2690af521b11f65b9b77ba45e49545fff364c822%2FPasted%20image%2020250221211225.png?alt=media) **BIO (Blocking I/O)** **BIO 属于同步阻塞 IO 模型** 。同步阻塞 IO 模型中，应用程序发起 read 调用后，会一直阻塞，直到内核把数据拷贝到用户空间。 **NIO (Non-blocking/New I/O)** Java 中的 NIO 于 Java 1.4 中引入，对应 `java.nio` 包，提供了 `Channel` , `Selector`，`Buffer` 等抽象。NIO 中的 N 可以理解为 Non-blocking，不单纯是 New。它是支持面向缓冲的，基于通道的 I/O 操作方法。对于高负载、高并发的（网络）应用，应使用 NIO 。 Java 中的 NIO 可以看作是 **I/O 多路复用模型**。也有很多人认为，Java 中的 NIO 属于同步非阻塞 IO 模型。 **同步非阻塞 IO 模型** ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-f1e420c9292a9df774c47cc1ee491e45dec067c4%2FPasted%20image%2020250221211545.png?alt=media) 同步非阻塞 IO 模型中，应用程序会一直发起 read 调用，等待数据从内核空间拷贝到用户空间的这段时间里，线程依然是阻塞的，直到在内核把数据拷贝到用户空间。 相比于同步阻塞 IO 模型，同步非阻塞 IO 模型确实有了很大改进。通过轮询操作，避免了一直阻塞。 但是，这种 IO 模型同样存在问题：**应用程序不断进行 I/O 系统调用轮询数据是否已经准备好的过程是十分消耗 CPU 资源的。** **I/O 多路复用模型** ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-edc13af72623134020202617ec67508dbe11ce60%2FPasted%20image%2020250221211749.png?alt=media) IO 多路复用模型中，线程首先发起 select 调用，询问内核数据是否准备就绪，等内核把数据准备好了，用户线程再发起 read 调用。read 调用的过程（数据从内核空间 -> 用户空间）还是阻塞的。 目前支持 IO 多路复用的系统调用，有 select，epoll 等等。select 系统调用，目前几乎在所有的操作系统上都有支持。 * **select 调用**：内核提供的系统调用，它支持一次查询多个系统调用的可用状态。几乎所有的操作系统都支持。 * **epoll 调用**：linux 2.6 内核，属于 select 调用的增强版本，优化了 IO 的执行效率。 **IO 多路复用模型，通过减少无效的系统调用，减少了对 CPU 资源的消耗。** ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-a5fffea0ac86ab49e322bccbddaa1fbef1098f4a%2FPasted%20image%2020250221211814.png?alt=media) Java 中的 NIO ，有一个非常重要的**选择器 ( Selector )** 的概念，也可以被称为 **多路复用器**。通过它，只需要一个线程便可以管理多个客户端连接。当客户端数据到了之后，才会为其服务。 **AIO (Asynchronous I/O)** AIO 也就是 NIO 2。Java 7 中引入了 NIO 的改进版 NIO 2，它是异步 IO 模型。异步 IO 是基于事件和回调机制实现的，也就是应用操作之后会直接返回，不会堵塞在那里，当后台处理完成，操作系统会通知相应的线程进行后续的操作。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-3aeb53e1f5a1b565a542cfbbc9838ae62187122a%2FPasted%20image%2020250221211211.png?alt=media) ### Java NIO #### NIO 简介 在传统的 Java I/O 模型（BIO）中，I/O 操作是以阻塞的方式进行的。也就是说，当一个线程执行一个 I/O 操作时，它会被阻塞直到操作完成。这种阻塞模型在处理多个并发连接时可能会导致性能瓶颈，因为需要为每个连接创建一个线程，而线程的创建和切换都是有开销的。 为了解决这个问题，在 Java1.4 版本引入了一种新的 I/O 模型 — **NIO** （New IO，也称为 Non-blocking IO） 。NIO 弥补了同步阻塞 I/O 的不足，它在标准 Java 代码中提供了非阻塞、面向缓冲、基于通道的 I/O，可以使用少量的线程来处理多个连接，大大提高了 I/O 效率和并发。 使用 NIO 并不一定意味着高性能，它的性能优势主要体现在高并发和高延迟的网络环境下。当连接数较少、并发程度较低或者网络传输速度较快时，NIO 的性能并不一定优于传统的 BIO 。 如果我们需要使用 NIO 构建网络程序的话，不建议直接使用原生 NIO，编程复杂且功能性太弱，推荐使用一些成熟的基于 NIO 的网络编程框架比如 Netty。Netty 在 NIO 的基础上进行了一些优化和扩展比如支持多种协议、支持 SSL/TLS 等等。 #### NIO 核心组件 * **Buffer（缓冲区）**：NIO 读写数据都是通过缓冲区进行操作的。读操作的时候将 Channel 中的数据填充到 Buffer 中，而写操作时将 Buffer 中的数据写入到 Channel 中。 * **Channel（通道）**：Channel 是一个双向的、可读可写的数据传输通道，NIO 通过 Channel 来实现数据的输入输出。通道是一个抽象的概念，它可以代表文件、套接字或者其他数据源之间的连接。 * **Selector（选择器）**：允许一个线程处理多个 Channel，基于事件驱动的 I/O 多路复用模型。所有的 Channel 都可以注册到 Selector 上，由 Selector 来分配线程来处理事件。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-a5fffea0ac86ab49e322bccbddaa1fbef1098f4a%2FPasted%20image%2020250221211954.png?alt=media) **Buffer（缓冲区）** 在传统的 BIO 中，数据的读写是面向流的， 分为字节流和字符流。 在 Java 1.4 的 NIO 库中，所有数据都是用缓冲区处理的，这是新库和之前的 BIO 的一个重要区别，有点类似于 BIO 中的缓冲流。NIO 在读取数据时，它是直接读到缓冲区中的。在写入数据时，写入到缓冲区中。 使用 NIO 在读写数据时，都是通过缓冲区进行操作。 Buffer 最核心的两个方法： 1. `get` : 读取缓冲区的数据 2. `put` ：向缓冲区写入数据 除上述两个方法之外，其他的重要方法： * `flip` ：将缓冲区从写模式切换到读模式，它会将 `limit` 的值设置为当前 `position` 的值，将 `position` 的值设置为 0。 * `clear`: 清空缓冲区，将缓冲区从读模式切换到写模式，并将 `position` 的值设置为 0，将 `limit` 的值设置为 `capacity` 的值。 **Channel（通道）** Channel 是一个通道，它建立了与数据源（如文件、网络套接字等）之间的连接。我们可以利用它来读取和写入数据，就像打开了一条自来水管，让数据在 Channel 中自由流动。 BIO 中的流是单向的，分为各种 `InputStream`（输入流）和 `OutputStream`（输出流），数据只是在一个方向上传输。通道与流的不同之处在于通道是双向的，它可以用于读、写或者同时用于读写。 Channel 与前面介绍的 Buffer 打交道，读操作的时候将 Channel 中的数据填充到 Buffer 中，而写操作时将 Buffer 中的数据写入到 Channel 中。 另外，因为 Channel 是全双工的，所以它可以比流更好地映射底层操作系统的 API。特别是在 UNIX 网络编程模型中，底层操作系统的通道都是全双工的，同时支持读写操作。 Channel 最核心的两个方法： 1. `read` ：读取数据并写入到 Buffer 中。 2. `write` ：将 Buffer 中的数据写入到 Channel 中。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-91373fe35f3e72a7ae4bc5be93aa546ab4acab5e%2FPasted%20image%2020250221212217.png?alt=media) **Selector（选择器）** Selector（选择器） 是 NIO 中的一个关键组件，它允许一个线程处理多个 Channel。Selector 是基于事件驱动的 I/O 多路复用模型，主要运作原理是：通过 Selector 注册通道的事件，Selector 会不断地轮询注册在其上的 Channel。当事件发生时，Selector 会将相关的 Channel 加入到就绪集合中。通过 SelectionKey 可以获取就绪 Channel 的集合，然后对这些就绪的 Channel 进行相应的 I/O 操作。 一个多路复用器 Selector 可以同时轮询多个 Channel，由于 JDK 使用了 `epoll()` 代替传统的 `select` 实现，所以它并没有最大连接句柄 `1024/2048` 的限制。这也就意味着只需要一个线程负责 Selector 的轮询，就可以接入成千上万的客户端。 `Selector`是抽象类，可以通过调用此类的 `open()` 静态方法来创建 Selector 实例。Selector 可以同时监控多个 `SelectableChannel` 的 `IO` 状况，是非阻塞 `IO` 的核心。 ![](https://932469815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHYGdK54G4HJCL6Pwrf5l%2Fuploads%2Fgit-blob-a1c41c35ba971881dbcfad077b881df42aebf16c%2FPasted%20image%2020250221212448.png?alt=media) #### NIO 零拷贝 零拷贝是提升 IO 操作性能的一个常用手段，像 ActiveMQ、Kafka 、RocketMQ、QMQ、Netty 等顶级开源项目都用到了零拷贝。 零拷贝是指计算机执行 IO 操作时，CPU 不需要将数据从一个存储区域复制到另一个存储区域，从而可以减少上下文切换以及 CPU 的拷贝时间。也就是说，零拷贝主要解决操作系统在处理 I/O 操作时频繁复制数据的问题。零拷贝的常见实现技术有： `mmap+write`、`sendfile`和 `sendfile + DMA gather copy` 。 可以看出，无论是传统的 I/O 方式，还是引入了零拷贝之后，2 次 DMA(Direct Memory Access) 拷贝是都少不了的。因为两次 DMA 都是依赖硬件完成的。零拷贝主要是减少了 CPU 拷贝及上下文的切换。 **Java 对零拷贝的支持** `MappedByteBuffer` 是 NIO 基于内存映射（`mmap`）这种零拷⻉⽅式的提供的⼀种实现，底层实际是调用了 Linux 内核的 `mmap` 系统调用。它可以将一个文件或者文件的一部分映射到内存中，形成一个虚拟内存文件，这样就可以直接操作内存中的数据，而不需要通过系统调用来读写文件。 `FileChannel` 的`transferTo()/transferFrom()`是 NIO 基于发送文件（`sendfile`）这种零拷贝方式的提供的一种实现，底层实际是调用了 Linux 内核的 `sendfile`系统调用。它可以直接将文件数据从磁盘发送到网络，而不需要经过用户空间的缓冲区。