猿辅导Java后台开发面试题及参考答案

int 与 Integer 的区别是什么？若创建数量庞大的数字时使用 Integer，会对重复数字创建新对象吗？

int 是 Java 中的基本数据类型，直接存储数值，占用 4 个字节，默认值为 0，不需要通过 new 关键字创建，也不具备对象的特性，不能调用方法。而 Integer 是 int 的包装类，属于引用数据类型，存储的是对象的引用（地址），默认值为 null，需要通过 new 关键字或自动装箱创建，具备对象的特性，可以调用诸如 intValue()、compareTo() 等方法。

从使用场景来看，int 适用于简单的数值运算、局部变量等场景，因为它在内存占用和访问效率上更有优势；Integer 则适用于需要对象特性的场景，比如作为集合（如 ArrayList<Integer>）的元素、泛型参数、反射调用等，因为集合和泛型不能直接使用基本数据类型。

关于创建数量庞大的数字时 Integer 是否对重复数字创建新对象，这涉及到 Integer 的缓存机制。Java 为了提高性能和减少内存占用，在 Integer 类中实现了一个缓存机制（IntegerCache），默认缓存了从 -128 到 127 之间的整数对象。当使用自动装箱（如 Integer i = 100）或 valueOf() 方法创建这个范围内的 Integer 对象时，会直接从缓存中获取已存在的对象，而不会创建新对象；当数值超出这个范围时，会创建新的 Integer 对象。例如：

Integer a = 100;
Integer b = 100;
System.out.println(a == b); // 输出 true，因为从缓存获取

Integer c = 200;
Integer d = 200;
System.out.println(c == d); // 输出 false，因为创建了新对象

不过，这个缓存范围的上限（127）可以通过 JVM 参数 -XX:AutoBoxCacheMax=<size> 进行调整，但下限（-128）是固定的。

面试关键点：基本数据类型与包装类的本质区别、自动装箱/拆箱的原理、Integer 缓存机制的范围和应用场景。

记忆法：可以通过"基值引对，缓存区间"来记忆，"基值"指 int 是基本数据类型存储数值，"引对"指 Integer 是引用类型存储对象引用，"缓存区间"则记住 -128 到 127 这个核心范围。

String、StringBuilder、StringBuffer 的区别是什么？为什么阿里巴巴编程规约中不建议在 for 循环体里写str += "a"这种代码？

String、StringBuilder、StringBuffer 都是 Java 中用于处理字符串的类，但它们在可变性、线程安全性和性能上有显著区别。

String 是不可变的（immutable），其底层是一个被 final 修饰的 char 数组（JDK 9 及以上改为 byte 数组），这意味着一旦创建 String 对象，其内容就无法修改。每次对 String 进行拼接、截取等操作时，都会创建新的 String 对象，原对象不会改变。这种特性使得 String 适合存储不常修改的字符串，但频繁修改时会产生大量无用对象，影响性能和内存。

StringBuilder 是可变的（mutable），底层也是一个 char 数组（或 byte 数组），但没有被 final 修饰，其内部提供了 append()、insert() 等方法直接修改数组内容，不会创建新对象。它不具备线程安全特性，多个线程同时操作时可能出现数据不一致的问题，但由于避免了同步开销，执行效率较高，适合单线程环境下频繁修改字符串的场景。

StringBuffer 同样是可变的，功能与 StringBuilder 基本一致，但它的所有方法都被 synchronized 修饰，具备线程安全特性。不过，同步机制会带来额外的性能开销，因此效率低于 StringBuilder，适合多线程环境下需要修改字符串的场景。

阿里巴巴编程规约不建议在 for 循环体里写 str += "a" 这种代码，核心原因与 String 的不可变性有关。在循环中使用 += 拼接字符串时，每次拼接都会创建一个新的 String 对象，循环次数越多，产生的无用对象就越多，不仅会占用大量内存，还会增加垃圾回收的负担，严重影响程序性能。例如，一个循环 1000 次的拼接操作，会创建 1000 个左右的 String 对象。

而如果使用 StringBuilder，通过 append() 方法进行拼接，整个过程只会创建一个 StringBuilder 对象，所有修改都在该对象内部完成，能显著提升性能。示例如下：

// 不推荐的写法
String str = "";
for (int i = 0; i < 1000; i++) {
    str += "a"; // 每次都会创建新的String对象
}

// 推荐的写法
StringBuilder sb = new StringBuilder();
for (int i = 0; i < 1000; i++) {
    sb.append("a"); // 仅在一个对象上操作
}
String result = sb.toString();

面试关键点：三者的可变性、线程安全性对比；String 不可变性的底层原因；循环中字符串拼接的性能问题及优化方案。

记忆法：可以用"String 不变，Build 快不安全，Buffer 慢但安全，循环拼接用 Build"来记忆，既区分了三者的核心特性，也记住了循环中的最佳实践。

Java 的 4 个访问修饰符（public、protected、default、private）的作用是什么？类可以使用哪些访问修饰符？为什么？

Java 中的 4 个访问修饰符用于控制类、方法、字段等成员的访问权限，从权限由大到小依次为 public、protected、default（缺省，即不写修饰符）、private，具体作用如下：

public：具有最大的访问权限，被其修饰的成员可以在任何地方被访问，无论是否在同一个类、同一个包或不同包中。例如，一个 public 修饰的类，其所有 public 成员在项目的任何类中都可直接访问。

protected：被修饰的成员可以在本类、同一个包中的其他类，以及不同包中的子类中访问。需要注意的是，不同包中的非子类无法访问 protected 成员。例如，类 A 有一个 protected 方法，包外的类 B 继承了 A，则 B 可以访问 A 的该方法，但包外的非子类 C 不能访问。

default（缺省）：当成员没有显式指定访问修饰符时，默认使用该权限。被修饰的成员只能在本类和同一个包中的其他类中访问，不同包中的类（包括子类）都无法访问。

private：具有最小的访问权限，被修饰的成员只能在当前类内部被访问，同一个包中的其他类、不同包的类（包括子类）都无法直接访问。通常用于封装类的私有字段，通过 public 的 getter/setter 方法间接访问，以保证数据的安全性。

关于类可以使用的访问修饰符，只有 public 和 default 两种。这是因为类的访问修饰符需要考虑类的可见范围：

• public 修饰的类可以被项目中所有的类访问，适合作为对外提供功能的接口或公共类。
• default 修饰的类（即缺省）只能被同一个包中的类访问，适合作为包内部的辅助类，对外隐藏实现细节。

而 protected 和 private 不能用于修饰类，原因如下：protected 的设计初衷是允许子类访问父类的成员，若用于修饰类，在不同包中只有子类可访问，但类的继承关系并不能限制类本身的可见性，逻辑上不成立；private 修饰的类只能在自身内部被访问，而类本身需要被其他类引用才能发挥作用，private 会导致类无法被外部使用，失去了存在的意义。

面试关键点：4 个访问修饰符的权限范围对比；类与类成员在访问修饰符使用上的区别及原因；访问修饰符在封装和代码安全性中的作用。

记忆法：可以通过"公全保包子，缺省同包友，私有仅自身；类修饰，公缺省，保护私有不可用"来记忆，前半句描述 4 个修饰符的权限范围，后半句明确类的可用修饰符及原因。

Object 类中包含哪些常用方法？

Object 类是 Java 中所有类的根类，任何类都直接或间接继承自 Object 类，因此它包含的方法是所有 Java 对象都具备的基础功能，常用方法如下：

getClass()：返回当前对象的运行时类（Class 对象）。该方法是 final 修饰的，无法被重写。通过它可以获取对象的类信息，如类名、父类、实现的接口等，常用于反射机制。例如：obj.getClass().getName() 可获取对象所属类的全限定名。

hashCode()：返回对象的哈希码值（int 类型）。哈希码通常用于哈希表（如 HashMap、HashSet）中，作为对象的存储索引，提高查找效率。默认实现是根据对象的内存地址计算的，但子类可以重写该方法，通常与 equals() 方法一起重写，以保证"相等的对象必须有相等的哈希码"。

equals(Object obj)：判断当前对象与参数 obj 是否"相等"。默认实现是 return (this == obj)，即比较两个对象的内存地址（引用是否相同）。但实际业务中，通常需要重写该方法来定义对象的逻辑相等（如两个对象的属性值相同则认为相等），重写时需遵循自反性、对称性、传递性等规则。

clone()：创建并返回当前对象的一个副本（克隆对象）。该方法是 protected 修饰的，子类若要使用需重写并改为 public 修饰，且类需实现 Cloneable 接口（否则会抛出 CloneNotSupportedException）。克隆分为浅克隆和深克隆，默认是浅克隆（仅复制对象本身及基本类型字段，引用类型字段仍指向原对象）。

toString()：返回对象的字符串表示形式。默认实现是 getClass().getName() + "@" + Integer.toHexString(hashCode())，即类名@哈希码的十六进制形式。实际开发中通常重写该方法，返回对象的关键属性信息，方便日志打印和调试。

notify()：唤醒在此对象的监视器上等待的单个线程。若有多个线程等待，随机选择一个唤醒，该线程需重新获取对象的锁才能继续执行。

notifyAll()：唤醒在此对象的监视器上等待的所有线程，这些线程会竞争获取对象的锁，最终只有一个线程能获得锁并继续执行，其他线程继续等待。

wait()：使当前线程进入等待状态，释放对象的锁，并在其他线程调用该对象的 notify() 或 notifyAll() 方法时被唤醒，或等待指定时间后自动唤醒。该方法有三个重载版本：wait()（无限期等待）、wait(long timeout)（等待指定毫秒数）、wait(long timeout, int nanos)（更精确的等待时间）。

finalize()：当垃圾回收器确定对象不再被引用时，会调用该方法进行资源清理。但该方法的执行时间不确定，且 Java 9 及以上已标记为过时（deprecated），不推荐使用，通常用 try-with-resources 或显式的 close() 方法替代。

面试关键点：各方法的功能和使用场景；hashCode() 与 equals() 的关系；clone() 的克隆机制；wait() 与 notify()/notifyAll() 在多线程通信中的作用。

记忆法：可以用"类信 getClass，哈希 equals 辨，克隆 clone 制副本，toString 显信息，notify 唤醒 wait 眠，finalize 回收前"来记忆，每句对应一个核心方法的功能，便于快速联想。

Object 类中的 equals () 和 hashCode () 默认实现是什么？重写 equals () 但不重写 hashCode () 会有什么问题？

Object 类中 equals() 方法的默认实现是比较两个对象的引用是否相同，即判断两个对象是否指向同一块内存地址，其源码大致为：public boolean equals(Object obj) { return (this == obj); }。这里的 == 对于基本数据类型是比较值，对于引用数据类型就是比较内存地址。

hashCode() 方法的默认实现是根据对象的内存地址计算出一个整数哈希码值，源码通常通过本地方法（native method）实现，如 public native int hashCode();。这意味着不同内存地址的对象，其默认哈希码一般不同；同一对象（内存地址不变）的哈希码始终相同。

在 Java 中，hashCode() 和 equals() 存在一个重要的约定：如果两个对象通过 equals() 方法判断为相等（返回 true），那么它们的 hashCode() 方法必须返回相同的哈希码；反之，两个对象的 hashCode() 返回相同的哈希码，它们的 equals() 不一定返回 true（哈希冲突允许存在）。

若重写了 equals() 但没有重写 hashCode()，会违反上述约定，引发一系列问题，尤其是在使用哈希表（如 HashMap、HashSet、HashTable 等）时：

当两个对象通过重写的 equals() 方法判断为相等时，由于未重写 hashCode()，它们的默认哈希码可能不同（因为内存地址不同）。在 HashMap 中，对象的存储位置由 hashCode() 计算的哈希值决定，这会导致两个相等的对象被存入不同的桶中。此时，当使用 containsKey() 或 contains() 等方法查找对象时，可能无法找到预期的对象，因为哈希表会先根据 hashCode() 定位桶，再在桶内通过 equals() 比较，而两个相等的对象可能在不同的桶中，导致查找失败。

例如：

class Person {
    private String name;

    public Person(String name) {
        this.name = name;
    }

    // 重写equals()，认为name相同则对象相等
    @Override
    public boolean equals(Object obj) {
        if (this == obj) return true;
        if (obj == null || getClass() != obj.getClass()) return false;
        Person person = (Person) obj;
        return name.equals(person.name);
    }

    // 未重写hashCode()
}

public class Test {
    public static void main(String[] args) {
        Person p1 = new Person("Alice");
        Person p2 = new Person("Alice");

        System.out.println(p1.equals(p2)); // 输出true，认为相等

        HashMap<Person, Integer> map = new HashMap<>();
        map.put(p1, 1);
        System.out.println(map.get(p2)); // 输出null，因为p1和p2哈希码不同，get(p2)找不到
    }
}

上述代码中，p1 和 p2 通过 equals() 判断为相等，但由于未重写 hashCode()，它们的哈希码不同，导致 p2 无法从 HashMap 中获取到 p1 存入的值，违背了哈希表的设计逻辑。

面试关键点：equals() 和 hashCode() 的默认实现逻辑；两者的约定关系；未同时重写时在哈希表中的问题；重写时的最佳实践（如基于相同字段计算哈希码）。

记忆法：可以用"默认 equals 比地址，hashCode 随地址；重写 equals 必重写 hashCode，否则哈希表找不着"来记忆，突出两者的关联和不同步重写的后果。

final 关键字和 finally 关键字的区别是什么？

final 和 finally 是 Java 中功能完全不同的关键字，主要区别体现在作用、使用场景和语法上。

final 关键字用于限制程序元素的可变性，可修饰类、方法和变量，分别产生不同的约束：修饰类时，该类不能被继承（如 String 类被 final 修饰，无法创建其子类）；修饰方法时，该方法不能被子类重写（可防止方法实现被篡改）；修饰变量时，变量一旦被赋值就不能再修改（对于基本类型，值不可变；对于引用类型，引用地址不可变，但对象内容可修改）。例如：

// final修饰类，不可继承
final class FinalClass {}

// final修饰方法，不可重写
class Parent {
    final void finalMethod() {}
}
class Child extends Parent {
    // 编译错误，无法重写final方法
    // void finalMethod() {}
}

// final修饰变量，不可修改
class Test {
    final int num = 10;
    void changeNum() {
        // 编译错误，无法修改final变量
        // num = 20;
    }
}

finally 关键字仅用于异常处理机制，与 try 语句块配合使用，用于定义无论是否发生异常都必须执行的代码块。通常用于释放资源（如关闭文件流、数据库连接等），确保资源不会因异常而泄漏。例如：

FileInputStream fis = null;
try {
    fis = new FileInputStream("file.txt");
    // 读取文件操作
} catch (IOException e) {
    e.printStackTrace();
} finally {
    // 无论是否发生异常，都关闭流
    if (fis != null) {
        try {
            fis.close();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

需要注意，finally 唯一不执行的情况是在 try 或 catch 块中调用了 System.exit(0)（终止虚拟机），此时程序直接退出，finally 块不会执行。

面试关键点：final 对类、方法、变量的不同约束；finally 在异常处理中的作用及执行时机；两者在语法和功能上的本质区别。

记忆法：可通过"final 定不可变，类不继、法不重、量不改；finally 保执行，资源释放离不了"来记忆，清晰区分两者的核心特性。

Java 的异常体系结构是怎样的？项目中如何使用异常？受检异常和非受检异常的区别是什么？（举例：运行时异常如 NullPointerException，非运行时异常如 IOException）

Java 的异常体系以 Throwable 为根类，所有异常和错误都直接或间接继承自该类，体系结构可分为两大分支：

一是 Error，代表程序无法处理的严重错误，通常由 JVM 抛出，如 OutOfMemoryError（内存溢出）、StackOverflowError（栈溢出）等。这类错误发生时，程序一般会终止，开发者无需捕获或处理，因为通常无法通过代码修复。

二是 Exception，代表程序可以处理的异常，是开发者需要关注的核心。Exception 又分为两类：受检异常（Checked Exception）和非受检异常（Unchecked Exception）。

受检异常是指除 RuntimeException 及其子类之外的 Exception 子类（如 IOException、SQLException 等）。编译器会强制要求开发者处理这类异常，要么通过 try-catch 块捕获，要么在方法上用 throws 声明抛出，否则编译不通过。例如，读取文件时可能抛出的 IOException 就是受检异常，必须显式处理。

非受检异常即 RuntimeException 及其子类（如 NullPointerException、IndexOutOfBoundsException、IllegalArgumentException 等）。这类异常通常由程序逻辑错误导致，编译器不强制要求处理，开发者可根据需要选择捕获或抛出。例如，调用 null 对象的方法会抛出 NullPointerException，属于非受检异常。

项目中使用异常需遵循以下原则：避免滥用异常（不应用异常控制正常流程）；具体明确（捕获特定异常而非笼统的 Exception）；不吞异常（避免空的 catch 块，至少记录日志）；传递有意义的信息（异常信息应清晰描述错误原因）；资源释放放在 finally 或使用 try-with-resources。例如：

// 合理使用异常示例
public String readFile(String path) throws IOException { // 声明受检异常
    try (BufferedReader br = new BufferedReader(new FileReader(path))) { // try-with-resources自动释放资源
        return br.readLine();
    } catch (FileNotFoundException e) { // 捕获特定异常
        log.error("文件未找到: {}", path, e); // 记录日志
        throw new RuntimeException("读取文件失败: 文件不存在", e); // 包装异常并抛出
    }
}

受检异常和非受检异常的核心区别：受检异常在编译期检查，必须显式处理；非受检异常在运行期发生，编译期不强制处理。前者通常与外部资源交互相关（如 IO、数据库操作），后者多与程序逻辑错误相关（如空指针、数组越界）。

面试关键点：异常体系的层级结构；Error 与 Exception 的区别；受检与非受检异常的判断标准及处理差异；项目中异常处理的最佳实践。

记忆法：可通过"Throwable 为根，Error 严重 Exception 可处理；受检编译必处理，非受运行逻辑错"来记忆，快速梳理体系和核心区别。

什么是 Java 反射机制？框架中哪些地方用到了反射？

Java 反射机制是指程序在运行时可以动态获取类的信息（如类名、父类、接口、方法、字段等），并能动态调用类的方法、访问或修改字段的能力。这种动态性打破了编译期的类型约束，允许程序在运行时操作未知类型的对象。

反射的实现依赖于 Java 提供的 java.lang.reflect 包，核心类包括：Class（代表类的字节码对象，是反射的入口）、Method（代表类的方法）、Field（代表类的字段）、Constructor（代表类的构造方法）等。通过这些类，可完成反射的核心操作：获取 Class 对象（如 Class.forName("com.example.User")、user.getClass()、User.class）；获取类的成员（如 getMethods() 获取所有公共方法、getDeclaredFields() 获取所有字段）；调用方法（如 method.invoke(obj, args)）；访问或修改字段（如 field.set(obj, value)）。

例如，通过反射创建对象并调用方法：

class User {
    private String name;
    public User(String name) {
        this.name = name;
    }
    public void sayHello() {
        System.out.println("Hello, " + name);
    }
}

public class ReflectionDemo {
    public static void main(String[] args) throws Exception {
        // 获取Class对象
        Class<?> userClass = Class.forName("User");
        // 获取构造方法并创建对象
        Constructor<?> constructor = userClass.getConstructor(String.class);
        Object user = constructor.newInstance("Alice");
        // 获取方法并调用
        Method sayHelloMethod = userClass.getMethod("sayHello");
        sayHelloMethod.invoke(user); // 输出：Hello, Alice
    }
}

反射在众多框架中被广泛使用，是框架实现灵活性和动态性的核心技术：

Spring 框架的 IOC（控制反转）容器通过反射创建对象：当 Spring 启动时，解析配置文件或注解（如 @Component），获取类的全限定名，通过 Class.forName() 加载类，再用反射调用构造方法创建对象，存入容器中管理。

MyBatis 框架的 SQL 映射：MyBatis 解析 Mapper 接口和 XML 配置后，通过反射动态生成接口的代理对象；在结果集映射时，使用反射将数据库字段值设置到 Java 对象的对应字段中。

JUnit 测试框架：如 @Test 注解，JUnit 运行时通过反射扫描类中带有 @Test 的方法，并动态调用这些方法执行测试。

注解处理器：许多框架（如 Lombok、Spring Boot）通过反射解析类、方法上的注解（如 @Data、@Controller），根据注解信息生成代码或执行特定逻辑。

面试关键点：反射的定义和核心类；反射的基本操作（获取 Class 对象、调用方法等）；反射在主流框架中的具体应用；反射的优缺点（灵活性高但性能略低、破坏封装性）。

记忆法：可通过"反射运行时，探类获信息，调方法改属性，框架动态靠它起"来记忆，概括反射的核心能力和应用场景。

什么是 Java 泛型？泛型擦除是什么意思？List<int> list = new ArrayList()这种写法有什么问题？

Java 泛型是 JDK 5 引入的特性，允许在定义类、接口、方法时指定类型参数（即参数化类型），使代码能操作多种数据类型而无需重复编写，同时在编译期提供类型安全检查，避免运行时的 ClassCastException。

泛型的核心作用是"参数化类型"，例如定义泛型类：

// 泛型类，T为类型参数
class Box<T> {
    private T value;
    public T getValue() { return value; }
    public void setValue(T value) { this.value = value; }
}

// 使用时指定具体类型
Box<String> stringBox = new Box<>();
stringBox.setValue("Hello");
String str = stringBox.getValue(); // 无需强制转换，编译期检查类型

泛型擦除是指 Java 泛型仅在编译期有效，编译后字节码中会移除泛型的类型参数信息，替换为原始类型（即泛型类定义时的上限类型，若无上限则为 Object）。例如，编译后的 Box<String> 和 Box<Integer> 都会被擦除为 Box（原始类型），这是因为 Java 为了兼容泛型引入前的代码而采用的"伪泛型"实现。

泛型擦除会导致一些现象：运行时无法获取泛型的具体类型（如 list.getClass() == ArrayList.class，无论泛型参数是什么）；泛型数组创建受限（如 new T[] 不允许，需强制转换）；静态方法中不能使用类的泛型参数（因为静态成员属于类，而泛型参数与实例相关）。

List<int> list = new ArrayList() 这种写法存在两个问题：

一是泛型参数不支持基本数据类型。Java 泛型的类型参数必须是引用类型（如 Integer、String），而 int 是基本数据类型，无法作为泛型参数。这是因为泛型擦除后会使用 Object 或上限类型存储数据，而基本数据类型不继承自 Object，无法直接存储，需通过包装类（如 Integer）实现。正确写法应为 List<Integer> list = new ArrayList<>()。

二是未使用菱形语法（Diamond Operator），虽然在 JDK 7 及以上允许右侧省略泛型参数（即 new ArrayList<>()），但左侧声明了泛型而右侧未明确时，仍能编译通过（兼容旧代码），但可能失去部分类型安全检查。更规范的写法是两侧保持一致，即 List<Integer> list = new ArrayList<>()。

面试关键点：泛型的定义和作用；泛型擦除的概念及影响；泛型对基本数据类型的限制；泛型在集合、方法中的应用。

记忆法：可通过"泛型参数化，编译保安全；擦除去类型，基本不用包装换"来记忆，涵盖泛型的核心特性和常见问题。

什么是 Java 注解？注解有哪些常见用途？

Java 注解（Annotation）是 JDK 5 引入的一种特殊标记，用于为代码（类、方法、字段等）提供元数据（描述数据的数据）。注解本身不直接影响代码的执行逻辑，但可通过工具（编译器、框架等）在编译期或运行时解析这些元数据，从而实现特定功能。

注解的定义与接口类似，需使用 @interface 关键字，可包含成员变量（以方法形式声明），并可通过元注解（修饰注解的注解）指定其保留策略、适用目标等。常见的元注解包括：

• @Retention：指定注解的保留阶段，有 SOURCE（仅编译期保留，如 @Override）、CLASS（编译期保留到字节码，默认）、RUNTIME（保留到运行时，可通过反射获取，如 @Controller）。
• @Target：指定注解可修饰的元素（如 TYPE 用于类、METHOD 用于方法、FIELD 用于字段等）。
• @Inherited：允许子类继承父类的注解。
• @Documented：注解会被包含在 Javadoc 文档中。

例如，定义一个简单的注解：

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface Log {
    String value() default "操作日志"; // 注解成员，默认值为"操作日志"
}

注解的常见用途包括：

1. 编译期检查与提示：编译器可通过注解检测代码错误或提供提示。例如 @Override 用于标记方法重写父类方法，若方法签名与父类不一致，编译器会报错；@Deprecated 标记过时的类或方法，使用时编译器会警告。

2. 框架配置与依赖注入：主流框架（如 Spring、Spring Boot）大量使用注解简化配置。例如 @Controller 标记控制器类，@Service 标记服务类，Spring 会自动扫描并管理这些类的实例；@Autowired 实现依赖注入，自动装配所需对象。

3. 生成文档与代码：通过注解可生成 Javadoc 文档（如 @param、@return 描述方法参数和返回值），或通过工具（如 Lombok）根据注解生成代码（如 @Data 自动生成 getter、setter、toString 等方法）。

4. 测试框架标记：测试框架（如 JUnit）用注解标记测试方法。例如 JUnit 的 @Test 标记测试方法，框架运行时会自动执行这些方法；@BeforeEach 标记测试前的初始化方法。

5. 运行时动态处理：通过反射在运行时解析注解，执行特定逻辑。例如自定义 @Log 注解，结合 AOP 实现方法调用日志的自动记录，无需手动编写日志代码。

面试关键点：注解的定义和元注解的作用；注解的保留策略；注解在编译期和运行时的应用场景；常见内置注解和框架注解的示例。

记忆法：可通过"注解是标签，元数据来带；编译查错误，框架配依赖，文档代码生，测试运行改"来记忆，涵盖注解的本质和主要用途。

对面向对象的理解是什么？（围绕封装、继承、多态等核心特性说明）

面向对象是一种以"对象"为核心的编程范式，通过抽象现实世界中的实体及其关系，将数据和操作数据的方法封装在一起，强调"做什么"而非"怎么做"，核心特性包括封装、继承和多态，它们相互配合实现代码的复用、扩展和维护性。

封装是面向对象的基础，指将对象的属性（数据）和方法（操作）捆绑在一起，隐藏内部实现细节，仅通过公共接口与外部交互。通过访问修饰符（private、protected、public等）控制属性和方法的可见性，例如将类的字段设为private，仅允许通过public的getter/setter方法访问或修改，确保数据的安全性和一致性。例如：

class Person {
    private String name; // 私有字段，外部无法直接访问
    private int age;

    // 公共方法，提供访问接口
    public String getName() { return name; }
    public void setName(String name) {
        if (name != null && !name.isEmpty()) { // 加入校验逻辑
            this.name = name;
        }
    }
}

继承是指子类通过extends关键字继承父类的属性和方法，实现代码复用，同时子类可新增特性或重写父类方法以适应自身需求。继承体现"is-a"关系（如"学生是一种人"），但需避免过度继承导致的耦合性过高。例如：

class Animal {
    void eat() { System.out.println("动物进食"); }
}
class Dog extends Animal {
    @Override // 重写父类方法
    void eat() { System.out.println("狗吃骨头"); }
    void bark() { System.out.println("狗叫"); } // 新增方法
}

多态是指同一行为（方法调用）在不同对象上有不同实现，通过"父类引用指向子类对象"实现。多态允许程序在运行时根据实际对象类型动态调用对应方法，提高代码的灵活性和扩展性。多态的实现依赖于继承（或接口实现）和方法重写，例如：

Animal animal = new Dog(); // 父类引用指向子类对象
animal.eat(); // 运行时调用Dog的eat()，输出"狗吃骨头"

此外，面向对象还包括抽象（通过抽象类和接口定义规范，不关注具体实现）、组合（"has-a"关系，如"汽车有发动机"，比继承更灵活）等思想。这些特性共同作用，使代码更贴近现实逻辑、易于维护和扩展，是大型软件开发的主流范式。

面试关键点：封装的实现方式及意义；继承的优缺点和适用场景；多态的实现原理（动态绑定）及实际价值；抽象与组合在面向对象中的作用。

记忆法：可通过"封装藏细节，继承复用加扩展，多态同调异实现，抽象定规范"来记忆，概括核心特性的本质和关系。

什么是 Java 的单例模式？常见的单例模式实现方式有哪些？

Java的单例模式是一种创建型设计模式，确保一个类在整个应用中只有一个实例，并提供一个全局访问点，避免频繁创建对象导致的资源浪费（如配置类、工具类、线程池等场景）。单例模式的核心是限制类的实例化次数，通常通过私有构造方法防止外部创建对象，再提供静态方法返回唯一实例。

常见的单例模式实现方式及特点如下：

1. 饿汉式：类加载时就创建实例，天然线程安全，但可能提前占用资源。

   public class Singleton {
   // 类加载时初始化实例
   private static final Singleton INSTANCE = new Singleton();
   // 私有构造方法，防止外部实例化
   private Singleton() {}
   // 全局访问点
   public static Singleton getInstance() {
   return INSTANCE;
   }
   }

2. 懒汉式（线程不安全）：延迟初始化，第一次调用时创建实例，但多线程环境下可能创建多个实例，仅适用于单线程。

   public class Singleton {
   private static Singleton instance;
   private Singleton() {}
   // 线程不安全，多线程同时调用可能创建多个实例
   public static Singleton getInstance() {
   if (instance == null) {
   instance = new Singleton();
   }
   return instance;
   }
   }

3. 懒汉式（线程安全，同步方法）：通过synchronized修饰getInstance()方法保证线程安全，但每次调用都加锁，性能较差。

   public static synchronized Singleton getInstance() {
   if (instance == null) {
   instance = new Singleton();
   }
   return instance;
   }

4. 双重检查锁（DCL）：优化同步效率，仅在实例未创建时加锁，且使用volatile防止指令重排序导致的半初始化问题，兼顾懒加载和线程安全。

   public class Singleton {
   // volatile防止指令重排序
   private static volatile Singleton instance;
   private Singleton() {}
   public static Singleton getInstance() {
   if (instance == null) { // 第一次检查，避免频繁加锁
   synchronized (Singleton.class) {
   if (instance == null) { // 第二次检查，防止多线程同时通过第一次检查
   instance = new Singleton();
   }
   }
   }
   return instance;
   }
   }

5. 静态内部类：利用类加载机制实现懒加载和线程安全（静态内部类仅在被调用时加载），性能优，是推荐的实现方式。

   public class Singleton {
   private Singleton() {}
   // 静态内部类，仅在getInstance()调用时加载
   private static class SingletonHolder {
   private static final Singleton INSTANCE = new Singleton();
   }
   public static Singleton getInstance() {
   return SingletonHolder.INSTANCE;
   }
   }

6. 枚举：天然防止反射和序列化破坏单例（枚举的构造方法由JVM控制，无法通过反射实例化），实现简单且绝对安全。

   public enum Singleton {
   INSTANCE; // 唯一实例
   // 枚举中可定义方法
   public void doSomething() {}
   }

面试关键点：各实现方式的线程安全性、懒加载特性、性能差异；防止反射和序列化破坏单例的方法；不同场景下的选择（如简单场景用饿汉式，需懒加载用静态内部类或DCL，安全性优先用枚举）。

记忆法：可通过"饿汉加载早安全，懒汉懒加载需同步，双重检查锁效率高，静态内部类推荐，枚举防破坏最佳"来记忆，快速区分各实现的核心特点。

Java 中的 BIO、NIO、AIO 分别是什么？它们的区别和应用场景是什么？

Java中的BIO、NIO、AIO是三种IO模型，分别对应阻塞IO、非阻塞IO、异步IO，核心区别在于处理IO操作时的阻塞特性和线程使用方式，适用于不同的并发场景。

BIO（Blocking IO，阻塞IO）是Java最早的IO模型，基于流（InputStream/OutputStream）操作，特点是"同步阻塞"：当线程执行read()或write()操作时，若数据未准备好（如网络数据未到达），线程会被阻塞，直到操作完成才继续执行。每个连接需要一个独立线程处理，若并发量大，会创建大量线程，导致CPU和内存资源耗尽，性能低下。例如传统的Socket编程：

// BIO示例：一个线程处理一个连接
ServerSocket serverSocket = new ServerSocket(8080);
while (true) {
    Socket socket = serverSocket.accept(); // 阻塞，等待连接
    new Thread(() -> {
        try (InputStream in = socket.getInputStream()) {
            byte[] buffer = new byte[1024];
            in.read(buffer); // 阻塞，等待数据
        } catch (IOException e) {
            e.printStackTrace();
        }
    }).start();
}

NIO（Non-blocking IO，非阻塞IO）是JDK 1.4引入的IO模型，基于通道（Channel）和缓冲区（Buffer），核心是"同步非阻塞"：通过Selector（多路复用器）管理多个通道，一个线程可处理多个连接。当通道上的IO操作未就绪时，线程不会阻塞，可处理其他通道；当操作就绪时，Selector通知线程处理。NIO避免了大量线程创建，适合高并发场景，核心组件包括：

• Channel：双向通道（如SocketChannel、ServerSocketChannel），可读写数据。

• Buffer：数据容器（如ByteBuffer），通道的数据需通过缓冲区传输。

• Selector：监听通道的事件（如连接就绪、读就绪、写就绪），实现多路复用。

  // NIO核心流程示意
  Selector selector = Selector.open();
  ServerSocketChannel serverChannel = ServerSocketChannel.open();
  serverChannel.configureBlocking(false); // 设置非阻塞
  serverChannel.register(selector, SelectionKey.OP_ACCEPT); // 注册接受连接事件

  while (true) {
  selector.select(); // 阻塞，等待事件就绪（可设置超时）
  Set<SelectionKey> keys = selector.selectedKeys();
  for (SelectionKey key : keys) {
  if (key.isAcceptable()) {
  // 处理新连接
  } else if (key.isReadable()) {
  // 处理读操作
  }
  keys.remove(key);
  }
  }

AIO（Asynchronous IO，异步IO）是JDK 1.7引入的IO模型，基于"异步非阻塞"：线程发起IO操作后立即返回，无需等待操作完成；当IO操作完成（或失败）时，系统通过回调函数通知线程处理结果，全程不阻塞线程。AIO更适合IO密集型场景，尤其是对响应时间要求不高的大文件操作。

三者的核心区别：

• 阻塞性：BIO是阻塞的，NIO在Selector.select()时可能阻塞但可设置超时，AIO全程非阻塞。
• 线程效率：BIO一个连接一个线程，效率低；NIO一个线程处理多个连接，效率高；AIO依赖回调，线程利用率最高。
• 编程复杂度：BIO简单直接，NIO需理解Selector和通道，AIO基于Future和回调，复杂度最高。

应用场景：BIO适用于连接数少、数据传输快的场景（如简单的内部服务）；NIO适用于高并发、数据传输频繁的场景（如Netty框架、即时通讯）；AIO适用于IO操作耗时较长、并发量高的场景（如大文件上传下载、分布式存储）。

面试关键点：三种IO模型的阻塞特性；NIO的核心组件（Channel、Buffer、Selector）及工作原理；AIO与NIO的本质区别；不同模型的适用场景及性能对比。

记忆法：可通过"BIO阻塞单连接一线程，NIO非阻塞Selector管多线，AIO异步等回调不阻塞"来记忆，概括三者的核心差异和工作方式。

启动两个 Java 进程，它们的 JVM 是共享的吗？

启动两个Java进程时，它们的JVM是完全独立的，不存在共享关系。这是由操作系统的进程隔离特性和JVM的运行机制共同决定的。

从进程本质来看，每个Java程序的启动都会触发操作系统创建一个独立的进程（通过java命令），而每个进程对应一个独立的JVM实例。操作系统会为每个进程分配独立的内存空间（虚拟地址空间），进程之间的内存无法直接访问，确保了进程的隔离性。JVM作为进程内的运行时环境，其所有组成部分（如堆、方法区、虚拟机栈、本地方法栈、程序计数器等内存区域）都属于所属进程的私有内存，两个Java进程的JVM内存区域完全隔离，彼此无法共享数据。例如，一个进程中修改的静态变量，在另一个进程中不会受到任何影响。

从JVM的运行机制来看，每个JVM实例有自己独立的类加载器体系（如 Bootstrap ClassLoader、Extension ClassLoader、Application ClassLoader），即使加载同一个类（如java.lang.String），在两个JVM中也会生成不同的Class对象（尽管字节码相同，但内存地址不同）。此外，每个JVM有自己的线程管理系统、垃圾回收器、即时编译器（JIT）等组件，这些组件的运行状态和数据也完全独立，不会相互干扰。

举例来说，同时启动两个Java程序（如两个Spring Boot应用），它们会在操作系统中显示为两个独立的进程（可通过任务管理器或ps命令查看），各自占用独立的CPU和内存资源。当一个进程崩溃或被终止时，另一个进程不受影响，这也印证了JVM的独立性。

需要注意的是，若两个Java进程需要通信，不能直接通过内存共享，必须通过进程间通信（IPC）机制，如Socket网络通信、共享文件、消息队列（如RabbitMQ）等。

面试关键点：Java进程与JVM的一一对应关系；进程隔离对JVM内存和组件的影响；跨进程通信的必要性及方式。

记忆法：可通过"一进程一JVM，内存组件各独立，互不相干需通信"来记忆，明确两个Java进程的JVM无共享关系。

C++ 的模板和 Java 的泛型有什么区别？

C++的模板和Java的泛型都用于实现代码复用（编写与类型无关的通用代码），但两者在实现机制、类型处理、功能范围等方面有本质区别，核心差异源于C++的"编译期实例化"和Java的"泛型擦除"机制。

1. 实现机制不同：C++模板是"编译期多态"，编译器会为每个模板参数的具体类型生成独立的代码（模板实例化）。例如，template <class T> class Box在使用Box<int>和Box<string>时，编译器会分别生成针对int和string的Box类代码，两者是完全不同的类型。而Java泛型采用"类型擦除"机制，编译后泛型的类型参数会被擦除（替换为上限类型，无上限则为Object），例如Box<Integer>和Box<String>编译后都会被擦除为Box（原始类型），字节码中不保留泛型参数信息，仅在编译期进行类型检查。

2. 类型支持不同：C++模板支持所有类型（基本类型、自定义类型、指针等），无需包装。例如template <class T> T add(T a, T b)可直接用于add(1, 2)（int类型）。而Java泛型不支持基本数据类型，必须使用对应的包装类（如int需用Integer），因为类型擦除后会用Object存储数据，而基本类型不继承自Object。因此List<int>是非法的，必须写成List<Integer>。

3. 类型检查时机不同：C++模板的类型检查在实例化阶段（编译期），针对具体类型检查方法是否兼容。例如Box<int>调用append("str")会在编译期报错，因为int类型不支持字符串操作。Java泛型的类型检查在编译期（基于泛型参数），但运行时由于类型擦除，无法获取泛型参数信息（如list.getClass() == ArrayList.class，与泛型参数无关），可能出现运行时类型转换错误（需显式强制转换）。

4. 灵活性与功能范围不同：C++模板支持"模板元编程"，可在编译期执行计算（如编译期求阶乘），甚至生成代码，功能更强大但复杂度高。Java泛型受类型擦除限制，无法在运行时获取泛型参数类型，不支持模板特化（为特定类型提供不同实现）等高级特性，功能相对简单但更安全。

5. 继承关系不同：C++中模板实例化的不同类型之间无继承关系，Box<int>和Box<string>是完全独立的类，无法相互赋值。Java中Box<Integer>和Box<String>擦除后都是Box，但编译器会阻止Box<Integer> = Box<String>的赋值（泛型安全性检查）。

面试关键点：实现机制（实例化vs擦除）的核心差异；对基本类型的支持；类型检查的时机和方式；功能范围的差异（如模板元编程）。

记忆法：可通过"C++模板编译实例化，类型全支持，元编程强；Java泛型擦除，基本用包装，运行无类型"来记忆，清晰区分两者的核心区别。

C++ 和 Java 的内存模型有什么区别？（可从内存分区、垃圾回收（引用计数与可达性分析）、垃圾回收器、对象生命周期等方面说明）

C++ 和 Java 的内存模型在设计理念和实现机制上存在显著差异，主要体现在内存分区、垃圾回收、对象生命周期等方面，这些差异源于 C++ 对性能和灵活性的追求，以及 Java 对安全性和开发效率的侧重。

从内存分区来看，C++ 的内存分区主要包括：栈（存储局部变量、函数参数等，由编译器自动分配和释放）、堆（动态分配的内存，需手动管理，如 new 分配、delete 释放）、全局/静态存储区（存储全局变量和静态变量，程序启动时分配，结束时释放）、常量存储区（存储字符串常量等，只读）。而 Java 的内存模型基于 JVM 定义，主要包括：方法区（存储类信息、常量、静态变量等，JDK 8 后改为元空间，使用本地内存）、堆（存储对象实例，是垃圾回收的主要区域）、虚拟机栈（存储方法调用的栈帧，包含局部变量表、操作数栈等）、本地方法栈（类似虚拟机栈，用于本地方法调用）、程序计数器（记录当前线程执行的字节码地址）。两者的核心区别是 Java 内存分区由 JVM 严格管理，而 C++ 内存分区更依赖操作系统和编译器，开发者对内存的直接控制更强。

在垃圾回收方面，C++ 没有内置的自动垃圾回收机制，内存管理完全由开发者负责：通过 new 分配的堆内存必须手动用 delete 释放，否则会导致内存泄漏；部分场景下（如智能指针 shared_ptr）会使用引用计数算法（记录对象被引用的次数，为 0 时自动释放），但这属于库实现而非语言原生特性，且无法解决循环引用问题（如两个对象相互引用，引用计数始终不为 0，导致内存泄漏）。Java 则内置自动垃圾回收机制，核心是通过可达性分析算法判断对象是否存活：以 GC Roots（如虚拟机栈中的引用、静态变量等）为起点，遍历对象引用链，不可达的对象被标记为可回收。这种方式能解决循环引用问题，且无需开发者手动干预，降低了内存管理错误的风险。

垃圾回收器的支持也不同：C++ 没有语言级别的垃圾回收器，所有内存释放依赖手动操作或第三方库；Java 则提供了多种垃圾回收器，针对不同场景优化，如 SerialGC（单线程回收，适合单CPU环境）、ParallelGC（多线程回收，注重吞吐量）、CMS（并发标记清除，注重响应时间）、G1（区域化分代式，平衡吞吐量和响应时间）、ZGC/Shenandoah（低延迟回收器，适合大堆场景）等，开发者可根据应用需求选择。

对象生命周期方面，C++ 对象的生命周期完全由开发者控制：栈上的对象随作用域结束自动销毁；堆上的对象需显式调用 delete，否则会一直存在（直到程序结束），可能导致内存泄漏。Java 对象的生命周期由 JVM 管理：对象在堆上创建，当被判定为不可达时，由垃圾回收器自动回收，开发者无需关心释放时机，但需注意避免内存泄漏（如长期持有无用对象的引用，导致对象无法被回收）。

面试关键点：内存分区的具体差异；垃圾回收机制（引用计数 vs 可达性分析）的优缺点；垃圾回收器的有无及种类；对象生命周期管理的责任主体。

记忆法：可通过"C++ 手动管内存，分区依赖系统，回收靠手动或计数；Java 自动管内存，JVM 分区，可达性分析加多种回收器"来记忆，概括核心区别。

代码题：如何将 IPv4 地址转换为 int32 类型？

IPv4 地址由 4 个 0-255 的整数（ octet，八位组）组成，格式为 x1.x2.x3.x4（如 192.168.1.1）。转换为 int32 类型（32 位整数）的核心思路是：将每个八位组转换为 8 位二进制数，按顺序拼接成 32 位二进制数，再转换为十进制整数（网络字节序通常为大端序，即高位字节在前）。

实现步骤包括：

1. 验证输入合法性：IPv4 地址必须由 4 个八位组组成，每个组的值在 0-255 之间，否则抛出异常。
2. 拆分地址：按 . 分割字符串，得到 4 个字符串元素。
3. 转换为整数：将每个字符串元素转换为整数，检查是否在 0-255 范围内。
4. 拼接为 32 位整数：将第一个八位组左移 24 位，第二个左移 16 位，第三个左移 8 位，第四个不位移，然后通过按位或（|）拼接。

代码示例如下：

public class IPv4ToInt32 {
    public static int ipv4ToInt32(String ipAddress) {
        // 验证输入不为空
        if (ipAddress == null || ipAddress.isEmpty()) {
            throw new IllegalArgumentException("IPv4地址不能为空");
        }
        
        // 按"."拆分
        String[] octets = ipAddress.split("\\.");
        // 检查是否有4个八位组
        if (octets.length != 4) {
            throw new IllegalArgumentException("无效的IPv4地址格式");
        }
        
        int result = 0;
        for (int i = 0; i < 4; i++) {
            try {
                // 转换为整数
                int octet = Integer.parseInt(octets[i]);
                // 检查范围
                if (octet < 0 || octet > 255) {
                    throw new IllegalArgumentException("八位组值超出范围（0-255）");
                }
                // 左移并拼接（大端序）
                result |= (octet << (24 - i * 8));
            } catch (NumberFormatException e) {
                throw new IllegalArgumentException("八位组不是有效整数", e);
            }
        }
        return result;
    }

    public static void main(String[] args) {
        // 测试案例
        System.out.println(ipv4ToInt32("0.0.0.0")); // 输出 0
        System.out.println(ipv4ToInt32("255.255.255.255")); // 输出 -1（32位全1的补码表示）
        System.out.println(ipv4ToInt32("192.168.1.1")); // 输出 3232235777
    }
}

关键说明：

• 拆分时需用 \\.（转义），因为 . 在正则中是通配符。
• 左移计算：第一个八位组（x1）是最高位，左移 24 位；x2 左移 16 位；x3 左移 8 位；x4 不左移，确保 32 位的正确拼接。
• 异常处理：覆盖输入为空、格式错误、数值越界、非整数等情况，保证健壮性。
• 对于 255.255.255.255，32 位全为 1，在 Java 中 int 是有符号的，因此表示为 -1（补码规则）。

面试关键点：输入验证的全面性；位运算的正确应用（左移和按位或）；对有符号整数的理解（如全 1 表示 -1）。

记忆法：可通过"四分验范围，左移拼 32，大端高位前"来记忆，概括转换的核心步骤。

介绍 Java 中常用的集合类有哪些？

Java 中的集合类位于 java.util 包下，用于存储和操作多个对象，主要分为 Collection 和 Map 两大体系，Collection 存储单列元素，Map 存储键值对（双列元素），常用类及其特点如下：

Collection 接口下的主要分支包括 List、Set、Queue：

List 接口：存储有序、可重复的元素，允许通过索引访问，常用实现类有：

• ArrayList：底层基于动态数组实现，支持随机访问（get/set 操作效率高，时间复杂度 O(1)），但插入/删除元素（尤其是中间位置）需移动元素，效率较低（O(n)）；初始容量为 10，扩容时通常变为原来的 1.5 倍，适合查询频繁、增删少的场景。
• LinkedList：底层基于双向链表实现，不支持随机访问（查询需遍历，O(n)），但插入/删除元素（已知位置时）仅需修改指针，效率高（O(1)）；还实现了 Deque 接口，可作为双端队列使用，适合增删频繁（尤其是首尾）、查询少的场景。
• Vector：与 ArrayList 类似（动态数组），但方法被 synchronized 修饰，是线程安全的；扩容时默认变为原来的 2 倍，效率较低，已被 ConcurrentHashMap 等更高效的线程安全集合替代，不推荐在新代码中使用。

Set 接口：存储无序、不可重复的元素（基于 equals() 和 hashCode() 判断唯一性），常用实现类有：

• HashSet：底层基于 HashMap 实现（将元素作为 HashMap 的 key，value 为固定对象），无序，查询、添加、删除效率高（平均 O(1)），适合无需排序的去重场景。
• LinkedHashSet：继承自 HashSet，底层通过 LinkedHashMap 实现，保留元素的插入顺序（通过链表维护），性能略低于 HashSet，适合需要保持插入顺序的去重场景。
• TreeSet：底层基于红黑树（一种自平衡二叉搜索树）实现，元素会按自然顺序或自定义比较器（Comparator）排序，查询、添加、删除效率为 O(log n)，适合需要排序的场景。

Queue 接口：用于存储待处理的元素，遵循先进先出（FIFO）原则，常用实现类有：

• LinkedList：实现了 Queue 接口，可作为普通队列（add/offer 入队，remove/poll 出队）或双端队列（Deque）使用。
• PriorityQueue：底层基于二叉堆实现，元素按自然顺序或自定义比较器排序，出队时总是返回最小（或最大）元素，是一种优先级队列，不遵循 FIFO。
• ArrayBlockingQueue：基于数组的有界阻塞队列，多线程环境下可用于生产者-消费者模型，支持阻塞等待。

Map 接口：存储键值对（key-value），key 不可重复（通过 equals() 和 hashCode() 判断），value 可重复，常用实现类有：

• HashMap：底层基于数组+链表/红黑树实现（JDK 8 后，当链表长度超过 8 且数组容量≥64 时，链表转为红黑树），key 无序，查询、添加、删除效率高（平均 O(1)）；key 和 value 都可为 null，是非线程安全的，适合单线程下的键值对存储。
• LinkedHashMap：继承自 HashMap，通过链表维护 key 的插入顺序或访问顺序（可设置为 LRU 缓存），性能略低于 HashMap，适合需要保持键顺序的场景。
• TreeMap：底层基于红黑树实现，key 按自然顺序或自定义比较器排序，查询、添加、删除效率为 O(log n)；key 不能为 null，适合需要按键排序的场景。
• Hashtable：与 HashMap 类似，但方法被 synchronized 修饰，是线程安全的；key 和 value 都不能为 null，效率较低，已被 ConcurrentHashMap 替代。
• ConcurrentHashMap：线程安全的 HashMap 实现，JDK 7 基于分段锁，JDK 8 基于 CAS + synchronized，并发性能优于 Hashtable，适合多线程环境。

面试关键点：各集合类的底层实现（数组、链表、红黑树、哈希表等）；性能特点（时间复杂度）；线程安全性；适用场景的选择。

记忆法：可通过"List 有序可重复（Array 查快，Linked 增删快），Set 无序去重（Hash 快，Linked 保序，Tree 排序），Map 键值对（Hash 快，Linked 保序，Tree 排序，Concurrent 线程安全）"来记忆，快速梳理核心类的特点。

ArrayList 和 LinkedList 的底层实现是什么？它们的使用场景有什么区别？在处理大数据时该如何选择？

ArrayList 和 LinkedList 是 Java 中 List 接口的两种主要实现，底层实现机制不同，导致它们在性能和适用场景上有显著差异。

ArrayList 的底层实现是动态数组（可自动扩容的数组）。它维护一个 elementData 数组存储元素，初始容量默认为 10（可通过构造方法指定）。当元素数量超过当前容量时，会触发扩容：创建一个新数组（通常为原容量的 1.5 倍，计算方式为 oldCapacity + (oldCapacity >> 1)），并将原数组元素复制到新数组中。这种结构使得 ArrayList 支持随机访问（通过索引直接定位元素），因此 get(int index) 和 set(int index, E element) 操作效率极高，时间复杂度为 O(1)。但插入（add(int index, E element)）和删除（remove(int index)）元素时，需要移动目标位置后的所有元素（复制操作），时间复杂度为 O(n)，且元素越多，效率越低；此外，扩容时的数组复制也会带来额外性能开销。

LinkedList 的底层实现是双向链表（每个节点包含前驱指针 prev、后继指针 next 和数据 item）。链表节点在内存中不连续存储，通过指针关联。这种结构使得 LinkedList 不支持随机访问，get(int index) 操作需要从链表头或尾（根据索引位置选择更近的一端）遍历到目标节点，时间复杂度为 O(n)。但插入和删除元素时，只需修改目标节点前后的指针（无需移动其他元素），若已知节点位置（如通过迭代器定位），时间复杂度可降至 O(1)；此外，LinkedList 无需扩容，内存占用随元素数量动态变化（每个节点额外存储两个指针，内存 overhead 略高）。

两者的使用场景区别主要基于操作类型：

• ArrayList 适合"查询频繁、增删少"的场景，尤其是需要通过索引随机访问元素的情况（如存储用户列表，频繁根据索引查询用户信息）。
• LinkedList 适合"增删频繁（尤其是中间位置或首尾）、查询少"的场景，或需要作为队列/双端队列使用的情况（如实现消息队列，频繁在首尾添加/移除消息）。

处理大数据时的选择需综合考虑具体操作：

• 若大数据场景以随机访问（如按索引查询）为主，即使数据量大，ArrayList 仍是更好的选择，因为 O(1) 的查询效率在大数据量下优势明显，且数组的连续内存布局有利于 CPU 缓存（局部性原理），进一步提升性能；但需注意初始容量设置（如预估数据量并在构造时指定，减少扩容次数）。
• 若大数据场景以频繁插入/删除为主（尤其是中间位置），LinkedList 更合适，因为其增删操作的时间复杂度不受数据量影响（仅与操作位置相关）；但需注意，若需要频繁查询定位元素位置，LinkedList 的 O(n) 查询会成为瓶颈，此时可能需要结合哈希表等结构优化。

此外，内存占用也是考量因素：ArrayList 的数组可能存在未使用的容量（扩容预留），导致内存浪费；LinkedList 的每个节点额外占用两个指针的内存，总内存消耗可能更高（尤其数据量极大时）。

面试关键点：底层数据结构（动态数组 vs 双向链表）；核心操作的时间复杂度；适用场景的判断依据；大数据场景下的选择逻辑（结合操作类型和内存）。

记忆法：可通过"ArrayList 数组查快增删慢，LinkedList 链表查慢增删快；大数据查多选前者，增删多选后者"来记忆，概括核心差异和选择原则。

ArrayList 是线程安全的吗？为什么？

ArrayList 不是线程安全的。这是因为 ArrayList 的内部方法（如 add()、remove()、get() 等）没有任何同步机制（如 synchronized 修饰或 CAS 操作），在多线程并发修改或读写时，可能导致数据不一致、索引越界甚至程序崩溃。

具体来说，多线程环境下使用 ArrayList 可能出现以下问题：

1. 数据覆盖：当多个线程同时执行 add() 操作时，可能导致元素被覆盖。add() 方法的核心逻辑是先检查容量，再将元素放入 elementData[size++]。若两个线程同时读取到相同的 size 值，会将元素写入同一个位置，后写入的元素会覆盖先写入的元素，导致数据丢失。

2. 数组越界（IndexOutOfBoundsException）：扩容过程中可能出现此问题。当线程 A 执行 add() 时发现需要扩容，开始复制元素到新数组；此时线程 B 也执行 add()，读取到的仍是旧数组的容量，若旧数组已被线程 A 标记为扩容，线程 B 可能在旧数组中执行 elementData[size++]，而旧数组的容量已不足，导致越界异常。

3. 迭代器 fail-fast（快速失败）：当一个线程在迭代 ArrayList 时，另一个线程修改了 ArrayList 的结构（如添加、删除元素），迭代器会检测到 modCount（修改次数计数器）的变化，抛出 ConcurrentModificationException。这是 ArrayList 的一种保护机制，但并非解决线程安全的方案。

示例代码（多线程下的问题）：

import java.util.ArrayList;
import java.util.List;

public class ArrayListThreadSafety {
    public static void main(String[] args) {
        List<Integer> list = new ArrayList<>();
        // 多个线程同时添加元素
        Runnable task = () -> {
            for (int i = 0; i < 1000; i++) {
                list.add(i);
            }
        };

        Thread t1 = new Thread(task);
        Thread t2 = new Thread(task);
        t1.start();
        t2.start();

        try {
            t1.join();
            t2.join();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        // 预期大小为2000，实际可能小于2000（数据丢失）
        System.out.println("实际大小：" + list.size());
    }
}

上述代码中，两个线程各添加 1000 个元素，预期结果为 2000，但实际结果往往小于 2000，体现了 ArrayList 的线程不安全。

若需要线程安全的 List 实现，可选择：

• Vector：方法被 synchronized 修饰，线程安全，但性能较低（全表锁）。
• Collections.synchronizedList(new ArrayList<>())：通过包装器模式，为 ArrayList 的方法添加同步锁，性能略高于 Vector。
• CopyOnWriteArrayList（JUC 包）：写入时复制新数组，读取无锁，适合读多写少的场景，性能优异。

面试关键点：ArrayList 线程不安全的具体表现（数据覆盖、越界、快速失败）；底层原因（无同步机制）；线程安全的替代方案及适用场景。

记忆法：可通过"ArrayList 无同步，多线程用出问题，数据丢、会越界，安全用 Vector 或同步包装，读多写少 CopyOnWrite"来记忆，明确其线程安全性及解决方案。

HashSet 的底层实现原理是什么？它是线程安全的吗？

HashSet 的底层是通过 HashMap 实现的，其核心是利用 HashMap 中 key 的唯一性来保证 HashSet 中元素的不可重复特性。具体来说，HashSet 内部维护了一个 HashMap 实例，当向 HashSet 中添加元素时，实际上是将该元素作为 key 存入底层的 HashMap 中，而 value 则是一个固定的静态对象（通常是 new Object()，称为" PRESENT "）。由于 HashMap 的 key 不允许重复（重复时会覆盖 value），因此 HashSet 自然实现了元素的去重功能。

HashSet 的核心方法（如 add()、contains()、remove()）均通过调用底层 HashMap 的对应方法实现：

• add(E e) 方法：调用 map.put(e, PRESENT)，若返回 null 表示添加成功（元素不存在），若返回 PRESENT 表示元素已存在（添加失败）。
• contains(Object o) 方法：调用 map.containsKey(o)，判断元素是否存在。
• remove(Object o) 方法：调用 map.remove(o)，移除对应的 key 并返回是否成功。

例如，HashSet 的 add 方法简化源码如下：

public class HashSet<E> {
    private transient HashMap<E, Object> map;
    private static final Object PRESENT = new Object();

    public boolean add(E e) {
        return map.put(e, PRESENT) == null;
    }
}

关于线程安全性，HashSet 不是线程安全的。因为其底层依赖的 HashMap 本身是非线程安全的，在多线程环境下，若同时对 HashSet 进行添加、删除等操作，可能导致数据不一致（如元素丢失、重复）或抛出 ConcurrentModificationException（快速失败机制）。例如，两个线程同时添加元素时，可能因底层 HashMap 的 put 操作无同步保护，导致相同元素被重复插入，或链表/红黑树结构被破坏。

若需要线程安全的 Set 实现，可选择：

• Collections.synchronizedSet(new HashSet<>())：通过同步包装器为所有方法添加同步锁，保证线程安全，但性能较低。
• CopyOnWriteArraySet：基于 CopyOnWriteArrayList 实现，写入时复制新数组，读取无锁，适合读多写少的场景，并发性能优异。

面试关键点：HashSet 基于 HashMap 的实现细节（key 存储元素，固定 value）；线程不安全的原因（依赖非线程安全的 HashMap）；线程安全的替代方案及适用场景。

记忆法：可通过"HashSet 底层靠 HashMap，元素作 key 去重，线程不安全需包装"来记忆，概括核心实现和安全性特点。

HashMap 的底层数据结构是什么？为什么要用红黑树而不是其他树？

HashMap 的底层数据结构在 JDK 8 及之后为"数组 + 链表 + 红黑树"的组合结构，JDK 7 及之前则是"数组 + 链表"。这种演进是为了优化哈希冲突时的查询性能。

具体来说，HashMap 以数组（称为"哈希桶"）作为主体，数组的每个元素是一个链表或红黑树的头节点。当添加元素时，先通过 key 的哈希值计算数组索引（hash & (n-1)，n 为数组容量），将元素放入对应索引的位置：

• 若该位置为空，直接存储元素（作为链表头节点）。
• 若该位置已有元素（哈希冲突），则将新元素加入链表尾部。
• 当链表长度超过阈值（默认 8）且数组容量不小于 64 时，链表会转换为红黑树，以优化查询效率。

选择红黑树而非其他树（如 AVL 树、完全二叉树、B 树等）的原因主要有以下几点：

1. 平衡性能与维护成本的平衡：红黑树是一种自平衡二叉搜索树，通过一系列规则（如节点颜色为红或黑、根节点为黑、叶子节点为黑、红节点的子节点为黑、任意节点到叶子节点的黑节点数相同）保证树的高度近似平衡（最大高度为 2log(n+1)）。相比 AVL 树（要求左右子树高度差不超过 1），红黑树的平衡条件更宽松，插入和删除时的旋转操作更少，维护成本更低，适合 HashMap 中频繁插入、删除元素的场景。

2. 查询效率稳定：红黑树的查询、插入、删除时间复杂度均为 O(log n)，远优于链表的 O(n)。当哈希冲突导致链表过长时，转为红黑树能显著提升查询性能。而完全二叉树不保证平衡性，极端情况下可能退化为链表；B 树多用于磁盘存储（如数据库索引），节点可存储多个元素，不适合 HashMap 内存中的节点结构。

3. 内存占用合理：红黑树每个节点仅需额外存储一个颜色标记（红或黑），内存开销较小。相比之下，AVL 树需要存储平衡因子（整数），内存占用更高，对于 HashMap 这种可能包含大量节点的数据结构，红黑树更具优势。

4. 适配哈希冲突的特性：哈希冲突导致的链表长度通常不会特别长（根据泊松分布，链表长度达到 8 的概率极低），红黑树在这种中等规模的节点数量下，性能表现稳定，既能避免链表的低效，又无需像更复杂的树结构那样付出过高的维护成本。

面试关键点：HashMap 数据结构的演进（数组+链表到数组+链表+红黑树）；红黑树的平衡特性与性能优势；与其他树结构的对比（尤其是 AVL 树）。

记忆法：可通过"HashMap 结构数组链，长链转红黑树；红黑树平衡易维护，log n 效率稳，胜 AVL 少旋转"来记忆，概括数据结构及红黑树的优势。

HashMap 中插入一个元素的过程是怎样的？

HashMap 插入元素（put(K key, V value)）的过程涉及哈希计算、索引定位、冲突处理、结构转换（链表转红黑树）和扩容等步骤，具体如下：

1. 计算 key 的哈希值：首先调用 key 的 hashCode() 方法获取原始哈希值，再通过 HashMap 内部的 hash() 方法进行扰动处理（对原始哈希值进行高位运算，如 (h = key.hashCode()) ^ (h >>> 16)），目的是将高位哈希值融入低位，减少哈希冲突（尤其在数组容量较小时，保证高位信息也能影响索引计算）。

2. 计算数组索引：根据扰动后的哈希值和当前数组容量（n），通过 (n - 1) & hash 计算元素在数组中的索引位置（等价于 hash % n，但位运算效率更高）。数组容量始终为 2 的幂次方，确保 n - 1 的二进制全为 1，使索引分布更均匀。

3. 检查目标位置是否为空：

   • 若数组对应索引位置为空（即 table[index] == null），直接创建新节点（Node）并放入该位置，插入完成。
   • 若不为空，说明发生哈希冲突，需进一步处理。

4. 处理哈希冲突：

   • 首先判断该位置的头节点是否与待插入 key 相同（判断标准：hash 值相等 且 (key == 头节点 key 或 key.equals(头节点 key))）。若相同，直接替换该节点的 value，插入完成。
   • 若头节点不同，判断该位置的结构是链表还是红黑树：
     • 若是红黑树（TreeNode），调用红黑树的插入方法（putTreeVal），按红黑树规则插入新节点，若存在相同 key 则替换 value。
     • 若是链表（Node），遍历链表寻找与待插入 key 相同的节点：
       • 若找到，替换其 value。
       • 若未找到，在链表尾部插入新节点（JDK 8 后为尾插法，避免 JDK 7 头插法的循环链表问题）。

5. 链表转红黑树检查：插入新节点后，若链表长度超过阈值（默认 8），则调用 treeifyBin 方法尝试将链表转为红黑树。但转树前会先检查数组容量，若容量小于 64（MIN_TREEIFY_CAPACITY），则先进行扩容（而非转树），因为小容量下扩容更能有效分散元素；若容量≥64，则将链表转为红黑树。

6. 扩容检查：插入完成后，判断当前元素数量（size）是否超过阈值（capacity * loadFactor，默认容量 16 * 负载因子 0.75 = 12）。若超过，触发扩容：

   • 新容量为原容量的 2 倍（保证仍是 2 的幂次方）。
   • 创建新数组，将原数组中的元素重新计算索引后迁移到新数组（红黑树可能拆分为链表或保持树结构）。
   • 替换原数组为新数组，完成扩容。

示例流程简化代码（核心逻辑）：

public V put(K key, V value) {
    return putVal(hash(key), key, value, false, true);
}

final V putVal(int hash, K key, V value, boolean onlyIfAbsent, boolean evict) {
    Node<K,V>[] tab; Node<K,V> p; int n, i;
    if ((tab = table) == null || (n = tab.length) == 0)
        n = (tab = resize()).length; // 初始化数组
    if ((p = tab[i = (n - 1) & hash]) == null)
        tab[i] = newNode(hash, key, value, null); // 位置为空，直接插入
    else {
        Node<K,V> e; K k;
        if (p.hash == hash && ((k = p.key) == key || (key != null && key.equals(k))))
            e = p; // 头节点相同，标记待替换
        else if (p instanceof TreeNode)
            e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value); // 红黑树插入
        else {
            for (int binCount = 0; ; ++binCount) {
                if ((e = p.next) == null) {
                    p.next = newNode(hash, key, value, null); // 链表尾部插入
                    if (binCount >= TREEIFY_THRESHOLD - 1) // 链表长度达标
                        treeifyBin(tab, hash); // 尝试转红黑树
                    break;
                }
                if (e.hash == hash && ((k = e.key) == key || (key != null && key.equals(k))))
                    break; // 找到相同key，退出循环
                p = e;
            }
        }
        if (e != null) { // 存在相同key，替换value
            V oldValue = e.value;
            if (!onlyIfAbsent || oldValue == null)
                e.value = value;
            afterNodeAccess(e);
            return oldValue;
        }
    }
    ++modCount;
    if (++size > threshold)
        resize(); // 扩容
    afterNodeInsertion(evict);
    return null;
}

面试关键点：哈希值计算与索引定位的细节；哈希冲突的处理方式（链表 vs 红黑树）；链表转红黑树的条件；扩容的触发机制与过程。

记忆法：可通过"哈希扰动算索引，空位直接插，冲突查链树；同 key 则替换，异 key 尾插入；链长超 8 且容量够，转红黑树；size 超阈值就扩容"来记忆，概括插入的核心步骤。

若向 HashMap 中两次 put 同一个 key 的元素，最终会有几个元素？HashMap 是如何比较 key 的？（需结合 == 和 equals () 的区别说明）

向 HashMap 中两次 put 同一个 key 的元素，最终只会保留一个元素（key 唯一），第二次 put 的 value 会覆盖第一次的 value。这是因为 HashMap 的 key 具有唯一性，重复 put 同一 key 时，会执行"替换"逻辑而非"新增"。

HashMap 比较两个 key 是否相同的逻辑是"两步校验"，需同时满足以下两个条件：

1. 两个 key 的哈希值（通过 hashCode() 计算并经扰动处理后）必须相等。
2. 两个 key 要么是同一个对象（== 比较为 true），要么通过 equals() 方法比较为 true。

具体来说，当插入新 key 时，HashMap 会先计算新 key 与已有 key 的哈希值：若哈希值不同，直接判定为不同 key；若哈希值相同，再通过 == 比较引用地址（是否为内存中同一个对象），若 == 为 true 则判定为相同 key；若 == 为 false，则调用 equals() 方法比较，若返回 true 则判定为相同 key，否则为不同 key。

这里需要明确 == 和 equals() 的区别：

• ==：对于基本数据类型，比较的是值；对于引用数据类型，比较的是内存地址（是否指向同一个对象）。
• equals()：是 Object 类的方法，默认实现为 return (this == obj)（即比较引用地址），但很多类（如 String、Integer 等）会重写 equals() 方法，使其比较对象的逻辑内容（如 String 的 equals() 比较字符序列是否相同）。

例如：

HashMap<String, Integer> map = new HashMap<>();
map.put(new String("a"), 1);
map.put(new String("a"), 2); // 两次put的key是不同对象（new了两次）

System.out.println(map.size()); // 输出1，因为两个key的hash值相同且equals为true
System.out.println(map.get("a")); // 输出2，第二次的value覆盖了第一次

上述代码中，两个 new String("a") 是不同对象（== 为 false），但它们的哈希值相同（"a".hashCode() 相同），且 equals() 比较为 true（内容相同），因此被判定为同一 key，第二次 put 会覆盖 value。

反之，若两个 key 的 hashCode() 不同，即使 equals() 为 true，也会被判定为不同 key（如重写 equals() 但未重写 hashCode() 的类），这会违反 HashMap 的设计约定，导致相同逻辑的 key 被重复存储。

面试关键点：重复 put 同一 key 的结果（覆盖 value）；key 比较的两步校验（哈希值 + ==/equals()）；== 与 equals() 的本质区别；重写 equals() 必须重写 hashCode() 的原因。

记忆法：可通过"同 key 两次 put，最终留一个，value 被覆盖；比较 key 先看 hash，再看 == 或 equals，二者缺一不可"来记忆，概括核心逻辑和比较规则。

HashMap 中链表转红黑树的两个条件是什么？为什么要设置这样的数据条件？

HashMap 中链表转为红黑树需要同时满足两个条件：

1. 链表的长度超过阈值 TREEIFY_THRESHOLD（默认值为 8）。
2. 数组的容量不小于 MIN_TREEIFY_CAPACITY（默认值为 64）。

只有同时满足这两个条件，链表才会转换为红黑树；若链表长度达标但数组容量不足 64，则不会转树，而是触发扩容（数组容量翻倍），通过重新计算索引分散元素，缩短链表长度。

设置这两个条件的原因与哈希冲突的特性、性能平衡及工程实践密切相关：

1. 链表长度阈值（8）的设计依据：HashMap 作者通过泊松分布计算得出，在理想哈希函数和随机哈希值的情况下，链表长度为 8 的概率极低（约为 0.00000006），这意味着链表长度达到 8 通常是哈希冲突较严重的异常情况（如 key 的哈希函数设计不合理，导致哈希值分布不均）。此时链表的查询效率已降至 O(n)，转为红黑树（O(log n)）能显著提升查询性能，平衡哈希冲突带来的性能损失。同时，阈值设为 8 而非更小（如 4），是为了避免频繁在链表和红黑树之间转换（树转链表的阈值为 6，存在缓冲区间），减少结构转换的额外开销。

2. 数组容量阈值（64）的设计目的：当数组容量较小时（如 16），链表过长更可能是因为数组容量不足导致的哈希碰撞集中（而非哈希函数问题）。此时，通过扩容（将容量翻倍至 32、64 等）能更高效地分散元素------扩容后索引重新计算（hash & (newCap - 1)），原链表中的元素会被分散到不同的新索引位置，自然缩短链表长度。相比之下，在小容量数组中转红黑树的收益有限（树结构本身有额外内存开销），且后续扩容时树的拆分也会增加复杂度。因此，设置容量阈值 64，确保只有当数组容量足够大（哈希表已具备一定规模），且链表仍过长时，才进行转树操作，兼顾性能和资源消耗。

此外，红黑树转链表的阈值为 6（UNTREEIFY_THRESHOLD），与转树阈值 8 形成缓冲区间，避免链表长度在 8 附近波动时（如频繁插入删除）导致树与链表的频繁转换，进一步优化性能。

面试关键点：链表转红黑树的两个条件（长度 8 + 容量 64）；泊松分布对阈值 8 的影响；容量阈值 64 的设计初衷（优先扩容而非转树）；缓冲区间（8→6）的作用。

记忆法：可通过"链长超 8 且容量够 64，链表转红黑树；小容量先扩容，大概率碰 8 才转树，缓冲区间防抖动"来记忆，概括条件及设计原因。

HashMap 的扩容机制是怎样的？扩容过程中的头插法和尾插法有什么区别？

HashMap 的扩容机制是指当元素数量超过阈值时，通过扩大数组容量来减少哈希冲突、优化性能的过程，核心目的是分散密集的元素，避免链表或红黑树过长导致查询效率下降。

扩容的触发条件是：当 HashMap 中元素数量（size）超过阈值（threshold = 容量 × 负载因子，默认容量 16 × 0.75 = 12）时，触发扩容。若数组未初始化（第一次插入元素），也会触发扩容（初始化为默认容量 16）。

扩容的具体过程如下：

1. 计算新容量：新容量为原容量的 2 倍（保证始终是 2 的幂次方，如 16→32、32→64 等），这是为了通过 (n-1) & hash 计算索引时，利用高位哈希值，使元素分布更均匀。
2. 计算新阈值：新阈值为新容量 × 负载因子（默认 0.75）。
3. 创建新数组：按新容量创建一个更大的数组（newTab）。
4. 迁移元素：将原数组（oldTab）中的元素重新计算索引后迁移到新数组，具体分为三种情况：
   • 若原位置是单个节点（非链表/红黑树），直接计算新索引并放入新数组。
   • 若原位置是红黑树（TreeNode），则拆分红黑树：根据新索引规则，将树节点分为两个子树，若子树长度≤6，则转为链表，否则保持红黑树。
   • 若原位置是链表（Node），则遍历链表，将节点按新索引规则分为两个子链表（低位链表和高位链表），分别放入新数组的对应位置。
5. 替换引用：将新数组赋值给 HashMap 的 table 变量，更新容量和阈值，完成扩容。

扩容过程中的头插法和尾插法是 JDK 7 与 JDK 8 中迁移链表元素时的不同实现方式，核心区别如下：

头插法（JDK 7 及之前）：迁移链表时，将原链表的节点按"头插"方式放入新数组的对应位置，即新节点插入到新链表的头部。这种方式会导致链表反转（原链表顺序与新链表顺序相反）。在多线程环境下，若同时扩容，可能因链表反转形成循环链表，导致查询时陷入死循环（如线程 A 迁移到一半，线程 B 插入节点，修改指针形成环）。

尾插法（JDK 8 及之后）：迁移链表时，保持原链表的顺序，将节点按"尾插"方式放入新数组的对应位置，即新节点插入到新链表的尾部。这种方式不会改变链表顺序，避免了多线程扩容时的循环链表问题（但 HashMap 仍非线程安全，只是解决了该特定问题）。

示例（链表迁移对比）：

• 原链表：A → B → C（索引 i）
• 头插法迁移后（新索引 j）：C → B → A（顺序反转）
• 尾插法迁移后（新索引 j）：A → B → C（顺序不变）

面试关键点：扩容的触发条件与容量计算；元素迁移的三种场景（单节点、链表、红黑树）；头插法与尾插法的区别（顺序、线程安全隐患）；JDK 版本差异对扩容的影响。

记忆法：可通过"容量超阈值则扩容，新容原 2 倍，迁移元素分三类；头插反转易成环，尾插保序更安全"来记忆，概括扩容机制及两种插入方式的核心差异。

若向 HashMap 中存入 1 亿个数据，会一次性 rehash 完成吗？什么是渐进式 rehash？其实现原理是什么？

向 HashMap 中存入 1 亿个数据时，会触发多次扩容，且每次扩容都会一次性完成 rehash（重新计算所有元素的索引并迁移），不会分阶段进行。这是因为 HashMap 是单线程设计，扩容过程是阻塞式的：一旦触发扩容，当前线程会暂停其他操作，直到所有元素迁移完成，才能继续处理后续请求。对于 1 亿个数据，单次扩容的 rehash 操作会消耗大量 CPU 和时间，可能导致程序长时间卡顿，甚至影响服务可用性。

渐进式 rehash 并非 HashMap 的特性，而是 ConcurrentHashMap（JDK 7）为解决大规模数据扩容时的性能问题而设计的机制，目的是避免一次性 rehash 带来的长时间阻塞，实现"边服务边迁移"。

渐进式 rehash 的核心原理是将数据迁移过程分散到多次操作中，而非一次性完成，具体实现如下：

1. 双数组共存：触发扩容时，ConcurrentHashMap 会创建一个新数组（新容量为原容量的 2 倍），但不立即迁移所有数据，而是同时保留旧数组和新数组（通过 sizeCtl 标记扩容状态）。
2. 分步迁移：每次执行 put、get、remove 等操作时，会顺带迁移一部分数据（如迁移旧数组中一个段的元素）。迁移时，先锁定该段，将元素重新计算索引后放入新数组，完成后标记该段已迁移。
3. 读写兼容：查询操作时，会先检查新数组，若未找到则查询旧数组；插入操作时，直接插入新数组（确保新数据只进入新数组）；删除操作时，若元素在旧数组中，迁移后再删除。
4. 完成迁移：当旧数组中的所有元素都迁移到新数组后，用新数组替换旧数组，释放旧数组内存，扩容完成。

这种机制将一次性大量迁移的开销分散到多次操作中，避免了单线程阻塞，保证了高并发场景下的服务可用性。例如，存入 1 亿个数据时，ConcurrentHashMap 会在多次 put 操作中逐步完成迁移，而非一次性阻塞处理。

需要注意的是，JDK 8 中的 ConcurrentHashMap 摒弃了分段锁，采用 CAS + synchronized 实现同步，其扩容机制虽仍有优化，但不再是严格意义上的渐进式 rehash，而是通过多线程协助迁移（每个线程负责一部分桶）来提高效率。

面试关键点：HashMap 一次性 rehash 的特性及问题；渐进式 rehash 的设计目的（避免阻塞）；ConcurrentHashMap 渐进式 rehash 的核心实现（双数组、分步迁移、读写兼容）；JDK 版本差异对 rehash 机制的影响。

记忆法：可通过"HashMap 存亿级，一次性 rehash 阻塞；渐进式 rehash 属并发，双数组分步迁，边服务边完成"来记忆，明确两种 rehash 机制的差异。

HashMap 是线程安全的吗？如何保证 HashMap 的线程安全？

HashMap 不是线程安全的。其底层实现（数组 + 链表 + 红黑树）和方法（如 put、remove 等）均未提供同步机制，在多线程环境下并发读写或修改时，可能出现数据不一致、异常甚至程序崩溃，具体表现为：

1. 数据覆盖：多线程同时执行 put 操作时，可能因同时计算出相同索引且均判断该位置为空，导致后插入的元素覆盖先插入的元素，造成数据丢失。
2. 链表循环：JDK 7 及之前使用头插法扩容，多线程并发扩容时，可能因链表反转形成循环链表，导致后续查询操作陷入死循环。
3. 快速失败（ConcurrentModificationException）：一个线程迭代 HashMap 时，另一个线程修改其结构（如添加/删除元素），迭代器会检测到 modCount 变化并抛出异常。
4. 尺寸不准确：多线程并发修改时，size 字段的更新可能丢失（如两个线程同时执行 size++，最终结果可能比实际少 1）。

保证 HashMap 线程安全的常用方式有以下三种，各有特点：

1. 使用 Collections.synchronizedMap(new HashMap<>())：通过包装器模式，为 HashMap 的所有方法添加同步锁（synchronized 块，锁对象为包装器本身），使每个方法执行时都需获取锁，从而保证线程安全。优点是实现简单，适用于并发量低的场景；缺点是全表锁导致并发性能差（多线程无法同时操作），且迭代时仍需手动同步（否则可能抛出 ConcurrentModificationException）。

2. 使用 HashTable：HashTable 是早期的线程安全哈希表实现，其所有方法都被 synchronized 修饰（锁对象为 this），本质是全表锁。优点是无需额外处理，直接使用；缺点是与 synchronizedMap 类似，并发性能低，且不允许 null 作为 key 或 value，功能受限，已逐渐被 ConcurrentHashMap 替代。

3. 使用 ConcurrentHashMap（推荐）：JUC 包提供的高效线程安全哈希表，针对并发场景优化：

   • JDK 7 采用分段锁（Segment），将数组分为多个段，每个段独立加锁，多线程可同时操作不同段，并发性能大幅提升。
   • JDK 8 摒弃分段锁，采用 CAS 操作 + synchronized 关键字（只锁定链表头或红黑树节点），进一步减少锁竞争，性能更优。
     优点是并发性能高（支持多线程同时读写），允许 null 作为 value（key 仍不允许），支持原子操作（如 putIfAbsent）；缺点是实现复杂，内存占用略高，适用于高并发场景。

示例（使用 ConcurrentHashMap）：

import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;

public class SafeHashMap {
    public static void main(String[] args) {
        Map<String, Integer> map = new ConcurrentHashMap<>();
        
        // 多线程并发操作
        Runnable task = () -> {
            for (int i = 0; i < 1000; i++) {
                map.put(Thread.currentThread().getName() + i, i);
            }
        };
        
        new Thread(task).start();
        new Thread(task).start();
    }
}

面试关键点：HashMap 线程不安全的具体表现；三种线程安全方案的实现原理与优缺点；ConcurrentHashMap 的并发优化机制（分段锁 vs CAS + synchronized）；不同并发场景下的方案选择。

记忆法：可通过"HashMap 线程不安全，并发操作出问题；同步包装全表锁，HashTable 老性能低；ConcurrentHashMap 最推荐，分段或 CAS 高并发"来记忆，概括安全性问题及解决方案。

HashTable、SynchronizedMap 和 ConcurrentHashMap 的区别是什么？HashTable 如何保证线程安全？ConcurrentHashMap 如何实现线程安全？

HashTable、SynchronizedMap 和 ConcurrentHashMap 都是线程安全的哈希表实现，但在同步机制、性能、功能支持等方面有显著区别，具体如下：

三者的核心区别：

1. 同步机制与性能：

   • HashTable：所有方法（如 put、get）均被 synchronized 修饰，本质是"全表锁"（锁对象为当前 HashTable 实例）。任何时刻只有一个线程能操作整个哈希表，并发性能极低。
   • SynchronizedMap：通过 Collections.synchronizedMap() 包装普通 Map 生成，内部使用同步块（锁对象为包装器或指定的锁对象），同样是"全表锁"。与 HashTable 相比，灵活性略高（可指定锁对象），但并发性能相同（仍为单线程独占）。
   • ConcurrentHashMap：JDK 7 采用"分段锁"（将数组分为多个 Segment，每个 Segment 独立加锁），多线程可同时操作不同 Segment，并发性能大幅提升；JDK 8 摒弃分段锁，采用"CAS 操作 + synchronized"（只锁定链表头或红黑树节点），进一步减少锁竞争，性能更优，支持更高并发。

2. 功能限制：

   • HashTable：不允许 null 作为 key 或 value（会抛出 NullPointerException）。
   • SynchronizedMap：允许 null（取决于底层 Map，如包装 HashMap 时允许 null）。
   • ConcurrentHashMap：允许 null 作为 value，但不允许 null 作为 key（避免 null 引发的歧义，如 get(null) 无法区分 key 不存在还是 value 为 null）。

3. 迭代安全性：

   • HashTable 和 SynchronizedMap：迭代时若结构被修改（如添加/删除元素），可能抛出 ConcurrentModificationException（快速失败），需手动同步迭代过程。
   • ConcurrentHashMap：迭代器是"弱一致性"的，不会抛出 ConcurrentModificationException，迭代时能看到已提交的修改，但可能看不到迭代过程中的新修改。

4. 原子操作支持：

   • HashTable 和 SynchronizedMap：不支持原子操作（如 putIfAbsent），需手动加锁实现。
   • ConcurrentHashMap：内置多种原子操作（如 putIfAbsent、remove、replace 等），无需额外同步。

HashTable 保证线程安全的方式：HashTable 的所有公开方法（如 put、get、remove 等）都被 synchronized 关键字修饰，例如：

public synchronized V put(K key, V value) {
    // 实现逻辑
}

这意味着任何线程调用这些方法时，都必须先获取 HashTable 实例的锁，同一时间只有一个线程能执行这些方法，从而保证了操作的原子性和可见性。但这种全表锁的设计导致并发性能极差，多线程环境下效率低下。

ConcurrentHashMap 实现线程安全的方式因 JDK 版本而异：

• JDK 7：基于"分段锁（Segment）"实现。Segment 继承自 ReentrantLock，每个 Segment 管理数组中的一部分桶。当操作某个桶时，只需锁定对应的 Segment，其他 Segment 可被其他线程访问。例如 put 操作时，先计算 key 所在的 Segment，获取该 Segment 的锁，完成操作后释放锁。这种方式允许多线程同时操作不同 Segment，大幅提升并发性能。
• JDK 8：摒弃分段锁，采用"CAS 操作 + synchronized"实现。数组中的每个桶（链表头或红黑树节点）作为锁对象：
  • 对于 put 操作，若桶为空，通过 CAS 直接插入节点；若桶非空，对桶的头节点加 synchronized 锁，再执行插入、替换等操作。
  • 对于 get 操作，无需加锁（依赖 volatile 保证可见性），直接读取。
    这种方式锁粒度更细（从 Segment 缩小到单个桶），锁竞争进一步减少，性能优于分段锁，同时支持多线程协助扩容（每个线程负责一部分桶的迁移）。

面试关键点：三者在同步机制和性能上的核心差异；HashTable 的全表锁实现；ConcurrentHashMap 在 JDK 7 和 JDK 8 中的线程安全机制；功能限制（如 null 支持）和迭代特性的区别。

记忆法：可通过"HashTable 全表锁，性能低禁 null；SynchronizedMap 同锁表，略灵活；ConcurrentHashMap 分段或 CAS，高并发支持原子操"来记忆，概括三者的核心区别。

HashMap 和 LinkedHashMap 的区别是什么？

HashMap 和 LinkedHashMap 都是 Java 中常用的哈希表实现，LinkedHashMap 继承自 HashMap，在其基础上增加了对元素顺序的维护，两者的核心区别体现在底层结构、迭代顺序、性能和适用场景上。

1. 底层结构不同：HashMap 的底层是"数组 + 链表 + 红黑树"，仅通过哈希值和索引管理元素，不维护元素的顺序关系。LinkedHashMap 在 HashMap 结构的基础上，额外维护了一个双向链表（称为"访问链"），每个节点除了存储 key、value、哈希值和 next 指针（用于哈希桶）外，还包含 before 和 after 指针，用于链接前一个和后一个节点，从而记录元素的插入顺序或访问顺序。

2. 迭代顺序不同：HashMap 的迭代顺序是不确定的（与插入顺序无关，取决于哈希值和扩容情况），每次迭代可能得到不同的顺序。LinkedHashMap 的迭代顺序是确定的，有两种模式：

   • 插入顺序（默认）：迭代顺序与元素的插入顺序一致，即先插入的元素先被迭代到。
   • 访问顺序（通过构造方法 LinkedHashMap(int initialCapacity, float loadFactor, boolean accessOrder) 设置 accessOrder = true 启用）：每次调用 get 或 put 方法访问元素时，该元素会被移到双向链表的尾部，迭代顺序为"最近最少访问（LRU）"顺序，适用于实现缓存。

示例（迭代顺序对比）：

// HashMap 迭代顺序不确定
Map<String, Integer> hashMap = new HashMap<>();
hashMap.put("a", 1);
hashMap.put("b", 2);
hashMap.put("c", 3);
hashMap.forEach((k, v) -> System.out.print(k)); // 可能输出 "bca" 等任意顺序

// LinkedHashMap 插入顺序
Map<String, Integer> linkedHashMap1 = new LinkedHashMap<>();
linkedHashMap1.put("a", 1);
linkedHashMap1.put("b", 2);
linkedHashMap1.put("c", 3);
linkedHashMap1.forEach((k, v) -> System.out.print(k)); // 输出 "abc"（与插入顺序一致）

// LinkedHashMap 访问顺序
Map<String, Integer> linkedHashMap2 = new LinkedHashMap<>(16, 0.75f, true);
linkedHashMap2.put("a", 1);
linkedHashMap2.put("b", 2);
linkedHashMap2.get("a"); // 访问 "a"，移到尾部
linkedHashMap2.forEach((k, v) -> System.out.print(k)); // 输出 "ba"（"a" 被访问后移到尾部）

1. 性能差异：LinkedHashMap 由于需要维护双向链表，插入、删除元素时需额外更新 before 和 after 指针，性能略低于 HashMap（尤其是数据量较大时）。查询操作的性能两者相近（均依赖哈希值定位，时间复杂度 O(1) 或 O(log n)），但 LinkedHashMap 的迭代操作效率更高（直接遍历双向链表，无需遍历整个哈希桶数组）。

2. 适用场景不同：HashMap 适用于无需关注元素顺序、追求插入和查询高效的场景（如存储键值对配置、快速查找数据）。LinkedHashMap 适用于需要保持元素顺序的场景：

   • 插入顺序：如日志记录（按时间顺序存储）、需要按插入顺序遍历的场景。
   • 访问顺序：如实现 LRU（最近最少使用）缓存（通过重写 removeEldestEntry 方法，当元素数量超过阈值时，自动移除最久未访问的元素）。

3. 其他细节：两者的初始容量、负载因子、扩容机制、哈希冲突处理方式（链表转红黑树）完全一致，因为 LinkedHashMap 复用了 HashMap 的核心逻辑，仅在元素插入、访问、删除时额外维护双向链表。

面试关键点：底层结构的差异（双向链表的存在）；迭代顺序的确定性（插入顺序 vs 访问顺序）；性能对比（LinkedHashMap 的额外开销）；LRU 缓存的实现（LinkedHashMap 的访问顺序模式）。

记忆法：可通过"HashMap 无序快，LinkedHashMap 有序（插入/访问）稍慢；链表维护顺序，适用需序或缓存"来记忆，概括两者的核心区别和适用场景。

CopyOnWriteArrayList 和 ConcurrentLinkedQueue 的底层实现是什么？

CopyOnWriteArrayList 和 ConcurrentLinkedQueue 都是 Java 并发包（java.util.concurrent）中线程安全的集合类，分别针对 List 和 Queue 场景设计，底层实现各有特点，核心是通过无锁或轻量级同步机制保证高并发性能。

CopyOnWriteArrayList 的底层实现基于"写时复制（Copy-On-Write）"的动态数组。它维护一个 volatile 修饰的数组（array），确保读操作的可见性。核心思想是：读操作无需加锁，直接访问当前数组；写操作（如 add、set、remove 等）时，不直接修改原数组，而是创建一个新数组，将原数组元素复制到新数组后再执行修改，最后用新数组替换原数组（通过 volatile 保证其他线程可见）。具体实现如下：

• 读操作（get）：直接返回 array[index]，无锁，性能极高。
• 写操作（add）：先获取独占锁（ReentrantLock），防止多线程同时写操作导致的数组不一致；然后复制原数组到新数组（新容量 = 原容量 + 1）；在新数组中添加元素；最后将 array 引用指向新数组；释放锁。
• 迭代器：基于创建时的数组快照进行迭代，不反映后续修改，因此不会抛出 ConcurrentModificationException，是"弱一致性"迭代器。

简化代码示例（add 方法核心逻辑）：

public class CopyOnWriteArrayList<E> {
    private transient volatile Object[] array;
    private final ReentrantLock lock = new ReentrantLock();

    public boolean add(E e) {
        final ReentrantLock lock = this.lock;
        lock.lock(); // 加锁，保证写操作原子性
        try {
            Object[] elements = getArray();
            int len = elements.length;
            Object[] newElements = Arrays.copyOf(elements, len + 1); // 复制原数组
            newElements[len] = e; // 添加新元素
            setArray(newElements); // 替换原数组
            return true;
        } finally {
            lock.unlock(); // 释放锁
        }
    }
}

ConcurrentLinkedQueue 的底层实现是基于单向链表的无锁队列，采用"CAS（Compare-And-Swap）"操作保证线程安全，适用于高并发的生产者-消费者场景。其核心结构包括：

• 头节点（head）和尾节点（tail），均为 volatile 修饰，确保可见性。
• 每个节点（Node）包含元素（item）和 next 指针（指向后继节点），next 用 volatile 修饰。

核心操作（入队 offer 和出队 poll）均通过 CAS 实现，无需加锁：

• 入队（offer）：从尾节点开始，通过 CAS 将新节点设置为当前尾节点的 next，若成功则尝试更新尾节点（允许尾节点滞后，减少 CAS 操作）。
• 出队（poll）：从头节点开始，通过 CAS 将头节点的 item 设为 null（标记删除），若成功则更新头节点为下一个节点。

CAS 操作依赖 Unsafe 类的 native 方法，通过硬件级别的原子操作保证多线程下的原子性，避免了锁竞争带来的性能开销。由于无锁设计，多个线程可同时进行入队和出队操作，并发性能优异，但迭代器同样是弱一致性（可能看不到最新修改）。

面试关键点：CopyOnWriteArrayList 的写时复制机制（读无锁、写加锁复制）；ConcurrentLinkedQueue 的无锁 CAS 实现；两者的弱一致性迭代器特性；适用场景（CopyOnWriteArrayList 适合读多写少，ConcurrentLinkedQueue 适合高并发队列操作）。

记忆法：可通过"CopyOnWrite 写复制，读快写慢加锁；ConcurrentLinkedQueue 无锁 CAS，高并发队列顶呱呱"来记忆，概括两者的核心实现和特点。

什么是线程安全？Java 中有哪几种方式可以保证线程安全？

线程安全是指在多线程环境下，无论操作系统如何调度线程，多个线程对共享资源的并发操作都能保证结果的正确性（与单线程执行结果一致），不会出现数据不一致、逻辑错误或异常。线程安全的核心是解决共享资源的竞争问题，确保操作的原子性、可见性和有序性。

Java 中保证线程安全的方式主要有以下几种，各有适用场景：

1. 使用 synchronized 关键字：synchronized 是 Java 内置的同步机制，可修饰方法或代码块，通过获取对象的监视器锁（monitor）保证同一时间只有一个线程执行同步代码，实现操作的原子性。同时，synchronized 能保证可见性（释放锁时将修改刷新到主内存，获取锁时从主内存加载最新值）和有序性（禁止指令重排序）。例如：

   // 修饰方法
   public synchronized void increment() {
   count++;
   }

   // 修饰代码块
   public void update() {
   synchronized (this) {
   // 同步操作
   }
   }

优点是使用简单，无需手动释放锁；缺点是锁粒度较粗（可能导致并发性能低），无法中断等待锁的线程。

1. 使用 volatile 关键字：volatile 用于修饰变量，保证变量的可见性（一个线程修改后，其他线程能立即看到最新值）和有序性（禁止指令重排序），但不保证原子性。适用于变量被多个线程读取、但只有一个线程修改的场景（如状态标记）：

   private volatile boolean isRunning = true;

   public void stop() {
   isRunning = false; // 线程 A 修改
   }

   public void run() {
   while (isRunning) { // 线程 B 能立即看到修改
   // 执行任务
   }
   }

2. 使用 JUC 中的锁（如 ReentrantLock）：ReentrantLock 是可重入锁，提供比 synchronized 更灵活的功能，如可中断锁、超时获取锁、公平锁/非公平锁选择、条件变量（Condition）等。通过 lock() 获取锁，unlock() 释放锁（需在 finally 中执行）：

   private final ReentrantLock lock = new ReentrantLock();

   public void operation() {
   lock.lock();
   try {
   // 同步操作
   } finally {
   lock.unlock();
   }
   }

优点是锁粒度可控，功能丰富，适合复杂同步场景；缺点是需手动释放锁，易因遗漏导致死锁。

1. 使用原子类（如 AtomicInteger）：原子类基于 CAS 操作实现，提供线程安全的原子操作（如自增、赋值等），无需加锁，性能优于锁机制。常用类有 AtomicInteger、AtomicLong、AtomicReference 等：

   private AtomicInteger count = new AtomicInteger(0);

   public void increment() {
   count.incrementAndGet(); // 原子自增，等价于 count++
   }

适用于简单的计数器、状态标记等场景，不适合复杂的复合操作。

1. 使用线程安全的集合：如 ConcurrentHashMap、CopyOnWriteArrayList、ConcurrentLinkedQueue 等，内部通过锁分段、CAS、写时复制等机制保证线程安全，无需手动同步，适合高并发场景。

2. 使用 ThreadLocal：ThreadLocal 为每个线程提供独立的变量副本，避免共享资源竞争，本质是"以空间换时间"。适用于变量需线程隔离的场景（如数据库连接、Session 管理）：

   private ThreadLocal<Connection> connectionThreadLocal = ThreadLocal.withInitial(() -> {
   return DriverManager.getConnection(url, user, password);
   });

   // 线程获取自己的连接
   Connection conn = connectionThreadLocal.get();

3. 不可变对象：若对象创建后状态不可修改（如 String、Integer），则天然线程安全，因为无需担心被修改。可通过 final 关键字修饰类、字段，且不提供 setter 方法实现。

面试关键点：线程安全的核心定义（原子性、可见性、有序性）；各种线程安全方式的实现原理（synchronized 监视器锁、volatile 内存语义、CAS 操作等）；不同方式的适用场景及优缺点对比。

记忆法：可通过"同步锁（synchronized/ReentrantLock）保原子，volatile 保可见有序，原子类 CAS 高性能，线程安全集合免手动，ThreadLocal 隔离变量，不可变对象天然安"来记忆，概括主要方式及核心作用。

进程和线程的区别是什么？

进程和线程是操作系统中调度和资源管理的基本单位，两者既有联系又有本质区别，核心差异体现在资源占用、调度方式、通信机制等方面。

从定义来看，进程是程序的一次执行过程，是操作系统进行资源分配和调度的独立单位；线程是进程的一个执行单元，是操作系统进行任务调度的基本单位，一个进程可以包含多个线程，线程共享进程的资源。

具体区别如下：

1. 资源占用：进程拥有独立的资源空间，包括内存（代码段、数据段、堆）、文件描述符、IO 设备等，进程间的资源不共享，切换时需保存和恢复整个进程的资源状态，开销较大。线程不拥有独立资源，共享所属进程的内存、文件描述符等资源，仅拥有独立的栈空间、程序计数器和寄存器，资源占用少，切换时只需保存线程私有数据，开销远小于进程。

2. 调度粒度：操作系统调度的基本单位是线程，而非进程。同一进程内的线程切换由进程内的线程调度器管理，无需切换地址空间，速度更快；不同进程间的切换需要操作系统介入，涉及地址空间切换，速度较慢。因此，线程的调度效率远高于进程。

3. 生命周期：进程的生命周期包括创建、就绪、运行、阻塞、终止，创建和终止的开销大（需分配和释放资源）。线程的生命周期与进程类似，但创建和终止仅需初始化或释放私有数据，开销小。一个进程终止时，其所有线程会被强制终止；而线程终止不会影响同进程的其他线程。

4. 通信机制：进程间通信（IPC）需通过操作系统提供的机制，如管道、消息队列、共享内存、信号量、Socket 等，由于资源隔离，通信复杂且效率低。线程间通信简单，可直接通过共享进程内的变量（如全局变量、堆内存）实现，也可使用线程同步机制（如锁、信号量）协调访问，通信效率高。

5. 独立性：进程是独立的执行单位，一个进程崩溃通常不会影响其他进程（操作系统隔离）。线程依赖于进程，同一进程内的线程共享资源，一个线程崩溃可能导致整个进程崩溃（如内存访问错误），独立性低。

6. 并发性：多进程和多线程都能实现并发，但线程的并发粒度更细。在多核 CPU 上，多线程可真正并行执行（同一进程的线程分配到不同核心）；多进程也可并行，但资源开销更大。

举例来说，打开一个浏览器是一个进程，浏览器中的每个标签页可视为一个线程：标签页共享浏览器的网络连接、缓存等资源，切换标签页（线程切换）快速，一个标签页崩溃可能导致浏览器整体崩溃；而同时打开浏览器和文本编辑器则是两个独立进程，资源不共享，一个崩溃不影响另一个。

面试关键点：资源占用的独立性（进程独立 vs 线程共享）；调度粒度和开销（线程更轻量）；通信机制的复杂度；独立性和故障影响范围；并发性的实现差异。

记忆法：可通过"进程资源独，线程共享父；进程调度重，线程切换轻；进程通信难，线程共享简；进程独立强，线程同存亡"来记忆，概括核心区别。

操作系统中线程的状态有哪些？各状态之间如何转换？Java 中线程的状态有哪些？各状态之间如何转换？

操作系统和 Java 中的线程状态定义及转换逻辑不同，前者是操作系统内核级的状态描述，后者是 Java 语言层面基于内核状态的抽象，具体如下：

操作系统中线程的状态 ：

操作系统内核通常将线程状态分为以下几种：

1. 就绪（Ready）：线程已获取除 CPU 外的所有资源，等待操作系统调度分配 CPU 时间片。
2. 运行（Running）：线程正在 CPU 上执行，占用 CPU 资源。
3. 阻塞（Blocked）：线程因等待某种资源（如 I/O 完成、锁释放、信号量）而暂停执行，不占用 CPU。阻塞可细分为：
   • I/O 阻塞：等待 I/O 操作完成（如磁盘读写、网络请求）。
   • 锁阻塞：等待其他线程释放锁。
   • 信号量阻塞：等待信号量触发。
4. 终止（Terminated）：线程执行完成或被强制终止，生命周期结束。

状态转换：

• 就绪 → 运行：操作系统调度器从就绪队列中选择线程，分配 CPU 时间片。
• 运行 → 就绪：时间片用完或被更高优先级线程抢占，线程回到就绪队列。
• 运行 → 阻塞：线程执行过程中请求资源（如 I/O、锁），资源未就绪时进入阻塞状态。
• 阻塞 → 就绪：等待的资源就绪（如 I/O 完成、锁释放），线程从阻塞队列进入就绪队列，等待调度。
• 运行 → 终止：线程执行完 run 方法或被中断（如调用 stop()）。

Java 中线程的状态 ：

Java 中线程状态定义在 Thread.State 枚举中，共 6 种，是对操作系统状态的更高层次抽象：

1. NEW（新建）：线程对象已创建，但未调用 start() 方法，尚未启动。
2. RUNNABLE（可运行）：线程已启动，包含两种情况：
   • 正在 CPU 上执行（对应操作系统的运行状态）。
   • 等待 CPU 调度（对应操作系统的就绪状态）。
3. BLOCKED（阻塞）：线程等待获取 synchronized 监视器锁（如尝试进入 synchronized 方法/块，而锁被其他线程持有）。
4. WAITING（等待）：线程无限期等待其他线程的特定操作（如 Object.wait()、Thread.join()、LockSupport.park()），需被其他线程唤醒（如 Object.notify()）。
5. TIMED_WAITING（超时等待）：线程等待指定时间（如 Thread.sleep(long)、Object.wait(long)、Thread.join(long)），时间到后自动唤醒或被提前唤醒。
6. TERMINATED（终止）：线程执行完成（run 方法结束）或被异常终止。

状态转换：

• NEW → RUNNABLE：调用 start() 方法，线程启动，进入可运行状态。
• RUNNABLE → BLOCKED：线程尝试获取 synchronized 锁，若锁被占用，则进入阻塞状态；获取锁后从 BLOCKED → RUNNABLE。
• RUNNABLE → WAITING：执行 Object.wait()（无参）、Thread.join()（无参）等，进入等待状态；被其他线程调用 notify()/notifyAll() 或 join 的线程终止，从 WAITING → RUNNABLE。
• RUNNABLE → TIMED_WAITING：执行 Thread.sleep(1000)、Object.wait(1000) 等带超时的方法，进入超时等待；时间到或被提前唤醒，从 TIMED_WAITING → RUNNABLE。
• RUNNABLE → TERMINATED：线程执行完 run 方法或被强制终止（如 stop()，已废弃）。

核心区别：操作系统的"阻塞"包含所有资源等待，而 Java 的 BLOCKED 仅特指等待 synchronized 锁；Java 的 RUNNABLE 合并了操作系统的就绪和运行状态，更简洁。

面试关键点：操作系统线程状态的四态模型及转换；Java 线程的 6 种状态（尤其是 BLOCKED、WAITING、TIMED_WAITING 的区别）；状态转换的触发条件（如方法调用、锁竞争）。

记忆法：操作系统线程状态可记为"就绪等 CPU，运行占 CPU，阻塞等资源，终止已结束"；Java 线程状态可记为"NEW 未启动，RUNNABLE 可运行，BLOCKED 等锁，WAITING 等通知，TIMED_WAITING 限时等，TERMINATED 已终止"。

一个线程在等待获取 synchronized 锁时，该线程处于什么状态？

一个线程在等待获取 synchronized 锁时，处于 BLOCKED（阻塞）状态。这是 Java 线程状态中对"等待监视器锁"场景的明确定义，区别于其他等待状态（如 WAITING 或 TIMED_WAITING）。

具体来说，当线程 A 尝试进入一个 synchronized 方法或代码块时，若该锁已被线程 B 持有，线程 A 无法立即获取锁，会被放入该锁的"阻塞队列"中，此时线程 A 的状态从 RUNNABLE 转换为 BLOCKED。直到线程 B 释放锁（退出 synchronized 方法/块），操作系统会从阻塞队列中唤醒一个线程（通常是随机的），使其重新尝试获取锁，成功后状态从 BLOCKED 转换为 RUNNABLE。

需要明确 BLOCKED 状态与其他等待状态的区别：

• BLOCKED 仅针对 synchronized 锁的等待，是"被动等待"（等待其他线程释放锁）。
• WAITING 状态是线程主动调用无参的 Object.wait()、Thread.join() 等方法后进入的状态，需等待其他线程主动唤醒（如 notify()），等待的是"通知"而非"锁"。
• TIMED_WAITING 状态是线程调用带超时参数的方法（如 Thread.sleep(1000)、Object.wait(1000)）后进入的状态，等待时间到后自动唤醒，或被提前唤醒，等待的是"时间"或"通知"。

示例代码（展示 BLOCKED 状态）：

public class BlockedStateDemo {
    public static void main(String[] args) throws InterruptedException {
        Object lock = new Object();
        
        // 线程1持有锁
        Thread t1 = new Thread(() -> {
            synchronized (lock) {
                try {
                    Thread.sleep(5000); // 持有锁5秒
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        });
        
        // 线程2尝试获取锁，会进入BLOCKED状态
        Thread t2 = new Thread(() -> {
            synchronized (lock) { // 尝试获取锁
                System.out.println("线程2获取到锁");
            }
        });
        
        t1.start();
        Thread.sleep(1000); // 确保t1先获取锁
        t2.start();
        Thread.sleep(1000);
        
        // 此时t2处于BLOCKED状态
        System.out.println("t2状态：" + t2.getState()); // 输出 BLOCKED
    }
}

上述代码中，t1 先获取锁并持有 5 秒，t2 启动后尝试获取同一把锁，因锁被占用而进入 BLOCKED 状态，直到 t1 释放锁后，t2 才能获取锁并继续执行。

面试关键点：BLOCKED 状态的定义（等待 synchronized 锁）；与 WAITING、TIMED_WAITING 状态的区别；触发 BLOCKED 状态的场景（竞争 synchronized 锁）。

记忆法：可通过"等 synchronized 锁，状态是 BLOCKED；等通知是 WAITING，限时等是 TIMED_WAITING"来记忆，明确不同等待场景对应的线程状态。

调用线程的 start () 方法后再调用一次会发生什么？

调用线程的 start() 方法后再调用一次会抛出 IllegalThreadStateException 异常。这是由线程的生命周期规则决定的，start() 方法的核心作用是启动线程，使其从 NEW 状态进入 RUNNABLE 状态，而一个线程只能被启动一次。

线程的生命周期中，start() 方法的执行逻辑包含对线程状态的严格检查。当线程对象被创建时，初始状态为 NEW（尚未调用 start()）。第一次调用 start() 时，JVM 会检查状态是否为 NEW，若是则启动线程（调用底层 start0() native 方法，由操作系统创建实际的线程实体），并将状态从 NEW 转换为 RUNNABLE。一旦线程状态脱离 NEW（无论后续是 RUNNABLE、BLOCKED、TERMINATED 等），再次调用 start() 时，JVM 会检测到状态非 NEW，直接抛出 IllegalThreadStateException，阻止重复启动。

从底层实现看，Thread 类的 start() 方法源码（简化）如下：

public synchronized void start() {
    if (threadStatus != 0) // threadStatus 为 0 表示 NEW 状态
        throw new IllegalThreadStateException();
    // 加入线程组等操作
    start0(); //  native 方法，启动线程
}

其中 threadStatus 是线程的状态标识，初始值为 0（NEW 状态），start() 方法通过 synchronized 保证线程安全，且仅允许 threadStatus 为 0 时执行 start0()。

需要注意，线程执行完毕后状态变为 TERMINATED，此时即使再次调用 start()，同样会因状态非 NEW 而抛出异常。若需重复执行相同任务，需重新创建线程对象（处于 NEW 状态）并调用 start()。

示例代码验证：

public class RepeatStartDemo {
    public static void main(String[] args) {
        Thread thread = new Thread(() -> {
            System.out.println("线程执行");
        });
        
        thread.start(); // 第一次启动，正常执行
        try {
            Thread.sleep(1000); // 等待线程执行完毕
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        
        try {
            thread.start(); // 第二次启动，抛出异常
        } catch (IllegalThreadStateException e) {
            System.out.println("异常：" + e.getMessage()); // 输出异常信息
        }
    }
}

上述代码中，线程第一次启动后执行完毕（状态为 TERMINATED），第二次调用 start() 会触发 IllegalThreadStateException。

面试关键点：线程生命周期中 start() 方法的状态检查机制；IllegalThreadStateException 的触发条件；线程只能启动一次的底层原因（threadStatus 标识和 start0() native 方法的调用限制）。

记忆法：可通过"线程启动靠 start，一次启动终生效；状态脱离 NEW 后，再调用就抛异常"来记忆，明确 start() 方法的调用限制和异常原因。

从操作系统层面看，两个线程可以访问同一个数据吗？如果一个线程崩溃了，会影响整个进程的运行吗？

从操作系统层面看，两个线程可以访问同一个数据。因为线程是进程的执行单元，同一进程内的所有线程共享该进程的地址空间（包括代码段、数据段、堆内存等），这意味着线程间无需额外机制即可直接访问进程的共享资源（如全局变量、堆上的对象等）。例如，进程中的两个线程可同时读写堆内存中的同一个数组，或访问全局变量。这种共享特性是线程高效通信的基础，但也带来了线程安全问题（如数据竞争），需通过同步机制（如锁、信号量）保证操作的原子性。

一个线程崩溃是否影响整个进程，取决于崩溃的原因：

• 若线程因逻辑错误（如空指针异常、数组越界）崩溃，通常只会导致该线程终止，不会直接影响同进程的其他线程。这是因为现代操作系统会为线程设置异常处理机制，当线程触发未捕获的异常时，操作系统会终止该线程，但进程的其他线程仍可继续运行。例如，Java 中一个线程抛出 NullPointerException 未被捕获，会导致该线程终止，但 JVM 进程和其他线程不受影响。
• 若线程因严重错误（如访问非法内存地址、栈溢出、硬件错误）崩溃，可能导致整个进程终止。因为这些错误会破坏进程的共享资源（如内存空间被污染、进程的核心数据结构损坏），操作系统为避免进一步的系统级风险，会终止整个进程及其所有线程。例如，C 语言中线程执行 *(int*)0 = 0（写入空指针地址）会触发内存访问错误，操作系统会发送信号终止整个进程。

核心原因是线程与进程的资源关系：线程共享进程的地址空间和核心资源，线程的崩溃若局限于自身私有数据（如栈空间的局部错误），则影响范围有限；若涉及共享资源的破坏，则会牵连整个进程。

举例说明：

• 安全崩溃场景：线程 A 因 ArrayIndexOutOfBoundsException 终止，线程 B 仍可继续访问共享的全局变量，进程正常运行。
• 致命崩溃场景：线程 A 因缓冲区溢出改写了进程的代码段，导致进程的指令集被破坏，操作系统检测到后终止整个进程，线程 B 也随之终止。

面试关键点：线程共享进程资源的特性（可直接访问同一数据）；线程崩溃对进程的影响取决于崩溃原因（逻辑错误 vs 资源破坏）；线程与进程的资源依赖关系。

记忆法：可通过"线程共享进程资源，同数据可共访问；线程崩溃看原因，逻辑错仅自毙，坏共享杀全进程"来记忆，概括核心结论。

synchronized 关键字的使用方法是什么？其底层实现原理是什么？（需涉及对象头、锁池、等待池）

synchronized 是 Java 中用于保证线程安全的关键字，通过实现同步机制防止多线程并发访问共享资源时的数据不一致。其使用方法和底层实现如下：

使用方法 ：
synchronized 可用于修饰方法或代码块，具体有三种形式：

1. 修饰实例方法：锁对象为当前实例（this），同一实例的多个同步方法共享一把锁，不同实例的锁相互独立。

   public synchronized void instanceMethod() {
       // 同步代码
   }

2. 修饰静态方法：锁对象为当前类的 Class 对象（如 Xxx.class），所有静态同步方法共享同一把锁（类级别的锁）。

   public static synchronized void staticMethod() {
       // 同步代码
   }

3. 修饰代码块：显式指定锁对象（可为任意对象），灵活性更高，可缩小同步范围，减少锁竞争。

   public void blockMethod() {
       synchronized (lockObject) { // lockObject 为指定的锁对象
           // 同步代码
       }
   }

底层实现原理 ：
synchronized 的底层依赖 JVM 的监视器锁（monitor）机制，核心涉及对象头、锁池和等待池：

1. 对象头（Object Header）：Java 对象在内存中的布局包括对象头、实例数据和对齐填充，其中对象头是实现 synchronized 的关键。对象头由两部分组成：

   • Mark Word：存储对象的运行时状态，如哈希码、GC 分代年龄、锁状态（无锁、偏向锁、轻量级锁、重量级锁）、持有锁的线程 ID 等。锁的状态信息就存储在这里，是 synchronized 实现的核心数据结构。
   • 类型指针（Klass Pointer）：指向对象所属类的元数据（方法区中的 Class 对象），确定对象的类型。

   例如，在重量级锁状态下，Mark Word 会存储指向监视器（monitor）的指针，通过监视器实现锁的管理。

2. 监视器（monitor）：每个 Java 对象都关联一个监视器（可理解为一种同步工具），监视器内部维护两个队列：

   • 锁池（Entry Set）：存放等待获取锁的线程。当线程尝试获取 synchronized 锁时，若锁已被其他线程持有，该线程会被放入锁池，进入 BLOCKED 状态，等待锁释放。
   • 等待池（Wait Set）：存放调用 wait() 方法后释放锁的线程。线程获取锁后，若执行 wait()，会释放锁并进入等待池，进入 WAITING 状态，需等待其他线程调用 notify() 或 notifyAll() 唤醒，唤醒后线程会从等待池转移到锁池，重新竞争锁。

3. 同步过程：

   • 线程进入 synchronized 代码时，需先获取锁：通过 CAS 操作尝试修改对象头 Mark Word 中的锁状态，若成功（锁未被持有），则持有锁并执行代码；若失败（锁已被持有），则进入锁池（BLOCKED 状态）。
   • 线程执行 wait() 方法时，释放锁，从运行状态进入等待池（WAITING 状态）。
   • 其他线程执行 notify() 时，从等待池唤醒一个线程，使其进入锁池竞争锁；执行 notifyAll() 时，唤醒等待池所有线程，全部进入锁池竞争锁。
   • 线程退出 synchronized 代码时，释放锁，JVM 从锁池唤醒一个线程，使其有机会获取锁。

例如，当线程 A 持有锁执行同步代码时，线程 B 尝试获取锁会进入锁池（BLOCKED）；若线程 A 调用 wait()，则释放锁并进入等待池（WAITING），线程 B 可获取锁；线程 A 被 notify() 唤醒后，进入锁池等待重新获取锁。

面试关键点：synchronized 的三种使用形式（实例方法、静态方法、代码块）；对象头的结构（Mark Word 的作用）；监视器的锁池和等待池的区别及转换；同步过程的锁获取与释放逻辑。

记忆法：可通过"synchronized 三用法，实例静态代码块；底层依赖监视器，对象头存锁状态；锁池等锁 BLOCKED，等待池等 notify，wait 放锁入等待"来记忆，概括使用方法和底层机制。

Java 对 synchronized 做了哪些优化？（围绕偏向锁、轻量级锁、重量级锁的升级过程说明）

Java 对 synchronized 的优化主要体现在锁的分级实现上，通过引入偏向锁、轻量级锁和重量级锁，根据竞争程度动态调整锁的类型，减少锁竞争带来的性能开销。这三种锁的升级过程是"无锁 → 偏向锁 → 轻量级锁 → 重量级锁"，不可逆（除偏向锁可被撤销外），具体如下：

1. 偏向锁（Biased Locking） ：

适用场景：无实际竞争，且只有一个线程多次获取锁。

核心原理：锁会偏向于第一个获取它的线程，减少无竞争情况下的 CAS 操作开销。当线程第一次获取锁时，通过 CAS 将线程 ID 记录在对象头的 Mark Word 中（偏向模式），之后该线程再次获取锁时，无需 CAS 操作，仅需判断 Mark Word 中的线程 ID 是否为当前线程 ID，若一致则直接进入同步代码，几乎无开销。

2. 轻量级锁 ：

适用场景：有轻微竞争（多个线程交替获取锁，无长时间持有）。

升级触发：当有第二个线程尝试获取偏向锁时，偏向锁会被撤销（需等待全局安全点，暂停持有偏向锁的线程），升级为轻量级锁。

核心原理：线程获取轻量级锁时，会在栈帧中创建锁记录（Lock Record），存储对象头的 Mark Word 副本，然后通过 CAS 将对象头的 Mark Word 替换为指向锁记录的指针（称为"加锁"）。若 CAS 成功，线程获取锁；若 CAS 失败（表示存在竞争），则尝试自旋（忙等）获取锁，避免立即升级为重量级锁。

3. 重量级锁 ：

适用场景：竞争激烈（多个线程同时争抢锁，或线程持有锁时间长）。

升级触发：轻量级锁的自旋达到一定次数（或自旋线程数超过 CPU 核心数的一半），自旋失败，此时轻量级锁膨胀为重量级锁。

核心原理：依赖操作系统的互斥量（mutex）实现，线程获取重量级锁时，若锁被占用，线程会进入内核态阻塞（放入锁池，状态为 BLOCKED），不再自旋，减少 CPU 浪费。但内核态与用户态切换开销大，性能较低。

升级过程详解：

1. 初始状态：对象刚创建时，处于无锁状态，Mark Word 存储哈希码和 GC 年龄。
2. 偏向锁获取：第一个线程获取锁，通过 CAS 将线程 ID 写入 Mark Word，进入偏向模式。
3. 偏向锁撤销与轻量级锁升级：第二个线程尝试获取锁，JVM 检查到竞争，撤销偏向锁（需停顿线程，更新 Mark Word），两个线程分别在栈帧创建锁记录，通过 CAS 竞争 Mark Word 的锁记录指针，成功者获取轻量级锁。
4. 轻量级锁膨胀：若 CAS 竞争失败（如第三个线程参与竞争），线程进入自旋；自旋次数耗尽（或竞争加剧），轻量级锁升级为重量级锁，Mark Word 指向监视器（monitor），未获取锁的线程进入锁池阻塞。

优化效果：通过分级锁，在无竞争或轻微竞争时避免重量级锁的高开销，仅在激烈竞争时使用重量级锁，平衡了同步安全性和性能。例如，单线程频繁访问同步代码时，偏向锁几乎无开销；多线程交替访问时，轻量级锁的自旋减少阻塞；高并发争抢时，重量级锁保证同步但牺牲部分性能。

面试关键点：三种锁的适用场景；升级触发条件（偏向锁撤销、轻量级锁膨胀的原因）；各阶段锁的实现原理（偏向锁的线程 ID 记录、轻量级锁的 CAS 与自旋、重量级锁的互斥量）；优化带来的性能提升逻辑。

记忆法：可通过"无锁开始，单线程偏；多线程来，轻量自旋；竞争激烈，重量阻塞；锁升级不可逆，按需选类型"来记忆，概括锁升级的过程和核心逻辑。

synchronized 是在什么公共资源上加锁？创建一个 Java 对象时，除了属性值，还有什么部分？synchronized 锁定的数据存储在对象的哪里？

synchronized 是在对象的"监视器（monitor）"这一公共资源上加锁。监视器是一种同步机制，每个 Java 对象在 JVM 中都隐式关联一个监视器，synchronized 通过获取和释放监视器的所有权实现同步。当线程进入 synchronized 代码时，需先获取该对象的监视器所有权；退出时释放所有权，确保同一时间只有一个线程持有监视器，从而保证同步代码的原子性。

创建一个 Java 对象时，在内存中除了存储属性值（实例数据），还包括以下部分：

1. 对象头（Object Header）：对象的核心元数据，占 8 字节（32 位 JVM）或 16 字节（64 位 JVM，默认开启指针压缩），包含：

   • Mark Word：存储对象的运行时状态，如哈希码、GC 分代年龄、锁状态（无锁、偏向锁、轻量级锁、重量级锁）、持有锁的线程 ID、监视器指针等。
   • 类型指针（Klass Pointer）：指向对象所属类的元数据（方法区中的 Class 对象），用于确定对象的类型，如判断对象是否为某个类的实例。
   • 数组长度（仅数组对象）：若对象是数组，对象头还会额外存储数组的长度（4 字节）。

2. 对齐填充（Padding）：Java 对象在内存中的大小需为 8 字节的整数倍（64 位 JVM），若对象头 + 实例数据的总大小不满足，会通过对齐填充补充空白字节，确保内存对齐，提高 CPU 访问效率。

synchronized 锁定的数据存储在对象头的 Mark Word 中。Mark Word 是一个动态变化的字段，会根据对象的锁状态存储不同信息：

• 无锁状态：存储对象的哈希码、GC 分代年龄。
• 偏向锁状态：存储偏向的线程 ID、偏向时间戳、GC 分代年龄，标记为偏向模式。
• 轻量级锁状态：存储指向线程栈帧中锁记录（Lock Record）的指针，锁记录中包含 Mark Word 的副本。
• 重量级锁状态：存储指向监视器（monitor）的指针，通过监视器管理锁的竞争和等待。

例如，当线程获取重量级锁时，Mark Word 会指向该对象关联的监视器，监视器内部的锁池和等待池记录等待线程的状态；释放锁时，Mark Word 可能恢复为轻量级锁状态（若竞争消失）或保持重量级锁状态（若仍有竞争）。

这种设计的核心是将锁状态与对象绑定，通过对象头的 Mark Word 高效存储锁信息，避免额外的内存开销，同时支持锁的升级（偏向锁 → 轻量级锁 → 重量级锁），适应不同的并发场景。

面试关键点：synchronized 锁定的是对象的监视器；Java 对象的三部分组成（对象头、实例数据、对齐填充）；对象头中 Mark Word 的作用及锁状态存储；不同锁状态下 Mark Word 的内容差异。

记忆法：可通过"synchronized 锁监视器，对象关联不可离；创建对象三部分，头（对象头）、数（实例数据）、填充（对齐填充）要记齐；锁信息存 Mark Word，状态随锁动态变"来记忆，概括核心知识点。

ReentrantLock（Lock 接口）与 synchronized 的区别是什么？

ReentrantLock 是 Java 并发包（java.util.concurrent.locks）中实现 Lock 接口的可重入锁，与 synchronized 同为线程安全的同步机制，但在实现原理、功能特性和使用方式上有显著区别，具体如下：

1. 锁的获取与释放方式：synchronized 是隐式锁，无需手动操作，线程进入同步代码块时自动获取锁，退出时自动释放（包括正常退出、抛出异常），无需担心锁泄漏。ReentrantLock 是显式锁，需通过 lock() 方法手动获取锁，unlock() 方法释放锁，且 unlock() 必须放在 finally 块中（否则可能因异常导致锁未释放，引发死锁），示例：

   // synchronized 隐式释放
   public synchronized void syncMethod() {
   // 同步操作
   }

   // ReentrantLock 显式释放
   public void lockMethod() {
   lock.lock();
   try {
   // 同步操作
   } finally {
   lock.unlock(); // 必须手动释放
   }
   }

2. 可中断性：synchronized 无法中断等待锁的线程，线程一旦进入 BLOCKED 状态，只能等待其他线程释放锁或一直阻塞。ReentrantLock 支持中断等待锁的线程，通过 lockInterruptibly() 方法，线程在等待锁时可响应中断（如其他线程调用 interrupt()），避免无限期等待，示例：

   try {
   lock.lockInterruptibly(); // 可被中断的锁获取
   } catch (InterruptedException e) {
   // 处理中断逻辑
   }

3. 超时获取锁：ReentrantLock 可通过 tryLock(long timeout, TimeUnit unit) 尝试在指定时间内获取锁，超时未获取则返回 false，适合避免死锁。synchronized 无此功能，线程会一直阻塞直到获取锁。

4. 公平锁支持：synchronized 只能是非公平锁（线程获取锁的顺序不保证，可能存在饥饿）。ReentrantLock 可通过构造函数 new ReentrantLock(true) 创建公平锁，保证线程按等待顺序获取锁（需额外开销，性能略低）。

5. 条件变量（Condition）：ReentrantLock 可通过 newCondition() 方法创建多个条件变量，实现更精细的线程间通信（如不同条件下的等待/唤醒）。synchronized 仅通过对象的 wait()、notify()、notifyAll() 实现通信，且一个对象只有一个等待池，功能单一。示例：

   ReentrantLock lock = new ReentrantLock();
   Condition notEmpty = lock.newCondition();
   Condition notFull = lock.newCondition();

   // 线程1等待非空条件
   notEmpty.await();
   // 线程2唤醒非空条件
   notEmpty.signal();

6. 底层实现：synchronized 基于 JVM 内置的监视器锁（monitor）实现，依赖对象头的 Mark Word 和操作系统互斥量。ReentrantLock 基于 AQS（AbstractQueuedSynchronizer）实现，通过 volatile 修饰的状态变量（state）和双向队列管理线程等待，更灵活。

7. 性能：JDK 6 后 synchronized 引入偏向锁、轻量级锁等优化，性能与 ReentrantLock 接近。但在高并发且竞争激烈时，ReentrantLock 因可控制锁粒度和公平性，性能可能更优；低并发时两者差异不大。

面试关键点：显式/隐式锁的操作差异；可中断、超时、公平锁等功能特性；条件变量的灵活性；底层实现（monitor vs AQS）；性能对比及适用场景。

记忆法：可通过"synchronized 隐式自管理，ReentrantLock 显式需手动；中断超时公平锁，条件变量 Reentrant 强；底层 monitor 对 AQS，功能灵活选显式"来记忆，概括核心区别。

Java 中实现锁的方式有哪些？（对比显式锁与 synchronized 的差异）

Java 中实现锁的方式多样，可分为内置锁、显式锁、原子操作及分布式锁等，其中显式锁与 synchronized（内置锁）的差异是核心考点，具体如下：

实现锁的主要方式：

1. synchronized 关键字：Java 内置的隐式锁，通过修饰方法或代码块实现，依赖 JVM 监视器机制，自动获取和释放锁，无需手动操作。
2. 显式锁（Lock 接口实现类）：如 ReentrantLock、ReentrantReadWriteLock 等，需手动调用 lock() 和 unlock() 管理锁，基于 AQS 实现，功能更丰富。
3. 原子类（CAS 操作）：如 AtomicInteger、AtomicReference 等，基于 CAS（Compare-And-Swap）实现无锁同步，通过硬件原子操作保证线程安全。
4. volatile + CAS：结合 volatile 的可见性和 CAS 的原子性，实现轻量级同步（如 ConcurrentHashMap 中的部分操作）。
5. 分布式锁：如基于 Redis、ZooKeeper 实现的跨进程锁，用于分布式系统中多节点的同步（非 JVM 内置，依赖中间件）。

显式锁与 synchronized 的核心差异：

维度	synchronized	显式锁（如 ReentrantLock）
锁的管理方式	隐式（自动获取/释放）	显式（需手动调用 lock()/unlock()）
可中断性	不可中断（等待锁的线程无法响应中断）	可中断（lockInterruptibly() 支持中断）
超时获取锁	不支持	支持（tryLock(long timeout)）
公平锁支持	仅非公平锁	可通过构造函数指定公平/非公平
条件变量	单一（依赖对象的 wait()/notify()）	多条件变量（Condition），支持精细通信
锁类型扩展	仅排他锁	支持读写锁（ReentrantReadWriteLock）
底层实现	基于 JVM 监视器（monitor）	基于 AQS 框架（状态变量 + 等待队列）
性能（高并发）	优化后接近显式锁，但灵活性受限	竞争激烈时性能更优，锁粒度可控
适用场景	简单同步场景，代码简洁	复杂同步场景（如中断、超时、读写分离）

举例说明差异：

• 超时获取锁：显式锁可避免死锁，如 if (lock.tryLock(1, TimeUnit.SECONDS)) { ... }，synchronized 无此功能。
• 读写分离：ReentrantReadWriteLock 允许多个读线程并发访问，写线程独占，适合读多写少场景，synchronized 仅支持排他锁，读操作也会阻塞。
• 多条件等待：显式锁的 Condition 可实现不同条件的线程等待（如生产者-消费者模型中，分别等待"非空"和"非满"条件），synchronized 需创建多个对象锁才能实现类似功能。

面试关键点：Java 中锁的多种实现方式；显式锁与 synchronized 在功能、操作、性能上的差异；不同锁的适用场景（如读写锁适合读多写少）。

记忆法：可通过"内置锁隐式简，显式锁手动强；中断超时公平选，条件多组读写分；场景简单用 sync，复杂功能显式强"来记忆，概括核心差异和适用场景。

volatile 关键字的作用是什么？在内存层面上如何实现？它的使用场景是什么？

volatile 是 Java 中用于修饰变量的关键字，主要作用是保证变量的可见性和有序性，但不保证原子性，是轻量级的线程同步机制。

核心作用：

1. 保证可见性：当一个线程修改了 volatile 修饰的变量，其他线程能立即看到该变量的最新值。在多线程环境中，线程会将变量从主内存加载到工作内存（CPU 缓存）中操作，非 volatile 变量的修改可能仅停留在工作内存，未及时刷新到主内存，导致其他线程读取旧值。volatile 变量的修改会立即刷新到主内存，且其他线程读取时会从主内存重新加载，避免缓存不一致。

2. 禁止指令重排序：编译器或 CPU 为优化性能，可能对指令重排序（不改变单线程语义的前提下调整执行顺序）。volatile 变量通过内存屏障阻止重排序，确保代码执行顺序与源码一致。例如，在双重检查锁定实现单例模式时，volatile 可防止初始化对象的指令被重排序，避免其他线程获取未完全初始化的对象。

3. 不保证原子性：volatile 无法保证复合操作的原子性（如 i++，包含读取、修改、写入三步）。多线程并发执行 i++ 时，可能出现多个线程读取同一值，导致结果错误。

内存层面的实现 ：

volatile 的可见性和有序性通过"内存屏障"（Memory Barrier）实现，JVM 会为 volatile 变量的读写操作插入特定的内存屏障指令，限制指令重排序并保证内存可见性：

• 写屏障（Store Barrier）：当线程写入 volatile 变量时，会触发写屏障，将工作内存中的变量值刷新到主内存，并使其他线程中该变量的缓存失效（通过 MESI 缓存一致性协议）。
• 读屏障（Load Barrier）：当线程读取 volatile 变量时，会触发读屏障，从主内存重新加载变量值到工作内存，确保读取的是最新值。
• 重排序限制：写屏障禁止之前的指令重排序到屏障之后，读屏障禁止之后的指令重排序到屏障之前，保证指令执行顺序。

使用场景：

1. 状态标记量：用于标记线程的运行状态（如停止信号），确保一个线程修改状态后，其他线程能立即感知。示例：

   private volatile boolean isRunning = true;

   public void stop() {
   isRunning = false; // 线程 A 修改
   }

   public void run() {
   while (isRunning) { // 线程 B 立即看到最新值
   // 执行任务
   }
   }

2. 双重检查锁定（DCL）单例：防止指令重排序导致的单例对象未完全初始化问题。示例：

   public class Singleton {
   private static volatile Singleton instance; // 必须加 volatile

    private Singleton() {}
   
    public static Singleton getInstance() {
        if (instance == null) { // 第一次检查
            synchronized (Singleton.class) {
                if (instance == null) { // 第二次检查
                    instance = new Singleton(); // 防止重排序
                }
            }
        }
        return instance;
    }

   }

3. 与 CAS 结合实现非阻塞同步：如原子类（AtomicInteger）的内部变量 value 被 volatile 修饰，配合 CAS 操作实现线程安全的自增/自减。

面试关键点：volatile 的三大特性（可见性、有序性、非原子性）；内存屏障的作用（刷新主内存、禁止重排序）；典型使用场景（状态标记、DCL 单例）；与 synchronized 的区别（volatile 更轻量，无锁竞争）。

记忆法：可通过"volatile 保可见，禁重排，不原子；内存屏障来实现，写刷内存读加载；状态标记 DCL 用，轻量同步场景适"来记忆，概括核心作用和使用场景。

两个线程同时写一个 volatile 修饰的变量，第二个线程读到的值是多少？若一个线程更新了变量，其他线程的变量副本会失效，这是如何实现的？

两个线程同时写一个 volatile 修饰的变量时，第二个线程读到的值不确定，可能是第一个线程写入的值、自己写入的值，或其他中间值。这是因为 volatile 仅保证可见性和有序性，不保证原子性，无法避免"写覆盖"问题。

具体来说，变量的写入操作（如 i = i + 1）包含三个步骤：读取变量当前值、修改值、写入新值。当两个线程同时执行时，可能出现以下情况：

• 线程 A 读取值为 0，线程 B 也读取值为 0。
• 线程 A 计算得 1 并写入（volatile 保证写入主内存）。
• 线程 B 计算得 1 并写入，覆盖线程 A 的结果。
  此时第二个线程（假设为 B）读到的值是 1，但实际应是 2，出现数据丢失。因此，volatile 无法保证复合操作的线程安全，需结合锁或原子类（如 AtomicInteger）解决。

一个线程更新 volatile 变量后，其他线程的变量副本会失效，这通过"缓存一致性协议"和"内存屏障"共同实现：

1. 缓存一致性协议（如 MESI 协议）：现代 CPU 采用该协议保证多个缓存（线程的工作内存）中共享变量的一致性。当一个 CPU 核心（对应线程）修改了 volatile 变量，会将该变量的缓存行标记为"无效"（Invalid）。其他 CPU 核心在读取该变量时，会检测到缓存行无效，放弃本地缓存的旧值，从主内存重新加载最新值，确保读取的是更新后的数据。

2. 内存屏障（Memory Barrier）：JVM 为 volatile 变量的写操作插入"写屏障"，确保修改后的值立即刷新到主内存；为读操作插入"读屏障"，确保读取时从主内存加载，而非本地缓存。写屏障还会触发 CPU 发送"缓存无效"信号，通知其他核心该变量的缓存已失效，强制它们重新同步。

例如，线程 A 写入 volatile 变量 flag = true：

• 写屏障触发，flag 的新值从线程 A 的工作内存刷新到主内存。
• CPU 发送信号，标记其他线程中 flag 的缓存为无效。
• 线程 B 读取 flag 时，读屏障触发，检测到缓存无效，从主内存加载 true，而非旧值 false。

这种机制保证了 volatile 变量的可见性，但无法解决并发写入的原子性问题，因此仅适用于单写多读或状态标记的场景。

面试关键点：volatile 不保证原子性导致的写覆盖问题；缓存一致性协议（MESI）的作用；内存屏障在刷新主内存和失效缓存中的作用；volatile 可见性的实现细节。

记忆法：可通过"volatile 双写值不定，原子操作它不行；更新变量发信号，缓存失效 others 清；主存刷新靠屏障，可见性保原子零"来记忆，概括核心结论和实现机制。

什么是 CAS 操作？其原理是什么？在操作系统层面如何实现？

CAS（Compare-And-Swap，比较并交换）是一种无锁同步机制，通过原子操作实现多线程环境下的变量更新，无需使用锁，能减少线程阻塞带来的开销。

CAS 的定义：CAS 操作包含三个操作数------内存地址（V）、预期值（A）和新值（B）。操作逻辑是：若内存地址 V 中的值等于预期值 A，则将该值更新为 B；否则不做任何操作。整个过程是原子性的，不会被其他线程中断，最终返回操作是否成功（或内存中的实际值）。

核心原理：CAS 基于乐观锁思想，假设并发操作不会频繁冲突，因此不预先加锁，而是通过原子操作直接尝试更新，若失败则重试（自旋），直到成功或放弃。这种方式避免了锁竞争导致的线程阻塞，适合竞争不激烈的场景。

Java 中通过 sun.misc.Unsafe 类的 native 方法实现 CAS，如 compareAndSwapInt(Object o, long offset, int expected, int x)，其中：

• o 是目标对象，offset 是变量在对象内存中的偏移量（确定 V 的位置）。

• expected 是预期值（A），x 是新值（B）。
  示例（模拟 CAS 自增）：

  public class CASDemo {
  private static final Unsafe unsafe = Unsafe.getUnsafe();
  private static final long valueOffset;
  private volatile int value;

    static {
        try {
            valueOffset = unsafe.objectFieldOffset(CASDemo.class.getDeclaredField("value"));
        } catch (Exception e) {
            throw new Error(e);
        }
    }
  
    public int incrementAndGet() {
        int current;
        do {
            current = value; // 读取当前值（A）
        } while (!unsafe.compareAndSwapInt(this, valueOffset, current, current + 1)); // CAS 尝试更新
        return current + 1;
    }

  }

上述代码中，incrementAndGet 方法通过循环 CAS 实现原子自增：读取当前值，若 CAS 失败（说明值被其他线程修改），则重新读取并重试，直到成功。

操作系统层面的实现 ：

CAS 的原子性依赖底层 CPU 指令支持，不同架构的 CPU 提供了对应的原子操作指令：

• x86 架构：通过 cmpxchg（Compare and Exchange）指令实现，该指令在执行时会锁定总线（或缓存行），确保操作原子性。若内存中的值与预期值一致，则将新值写入；否则将内存中的实际值返回，不修改。
• ARM 架构：通过 ldrex（Load Exclusive）和 strex（Store Exclusive）指令组合实现。ldrex 加载值并标记排他访问，strex 仅当排他标记未被其他线程修改时才写入新值，确保原子性。

这些 CPU 指令是原子的，不会被中断，因此 CAS 操作在操作系统层面通过硬件保证了多线程环境下的原子性，无需依赖软件锁。

但 CAS 存在"ABA 问题"（变量从 A 变为 B 再变回 A，CAS 误认为未修改），可通过版本号机制（如 AtomicStampedReference）解决；此外，长期自旋可能浪费 CPU 资源，适合短期操作。

面试关键点：CAS 的三要素（V、A、B）及操作逻辑；乐观锁思想与自旋机制；Java 中 Unsafe 类的作用；CPU 指令（如 cmpxchg）的底层支持；ABA 问题及解决方式。

记忆法：可通过"CAS 比较再交换，V、A、B 三要素；内存值等预期值，更新新值原子做；底层依赖 CPU 令，无锁自旋效率高；ABA 问题版本解，乐观并发场景适"来记忆，概括核心原理和实现。

CAS 操作会自旋吗？如果自旋，就一定会成功吗？CAS 存在什么问题？如何解决 ABA 问题？

CAS 操作本身不会自旋，自旋是基于 CAS 实现的同步逻辑中常见的重试策略。CAS 是单次原子操作（比较并交换），而自旋指的是当 CAS 操作失败时，线程通过循环不断重试 CAS 直到成功或放弃，典型如原子类（AtomicInteger）的 incrementAndGet 方法：

public final int incrementAndGet() {
    int current;
    do {
        current = get(); // 读取当前值
    } while (!compareAndSet(current, current + 1)); // 自旋重试 CAS
    return current + 1;
}

这里的 do-while 循环就是自旋，目的是在 CAS 失败（值被其他线程修改）时重新尝试，直到成功。

自旋不一定会成功。若多个线程高频竞争同一变量，可能导致某个线程的自旋长期失败（始终被其他线程抢先修改），极端情况下甚至一直无法成功，造成 CPU 资源浪费。因此，自旋通常会设置重试次数上限（如 JUC 中的自适应自旋），避免无限循环。

CAS 存在以下问题：

1. ABA 问题：变量的值从 A 被修改为 B，再改回 A，CAS 会误认为值未变化而成功更新，可能导致逻辑错误。例如，链表节点被删除后重新插入，CAS 操作可能误判节点状态。
2. 自旋开销：高并发下，自旋重试会占用大量 CPU 资源，降低系统性能。
3. 只能保证单个变量的原子性：CAS 仅能对单个变量执行原子操作，无法直接保证多个变量的复合操作（如 i++ && j--）的原子性。

解决 ABA 问题的核心是引入版本号机制，通过记录变量的修改次数，避免仅通过值判断状态。Java 中 AtomicStampedReference 类就是典型实现，它将变量值与版本号绑定，CAS 操作时同时检查值和版本号：

// 初始化：值为100，版本号为1
AtomicStampedReference<Integer> asr = new AtomicStampedReference<>(100, 1);

// 尝试更新：预期值100，新值200；预期版本1，新版本2
boolean success = asr.compareAndSet(100, 200, 1, 2);

只有当变量当前值为 100 且版本号为 1 时，才会更新为 200 并将版本号改为 2。即使值从 100→200→100，版本号也会从 1→2→3，CAS 会因版本号不匹配而失败，解决 ABA 问题。

面试关键点：CAS 与自旋的关系（自旋是基于 CAS 的重试策略）；自旋的不确定性；CAS 的三大问题（ABA、自旋开销、单变量限制）；ABA 问题的版本号解决思路及 AtomicStampedReference 的使用。

记忆法：可通过"CAS 本身不自旋，自旋是重试；自旋未必成，高并发耗 CPU；ABA 问题值反复，版本号来防护；单变量原子限，复合操作需其他"来记忆，概括核心问题及解决方式。

CAS 和 Lock 的性能消耗相比，哪个更好？

CAS 和 Lock 的性能消耗无法绝对比较，需结合并发场景（竞争程度、操作耗时）判断，两者各有优势场景：

低并发、短操作场景下，CAS 性能更优。CAS 是无锁机制，基于 CPU 原子指令实现，无需线程阻塞/唤醒（用户态操作），开销主要来自自旋重试。当并发程度低、线程冲突少（如偶尔有线程修改共享变量），CAS 的自旋次数少，甚至一次成功，避免了 Lock 的锁竞争、线程切换（内核态操作）开销。例如，单线程或少量线程更新计数器时，AtomicInteger（基于 CAS）的性能远高于 ReentrantLock 保护的普通变量。

高并发、长操作场景下，Lock 性能更优。当并发激烈（大量线程竞争同一资源）或操作耗时较长（如复杂计算、IO 操作），CAS 的自旋会成为负担：线程不断重试 CAS 却频繁失败，导致 CPU 空转（自旋本质是"忙等"），浪费资源。而 Lock（如 ReentrantLock）在竞争失败时会将线程阻塞（通过 LockSupport.park()），释放 CPU 资源给其他线程，减少无效消耗。例如，大量线程并发写入数据库时，使用 Lock 控制并发比 CAS 自旋更高效。

具体差异可从底层开销分析：

• CAS 开销：主要是 CPU 自旋（循环执行 CAS 指令），无内核态切换，但高并发下自旋次数激增，CPU 利用率飙升。
• Lock 开销：包含锁竞争（CAS 尝试获取锁）、线程阻塞/唤醒（内核态操作，开销较大），但竞争激烈时可避免 CPU 空转，资源利用率更合理。

此外，操作耗时影响选择：短操作（如变量自增）适合 CAS，自旋成本低；长操作（如批量数据处理）适合 Lock，避免长时间自旋浪费 CPU。

示例场景对比：

• 计数器更新（短操作，低并发）：CAS 性能 > Lock，因自旋少，无阻塞开销。
• 订单创建（长操作，高并发）：Lock 性能 > CAS，因避免大量线程自旋，减少 CPU 浪费。

面试关键点：CAS 与 Lock 性能的场景依赖性；低并发短操作 CAS 更优的原因（无阻塞）；高并发长操作 Lock 更优的原因（减少自旋）；底层开销差异（用户态自旋 vs 内核态切换）。

记忆法：可通过"低并发短操作，CAS 无锁更轻快；高并发长操作，Lock 阻塞省资源；场景决定优劣势，竞争耗时是关键"来记忆，概括性能对比的核心逻辑。

JUC 的底层实现原理是什么？（可从 Unsafe 类、LockSupport、原子类、AQS 逐步说明）

JUC（java.util.concurrent）是 Java 并发编程的核心工具包，其底层依赖多个核心组件协同工作，从基础到上层依次为 Unsafe 类、LockSupport、原子类和 AQS，构成了并发工具的实现基础：

1. Unsafe 类：JUC 的"底层引擎"，提供直接操作内存和线程的 native 方法，是实现 CAS、线程挂起/唤醒等功能的基础。它通过内存偏移量直接访问对象字段（绕过 JVM 安全检查），主要功能包括：

   • CAS 操作：如 compareAndSwapInt，为原子类和 AQS 提供原子更新能力。
   • 线程操作：park() 和 unpark() 方法，用于线程的挂起和唤醒（被 LockSupport 封装）。
   • 内存操作：直接分配/释放内存（如 allocateMemory）、获取对象字段偏移量（如 objectFieldOffset），为定位变量内存地址提供支持。
     Unsafe 类是 JUC 实现无锁同步和高效线程控制的核心依赖。

2. LockSupport：线程阻塞/唤醒的工具类，封装了 Unsafe 的 park() 和 unpark() 方法，提供更安全的线程控制。与 Thread.suspend()/resume() 相比，它避免了线程悬挂（suspend 可能导致锁资源泄露），支持中断响应和超时控制。JUC 中的锁（如 ReentrantLock）和同步器在竞争失败时，通过 LockSupport.park() 挂起线程，获取资源后通过 LockSupport.unpark(thread) 唤醒，是线程等待/通知机制的底层实现。

3. 原子类：如 AtomicInteger、AtomicReference 等，基于 Unsafe 的 CAS 操作实现线程安全的原子更新。它们通过自旋 CAS 机制（循环重试 CAS 直到成功）保证变量的原子修改，无需加锁，适用于简单同步场景。例如，AtomicInteger 的 incrementAndGet() 方法通过 CAS 实现原子自增，底层调用 Unsafe 的 compareAndSwapInt。

4. AQS（AbstractQueuedSynchronizer）：JUC 同步工具的"框架基石"，定义了基于状态变量（state）和双向队列（CLH 队列）的同步模板。其核心思想是：

   • 用 volatile 变量 state 表示同步状态（如锁的持有计数）。
   • 用双向队列存储竞争失败的线程，实现线程排队等待。
   • 提供模板方法（如 acquire()、release()），子类通过实现 tryAcquire()、tryRelease() 等方法定制同步逻辑。
     JUC 中的 ReentrantLock、CountDownLatch、Semaphore 等均基于 AQS 实现：
   • ReentrantLock：state 表示锁的重入次数，tryAcquire() 实现锁的获取逻辑。
   • CountDownLatch：state 表示计数器值，tryReleaseShared() 实现计数器递减。

这些组件的协作关系：AQS 依赖 Unsafe 操作 state 和队列节点，通过 LockSupport 挂起/唤醒队列中的线程；原子类直接使用 Unsafe 的 CAS 操作；LockSupport 封装 Unsafe 的线程操作。这种分层设计使 JUC 工具兼具高效性和灵活性。

面试关键点：Unsafe 的核心功能（CAS、线程操作）；LockSupport 的线程控制作用；原子类的 CAS 实现；AQS 的状态变量和队列机制；各组件的协作关系。

记忆法：可通过"JUC 底层四件套，Unsafe 引擎最关键；LockSupport 管挂醒，原子类靠 CAS 转；AQS 框架定模板，状态队列承上边"来记忆，概括核心组件及作用。

AQS（AbstractQueuedSynchronizer）的底层实现原理是什么？AQS 是否可以实现非公平锁？

AQS（AbstractQueuedSynchronizer）是 JUC 中同步工具的基础框架，底层通过"状态变量 + 双向同步队列"实现线程同步，核心是对共享资源的竞争与等待机制。

底层实现原理：

1. 核心状态变量（state）：AQS 用 volatile 修饰的 state 变量表示共享资源的同步状态（如锁的持有次数、计数器值），确保多线程间的可见性。线程通过 CAS 操作修改 state 竞争资源，如获取锁时 state 从 0→1（非重入）或递增（重入），释放锁时递减或重置。

2. 双向同步队列（CLH 队列）：当线程竞争资源失败（CAS 修改 state 失败），会被包装为 Node 节点加入队列尾部，进入等待状态。队列采用双向链表结构，每个 Node 包含：

   • 线程引用（thread）：等待资源的线程。
   • 等待状态（waitStatus）：如 CANCELLED（已取消）、SIGNAL（需唤醒后继节点）。
   • 前驱节点（prev）和后继节点（next）：维护队列结构。
     队列头部（head）是已获取资源的线程节点，其他节点等待被唤醒。

3. 模板方法设计：AQS 定义了获取/释放资源的模板方法（如 acquire()、release()），封装了队列管理逻辑，子类只需实现 tryAcquire(int arg)（独占式获取）、tryRelease(int arg)（独占式释放）等抽象方法，定制资源竞争规则。

4. 线程等待/唤醒：竞争失败的线程通过 LockSupport.park() 挂起，进入阻塞状态；持有资源的线程释放资源时，通过 LockSupport.unpark() 唤醒队列中的后继线程，使其重新竞争资源。

AQS 可以实现非公平锁 ，且多数基于 AQS 的同步工具（如 ReentrantLock 默认模式）都实现了非公平锁。非公平锁的核心是"抢锁"机制：线程获取资源时，不遵守队列顺序，直接尝试 CAS 修改 state，成功则获取资源；失败才加入队列等待。

以 ReentrantLock 的非公平锁实现为例：

• tryAcquire() 方法首先尝试 CAS 修改 state（不检查队列），若当前线程是锁的持有者则重入（state 递增）。
• 只有 CAS 失败且当前线程不是持有者时，才会加入队列。
  这种设计允许新线程"插队"获取资源，可能导致队列中的线程饥饿，但减少了线程切换开销，性能通常高于公平锁。

公平锁则在 tryAcquire() 中检查队列是否有前驱节点，若有则放弃竞争，直接入队，严格按顺序获取资源，保证公平性但牺牲部分性能。

面试关键点：AQS 的核心组成（state 变量、CLH 队列）；模板方法与子类实现的分工；非公平锁的"抢锁"逻辑；ReentrantLock 中非公平锁的实现方式。

记忆法：可通过"AQS 状态加队列，线程竞争靠 CAS；获取释放模板定，子类实现 try 方法；非公平锁可实现，抢锁优先于队列；公平则按顺序来，性能公平难两全"来记忆，概括底层原理和非公平锁实现。

什么是线程池？创建一个线程池需要哪些参数？各参数的作用是什么？

线程池是管理线程生命周期的容器，通过重用已创建的线程减少频繁创建/销毁线程的开销（线程创建需分配栈内存、内核资源，销毁需回收资源），提高系统响应速度和资源利用率，是 Java 并发编程中控制并发量的核心工具。

创建线程池的核心类是 ThreadPoolExecutor，其构造函数定义了 7 个核心参数，各参数决定了线程池的行为特性：

1. corePoolSize（核心线程数） ：线程池长期维持的最小线程数，即使线程空闲也不会被销毁（除非设置 allowCoreThreadTimeOut 为 true）。当新任务提交时，若当前线程数小于 corePoolSize，线程池会创建新线程执行任务；若达到 corePoolSize，则将任务放入队列。

2. maximumPoolSize（最大线程数）：线程池允许创建的最大线程数，用于应对任务高峰期。当任务队列满且当前线程数小于 maximumPoolSize 时，线程池会创建新线程（非核心线程）执行任务；若达到 maximumPoolSize，触发拒绝策略。

3. keepAliveTime（空闲线程存活时间） ：非核心线程的空闲超时时间。当非核心线程空闲时间超过该值，会被销毁以释放资源；若 allowCoreThreadTimeOut 为 true，核心线程也会遵守该超时时间。

4. unit（时间单位） ：keepAliveTime 的时间单位，如 TimeUnit.SECONDS（秒）、TimeUnit.MILLISECONDS（毫秒）等。

5. workQueue（任务队列）：用于存放待执行任务的阻塞队列，当核心线程都在工作时，新任务会进入队列等待。常用队列类型：

   • ArrayBlockingQueue：有界数组队列，需指定容量，防止任务无限堆积。
   • LinkedBlockingQueue：无界链表队列（默认容量 Integer.MAX_VALUE），可能导致内存溢出。
   • SynchronousQueue：直接传递队列，不存储任务，需立即有线程接收，适合任务处理快的场景。

6. threadFactory（线程工厂） ：用于创建线程的工厂，可定制线程名称、优先级、是否为守护线程等。默认使用 Executors.defaultThreadFactory()，创建的线程属于同一线程组，优先级为正常。

7. handler（拒绝策略）：当任务队列满且线程数达到 maximumPoolSize 时，对新提交任务的处理策略。JDK 提供 4 种默认策略：

   • AbortPolicy：直接抛出 RejectedExecutionException（默认策略）。
   • CallerRunsPolicy：让提交任务的线程自己执行任务，减缓提交速度。
   • DiscardPolicy：默默丢弃新任务，不抛出异常。
   • DiscardOldestPolicy：丢弃队列中最旧的任务，尝试提交新任务。

示例（创建自定义线程池）：

ThreadPoolExecutor executor = new ThreadPoolExecutor(
    5, // corePoolSize：5个核心线程
    10, // maximumPoolSize：最多10个线程
    60, // keepAliveTime：空闲线程存活60秒
    TimeUnit.SECONDS, // 时间单位：秒
    new ArrayBlockingQueue<>(20), // 任务队列：容量20的有界队列
    Executors.defaultThreadFactory(), // 线程工厂：默认
    new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略：调用者执行
);

这些参数共同决定了线程池的负载能力和资源控制策略，合理配置可避免线程耗尽或内存溢出，是面试中的高频考点。

面试关键点：线程池的作用（重用线程、控制并发）；7个核心参数的含义及相互关系；任务队列和拒绝策略的类型及适用场景；参数配置对线程池行为的影响。

记忆法：可通过"核心线程常驻留，最大线程限峰值；空闲超时非核心，队列存任务；工厂造线程，拒绝策略满时用；七参定池性，合理配置是关键"来记忆，概括参数作用和线程池特性。

当有任务提交时，线程池的运行原理是什么？为什么线程池会先将任务加入队列，再创建最大线程数的线程？

当有任务提交到线程池时，其运行原理遵循一套优先级明确的处理流程，核心是通过"核心线程→任务队列→非核心线程→拒绝策略"的顺序高效分配资源，具体如下：

1. 检查核心线程：当任务提交时，线程池首先判断当前运行的线程数是否小于 corePoolSize（核心线程数）。若小于，直接创建新的核心线程执行任务（核心线程创建后长期驻留，除非设置 allowCoreThreadTimeOut 为 true）；若已达到 corePoolSize，则进入下一步。

2. 尝试加入任务队列：线程池检查任务队列（workQueue）是否未满。若未满，将任务放入队列等待执行（由已有的核心线程或后续空闲线程处理）；若队列已满，则进入下一步。

3. 检查最大线程数：判断当前线程数是否小于 maximumPoolSize（最大线程数）。若小于，创建非核心线程执行任务（非核心线程空闲时会被回收）；若已达到 maximumPoolSize，则触发拒绝策略（由 handler 处理）。

这种流程设计的核心原因是"优先利用现有资源，减少线程创建开销"。线程的创建和销毁需要消耗系统资源（如分配栈内存、内核态与用户态切换），频繁创建线程会显著降低性能。任务队列的作用是缓冲任务，让核心线程充分利用（核心线程常驻，无需频繁销毁），只有当队列满了（说明核心线程已饱和），才会创建非核心线程应对峰值，避免不必要的线程资源浪费。

例如，核心线程数为4、队列容量为20、最大线程数为8的线程池：当提交第5个任务时，核心线程已满，任务进入队列；提交第25个任务时，队列已满，此时创建第5个线程（非核心）；直到线程数达到8，第29个任务会触发拒绝策略。

若反过来"先创建最大线程数再入队"，会导致轻微任务增长就创建大量线程，不仅浪费资源，还可能因线程过多导致上下文切换频繁，降低系统吞吐量。因此，"先入队再扩容"是平衡资源利用率和性能的最优设计。

面试关键点：线程池处理任务的四步流程（核心线程→队列→非核心线程→拒绝策略）；队列的缓冲作用；优先入队的原因（减少线程创建开销，提高资源利用率）。

记忆法：可通过"任务提交先看核心线，不满直接来处理；核心满了入队列，队列满了扩线程；扩到最大还满了，拒绝策略来兜底；先入队再扩线程，减少开销效率高"来记忆，概括运行原理和设计逻辑。

若线程池参数设置为 corePoolSize=4、maxPoolSize=8，什么情况下会从 4 个线程扩容到 8 个线程？

当线程池参数为 corePoolSize=4、maxPoolSize=8 时，线程数从4扩容到8的触发条件是"核心线程全忙碌 + 任务队列已满 + 新任务持续提交"，具体过程如下：

1. 初始状态：线程池启动后，若有任务提交，会先创建核心线程，直到达到 corePoolSize=4。此时4个核心线程处理任务，新提交的任务会进入线程池的任务队列等待（假设队列有界，如容量为N）。

2. 核心线程饱和：当4个核心线程都在处理任务（无空闲），且新提交的任务不断进入队列，直到队列被填满（达到容量N）。此时队列无法再接收新任务，线程池进入"扩容准备"状态。

3. 触发扩容：当队列已满后，若有新任务继续提交，线程池会判断当前线程数（4）是否小于 maxPoolSize（8）。由于4 < 8，线程池会创建新的非核心线程处理新任务，每次提交新任务可能触发一次扩容，直到线程数达到8。

4. 扩容上限：当线程数达到8（maxPoolSize），若仍有新任务提交，队列已满且无法再创建线程，线程池会执行拒绝策略（如抛出异常、丢弃任务等）。

举例说明：假设任务队列容量为10，核心线程4个均忙碌。当第5-14个任务提交时，会进入队列（共10个任务）；第15个任务提交时，队列已满，线程池创建第5个线程；第16个任务创建第6个线程......直到第18个任务提交时，线程数达到8，之后的任务触发拒绝策略。

需注意，若任务队列是无界队列（如 LinkedBlockingQueue 默认容量为 Integer.MAX_VALUE），则队列永远不会满，线程数不会超过 corePoolSize=4，不会触发扩容（这也是不建议使用无界队列的原因之一，可能导致内存溢出）。只有使用有界队列且队列满时，才可能触发从核心线程数到最大线程数的扩容。

面试关键点：扩容的三大条件（核心线程满、队列满、新任务提交）；有界队列的重要性（无界队列无法触发扩容）；扩容的上限是 maxPoolSize。

记忆法：可通过"核心满，队列满，新任务来要扩容；core4到max8，条件缺一都不行；无界队列不扩容，有界满了才加线"来记忆，概括扩容的触发条件和限制。

线程池中是如何根据 keepAliveTime 来回收线程的？

线程池通过 keepAliveTime 回收线程的机制，主要针对非核心线程（默认），核心线程需特殊配置才会被回收，其底层通过监控线程空闲时间并主动中断实现，具体过程如下：

1. 回收对象：默认情况下，keepAliveTime 仅作用于非核心线程（即线程数超过 corePoolSize 的部分）。核心线程会长期驻留，即使空闲也不会被回收，以快速响应新任务。若需回收核心线程，需调用 allowCoreThreadTimeOut(true) 方法，此时核心线程也会遵守 keepAliveTime 规则。

2. 空闲时间监控：线程池中的工作线程在执行完任务后，会进入循环获取队列中任务的状态。若队列中没有任务，线程会进入空闲状态，此时开始计时。当空闲时间达到 keepAliveTime 时，线程会判断是否需要被回收：

   • 若当前线程数 > corePoolSize（非核心线程）：直接退出线程，被系统回收。
   • 若当前线程数 ≤ corePoolSize 且未设置 allowCoreThreadTimeOut：继续等待任务，不回收。
   • 若当前线程数 ≤ corePoolSize 且设置了 allowCoreThreadTimeOut：退出线程，被回收。

3. 回收实现：线程池通过 ThreadPoolExecutor.Worker 类管理工作线程，Worker 是一个内部类，实现了 Runnable 接口。Worker 线程的 run 方法会循环调用 getTask() 方法从队列获取任务：

   • getTask() 方法在队列无任务时，会调用 LockSupport.parkNanos(keepAliveTime) 使线程阻塞指定时间。
   • 若阻塞时间内仍无任务，getTask() 返回 null，Worker 线程退出循环，run 方法结束，线程被回收。

示例逻辑（简化的 getTask() 核心代码）：

private Runnable getTask() {
    boolean timedOut = false;
    while (true) {
        int c = ctl.get();
        // 检查是否需要回收线程
        if (runStateAtLeast(c, SHUTDOWN) && (runStateAtLeast(c, STOP) || workQueue.isEmpty())) {
            decrementWorkerCount();
            return null;
        }
        int wc = workerCountOf(c);
        // 判断是否需要超时等待（非核心线程或允许核心线程超时）
        boolean timed = allowCoreThreadTimeOut || wc > corePoolSize;
        // 若超时且符合回收条件，返回null触发线程回收
        if ((wc > maximumPoolSize || (timed && timedOut)) && (wc > 1 || workQueue.isEmpty())) {
            if (compareAndDecrementWorkerCount(c))
                return null;
            continue;
        }
        try {
            // 阻塞等待任务，超时返回null
            Runnable r = timed ? workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS) : workQueue.take();
            if (r != null)
                return r;
            timedOut = true; // 标记超时
        } catch (InterruptedException retry) {
            timedOut = false;
        }
    }
}

这种机制确保线程池在任务量减少时自动释放多余资源，避免空闲线程占用内存和CPU，平衡了资源利用率和响应速度。

面试关键点：keepAliveTime 对非核心线程的默认作用；核心线程回收的条件（allowCoreThreadTimeOut=true）；getTask() 方法的超时等待与线程退出逻辑；回收的底层实现（Worker 线程循环与阻塞）。

记忆法：可通过"keepAlive 管空闲，默认只收非核心；核心要收需配置，allowCoreTimeout 真；线程空闲超时后，getTask 返回 null，Worker 退出被回收"来记忆，概括回收机制和条件。

线程池的拒绝策略有哪些？哪种拒绝策略不会导致任务丢失？（例如 callerRunsPolicy）

线程池的拒绝策略是当任务队列满且线程数达到 maximumPoolSize 时，对新提交任务的处理机制。JDK 内置了4种拒绝策略，每种策略的行为和适用场景不同，具体如下：

1. AbortPolicy（默认策略）：直接抛出 RejectedExecutionException 异常，中断任务提交流程。这种策略的优点是快速反馈错误，让开发者及时感知系统过载；缺点是会导致当前任务丢失，适用于不允许任务丢失且需立即处理错误的场景（如金融交易）。

2. CallerRunsPolicy：让提交任务的线程（调用者线程）亲自执行该任务。例如，主线程提交任务被拒绝时，主线程会暂停当前工作，执行被拒绝的任务，执行完成后再继续。这种策略的优点是不会丢失任务，且通过减慢调用者的提交速度（调用者忙于执行任务），间接降低任务提交频率，给线程池缓冲时间；缺点是可能阻塞调用者线程，影响其他任务提交，适用于任务量不大、需保证任务不丢失的场景（如日志记录）。

3. DiscardPolicy：默默丢弃被拒绝的任务，不抛出任何异常，也不执行该任务。优点是不会中断系统运行；缺点是任务丢失且无任何提示，适用于任务可丢失、对系统稳定性要求高的场景（如非核心统计数据）。

4. DiscardOldestPolicy：丢弃任务队列中最旧的任务（即将被执行的任务），然后尝试提交当前被拒绝的任务。这种策略会丢失旧任务，但可能让新任务有机会执行，适用于旧任务时效性差、新任务更重要的场景（如实时数据处理）。

在这四种策略中，CallerRunsPolicy 是唯一不会导致任务丢失的策略，因为被拒绝的任务会由提交者线程执行，确保任务被处理。其他策略均会导致任务丢失（AbortPolicy 丢失当前任务，DiscardPolicy 丢失当前任务，DiscardOldestPolicy 丢失旧任务）。

实际开发中，也可通过实现 RejectedExecutionHandler 接口自定义拒绝策略，例如将任务持久化到数据库或消息队列，待线程池空闲后重试，进一步保证任务不丢失。

面试关键点：4种内置拒绝策略的行为差异；CallerRunsPolicy 不丢失任务的原因；各策略的适用场景；自定义拒绝策略的可能性。

记忆法：可通过"Abort 抛异常，Caller 自己跑，Discard 悄悄丢，Oldest 丢最老；唯有 Caller 不丢任务，其他策略皆丢失"来记忆，概括各策略特点和任务丢失情况。

线程池拒绝策略的代码是由哪个线程执行的？

线程池拒绝策略的代码由提交任务的线程 执行。当线程池无法处理新提交的任务（队列满且线程数达到 maximumPoolSize），会触发拒绝策略，此时执行拒绝策略中 rejectedExecution(Runnable r, ThreadPoolExecutor executor) 方法的线程，正是调用 execute() 或 submit() 方法提交任务的线程。

这一机制的底层逻辑是：任务提交过程是同步的，提交线程会主动检查线程池状态和资源，若符合拒绝条件，则直接在当前线程中执行拒绝策略代码。具体流程如下：

1. 提交线程调用 executor.execute(task) 提交任务。
2. 线程池内部检查：核心线程是否满→队列是否满→是否可扩容至最大线程数。
3. 若所有条件均不满足（触发拒绝），线程池调用拒绝策略的 rejectedExecution 方法。
4. 由于整个提交过程未涉及线程切换，rejectedExecution 方法由提交任务的线程直接执行。

示例验证：

public class RejectedThreadDemo {
    public static void main(String[] args) {
        // 创建核心线程1、最大线程1、队列容量1的线程池
        ThreadPoolExecutor executor = new ThreadPoolExecutor(
            1, 1, 0, TimeUnit.SECONDS,
            new ArrayBlockingQueue<>(1),
            new ThreadPoolExecutor.AbortPolicy()
        );
        
        // 提交3个任务（必然触发拒绝）
        executor.execute(() -> { try { Thread.sleep(1000); } catch (InterruptedException e) {} });
        executor.execute(() -> { try { Thread.sleep(1000); } catch (InterruptedException e) {} });
        
        // 第三个任务会被拒绝，打印执行拒绝策略的线程
        try {
            executor.execute(() -> System.out.println("任务3"));
        } catch (RejectedExecutionException e) {
            System.out.println("拒绝策略执行线程：" + Thread.currentThread().getName()); 
            // 输出：拒绝策略执行线程：main（即提交任务的主线程）
        }
        executor.shutdown();
    }
}

上述代码中，主线程提交第三个任务时触发拒绝策略，RejectedExecutionException 由主线程抛出，证明拒绝策略代码在主线程中执行。

这一设计的原因是：拒绝策略需要即时反馈任务提交结果，由提交线程执行可避免额外的线程调度开销，且符合"谁提交谁处理"的直观逻辑。若由线程池内部线程执行，可能导致延迟或线程池状态不一致。

面试关键点：拒绝策略由提交任务的线程执行；同步提交过程导致的线程关联；示例验证的核心逻辑。

记忆法：可通过"谁提交任务，谁执行拒绝；同步调用无切换，提交线程担职责"来记忆，概括执行拒绝策略的线程来源。

若将线程池的任务队列设置为无界队列，会对服务产生什么影响？

将线程池的任务队列设置为无界队列（如 LinkedBlockingQueue 未指定容量，默认容量为 Integer.MAX_VALUE），会对服务产生多方面影响，主要体现在资源占用、线程池行为和系统稳定性上：

1. 线程数永远不会超过核心线程数：无界队列可无限接收任务，因此当核心线程（corePoolSize）都在忙碌时，新任务会持续进入队列，不会触发"队列满后创建非核心线程"的逻辑。这意味着线程池中的线程数始终维持在 corePoolSize，maximumPoolSize 参数失去意义，无法通过扩容应对任务峰值。例如，corePoolSize=5、maxPoolSize=20的线程池，若使用无界队列，即使提交1000个任务，线程数也只会保持5个，无法利用更多线程加速处理。

2. 任务堆积可能导致内存溢出（OOM） ：无界队列会无限制存储任务，若任务提交速度远快于处理速度，队列中的任务会持续增长，占用大量堆内存。当内存耗尽时，会抛出 OutOfMemoryError，导致服务崩溃。例如，每个任务占用1KB内存，1000万个任务就会占用约10GB内存，远超普通应用的内存上限。

3. 系统响应延迟加剧：队列中堆积的任务需要等待核心线程处理，任务越多，等待时间越长，系统响应速度变慢。极端情况下，新提交的任务可能需要等待数小时甚至更久才能被执行，违背实时性要求。

4. 拒绝策略失效 ：由于队列永远不会满，线程池的拒绝策略（如 AbortPolicy）永远不会触发，无法通过拒绝机制保护系统。即使任务已经积压到危险程度，线程池仍会接收新任务，加速系统资源耗尽。

5. 排查问题难度增加：任务堆积时，线程池没有明显的错误提示（如拒绝异常），问题可能被掩盖，直到内存溢出才暴露，增加了故障排查的复杂度。

无界队列仅适用于"任务提交速度远低于处理速度，且任务总量可控"的场景（如低频率后台任务），但绝大多数生产环境（尤其是高并发服务）应避免使用，建议采用有界队列（如 ArrayBlockingQueue）并合理设置容量，结合拒绝策略和监控机制，确保系统稳定性。

面试关键点：无界队列对线程数的限制（不超过核心线程）；内存溢出风险；响应延迟和拒绝策略失效的后果；适用场景的局限性。

记忆法：可通过"无界队列无限装，线程不超核心量；任务堆积耗内存，OOM风险高；响应延迟拒策略废，生产环境慎用它"来记忆，概括核心影响。