结论：三者是包含关系，JDK ⊇ JRE ⊇ JVM。

• JVM（Java Virtual Machine）：字节码的执行引擎，负责加载 .class、解释与 JIT 编译、垃圾回收。它是"规范 + 实现"，不同平台有不同实现（HotSpot、OpenJ9 等）。
• JRE（Java Runtime Environment）：JVM + 核心类库 + 运行所需文件。只运行程序，装 JRE 就够。
• JDK（Java Development Kit）：JRE + 开发工具（javac、javap、jar、jconsole 等）。写代码必须装 JDK。

一句话记忆：写代码用 JDK，跑程序用 JRE，跨平台靠 JVM。

延伸： Java 9 模块化之后，官方不再单独提供 JRE 安装包，可以用 jlink 裁剪出自定义运行时镜像。

结论：靠"字节码 + 虚拟机"这一层抽象，跨平台的是编译产物，不是 JVM 本身。

• javac 把 .java 编译成与平台无关的字节码 .class，而不是某个平台的机器码。
• 各平台提供各自实现的 JVM，由 JVM 把同一份字节码翻译成本平台的机器指令。
• 因此 JVM 是平台相关的——不同操作系统要装对应版本的 JVM。

延伸： 严格说跨平台不彻底：依赖本地库（JNI）、文件路径分隔符、换行符、默认字符集等仍可能不兼容。与 C/C++ 对比：C 直接编译成目标平台机器码，每个平台都要重新编译。

延伸： float/double 遵循 IEEE 754，无法精确表示 0.1 这类十进制小数；char 只有 2 字节，表示不了 BMP 之外的字符（如部分 emoji），需要 code point / surrogate pair。

结论：包装类是基本类型的对象形式，两者在存储、默认值、比较和使用场景上都不同。

• 自动装箱/拆箱由编译器插入 valueOf() 和 xxxValue()。
• 空指针陷阱：Integer i = null; int j = i; 拆箱时直接 NPE。

延伸： 包装类不可变，valueOf 带缓存；高频循环里反复装箱会产生大量临时对象，性能敏感处优先用基本类型。

结论：== 比较的是值或引用地址，equals 是方法、语义由类自己定义；Object 的默认实现仍然是 ==。

• 基本类型：== 比较数值。
• 引用类型：== 比较是否指向同一个对象。
• Object.equals 源码就是 return (this == obj);。
• 重写后（String、Integer 等）equals 比较内容。

String a = new String("hi");
String b = new String("hi");
System.out.println(a == b);       // false，两个不同堆对象
System.out.println(a.equals(b));  // true，String 重写了 equals
Integer x = 128, y = 128;
System.out.println(x == y);       // false，超出缓存，是不同对象

延伸： 注意调用方向，用 "常量".equals(变量) 可以避免变量为 null 时抛 NPE。

结论：因为二者有契约——equals 相等的两个对象 hashCode 必须相等，否则基于哈希的集合会失效。

契约三条：

• equals 相等 → hashCode 必相等（强制）。
• hashCode 相等 → equals 不一定相等（允许哈希冲突）。
• 违反第一条，就会出现"两个相等对象被放进不同桶"。

反例：

class User {
    String name;
    @Override public boolean equals(Object o) {   // 只重写 equals
        return o instanceof User && ((User) o).name.equals(name);
    }
    // 未重写 hashCode，仍用 Object 的地址哈希
}
Set<User> set = new HashSet<>();
set.add(new User("tom"));
System.out.println(set.contains(new User("tom")));  // false！

HashMap/HashSet 先按 hashCode 定位桶、再在桶内用 equals 比较；哈希不同就直接分到不同桶，根本走不到 equals。

延伸： equals 里参与比较的字段，hashCode 里也必须参与；工具类用 Objects.hash(...)。这也是 Lombok @EqualsAndHashCode 存在的原因。

结论：String 是 final 类，内部存字符的数组引用是 private final 且从不对外暴露，对象创建后内容不可变。

注意区分：final 只保证数组引用不能重新指向，真正不可变是因为 String 不提供修改数组的方法，也从不把内部数组暴露出去。

设计意义：

• 字符串常量池可安全复用：多个 "a" 指向同一对象；否则共享会被篡改。
• hashCode 可缓存：String 内部缓存了 hash，作为 HashMap 的 key 时性能稳定。
• 线程安全：不可变对象天然线程安全，可无锁共享。
• 适合做 Map 的 key：key 若可变，哈希与桶下标就全乱了。

延伸： Java 9 起底层由 char[] 改为 byte[] + coder 字段（Compact Strings），Latin-1 字符只占 1 字节，显著省内存。反射虽能改数组内容，但那是破坏封装，不改变设计上不可变的结论。

// 循环里用 String 拼接是 O(n²) 的拷贝
String s = "";
for (int i = 0; i < 10000; i++) s += i;   // 每次都在新建对象
// 正确姿势
StringBuilder sb = new StringBuilder();
for (int i = 0; i < 10000; i++) sb.append(i);
String r = sb.toString();

延伸： 编译器会把单条语句里的 + 拼接优化成 StringBuilder；但循环体内的拼接每次迭代都新建，优化失效。StringBuilder 默认容量 16，能预估长度时可指定容量减少扩容。

三者只是拼写像，含义毫无关系。

• final：修饰符。修饰类 → 不可继承；修饰方法 → 不可重写；修饰变量 → 只能赋值一次（基本类型值不可变，引用类型是引用不可重新指向，但对象内容可变）。
• finally：异常处理块，配合 try 使用，通常放资源释放，正常、异常、return 路径都会执行（System.exit 等极端情况除外）。
• finalize：Object 的方法，GC 回收对象前可能被调用一次，用于兜底清理。已废弃（Java 9 起标记 @Deprecated），原因：执行时机不确定、可能让对象"复活"、拖慢 GC。

延伸： 关闭资源用 try-with-resources 或显式 close，不要依赖 finalize。面试常追问"final 修饰的引用能否改对象内容"——能改内容，不能改指向。

class A { void f(int x) {} }
class B extends A {
    @Override void f(int x) {}    // 重写
    void f(String s) {}           // 重载（同类中参数不同）
    @Override String toString() { return "B"; }  // 返回值协变
}

延伸： 重载在编译期按静态类型选定，易出坑——A a = new B(); a.f(x) 走的是 A 的重载版本，不会因为运行时是 B 就换。

选择原则：

• 需要多继承行为、只定义契约 → 接口。
• 需要共享状态字段、构造逻辑或公共实现，且是 is-a 关系 → 抽象类。
• 经典组合：接口定义契约，抽象类给骨架实现（如 List 与 AbstractList）。

延伸： Java 8 起接口有 default 方法，两者边界变模糊，但接口仍不能持有实例状态；接口 default 方法冲突时子类必须显式覆写。

protected 的细节：不同包的子类只能访问"通过自身继承得到的"protected 成员，不能通过父类引用去访问另一个父类实例的该成员。

• 顶层类只能用 public 或 default。
• 成员可以四选一。
• 重写时访问权限不能收紧。

延伸： 接口的方法默认是 public，Java 9 起允许 private 方法作为内部复用。

结论：static 表示"属于类而非对象"，在类初始化阶段处理。

• static 变量（类变量）：所有实例共享一份；类加载的准备阶段赋类型默认值，初始化阶段赋显式值。
• static 方法：静态方法，没有 this，不能访问实例成员，用类名直接调用。
• static 代码块：类初始化时执行一次，按源码顺序与 static 变量赋值交错执行，常用于注册驱动、初始化配置。
• static 内部类：不持有外部类实例引用，可独立创建对象。

class A {
    static int x = 1;   // 先执行，x = 1
    static { x = 2; }   // 后执行，x = 2
}

延伸： 触发类初始化的时机：new 实例、访问静态成员、反射 Class.forName、初始化子类前先初始化父类。只声明一个引用类型变量不会触发初始化。

• this：当前对象的引用。用途是区分成员变量与局部变量、调用本类其他构造器 this(...)、返回当前对象实现链式调用。
• super：不是一个真实对象，而是编译器提供的"以父类视角访问当前对象"的语法。用途是调用父类被重写的方法、调用父类构造器 super(...)。

关键点：

• 两者都不能出现在 static 上下文中。
• 子类构造器第一行必然是 this(...) 或 super(...)；都不写则编译器自动插入 super()，若父类没有无参构造会编译报错。
• this(...) 与 super(...) 不能同时出现，也不能放在构造器非首行的位置。

延伸： 子类重写方法后仍想复用父类逻辑，用 super.method()，这也是模板方法模式的常见写法。

结论：静态优先于实例，父类优先于子类。

执行顺序：

1. 父类静态变量 / 静态代码块（按出现顺序）
2. 子类静态变量 / 静态代码块
3. 父类实例变量初始化（含实例代码块）+ 父类构造器
4. 子类实例变量初始化 + 子类构造器

class P { static { System.out.print("1"); } { System.out.print("3"); } P() { System.out.print("4"); } }
class C extends P { static { System.out.print("2"); } { System.out.print("5"); } C() { System.out.print("6"); } }
// new C(); 输出：123456

• 静态块只在类首次初始化时执行一次。
• 实例变量初始化与实例代码块在 super() 之后、构造器体之前执行。

延伸： 追问"构造器里能调用可重写方法吗"——能，但危险：父类构造器执行时子类字段还没初始化，被重写的方法里访问子类字段只能拿到默认值。

结论：1 个或 2 个。

• 字面量 "abc" 在常量解析时，若字符串常量池没有就创建 1 个放进去。
• new 关键字在堆上再创建一个 String 对象。
• 所以池里已有 "abc" → 只 new 出 1 个；没有 → 一共 2 个。

常量池：JDK 7 起从永久代移到堆中（Java 8 后是堆内的字符串常量池/StringTable），存放字面量和 intern 过的字符串。

String a = "abc";                    // 常量池中的对象
String b = new String("abc");        // 堆上的新对象
System.out.println(a == b);          // false
System.out.println(a == b.intern()); // true

延伸： "a" + "b" + "c" 全是字面量，编译期常量折叠成 "abc" 进常量池；若拼接里含变量，则是运行时 new StringBuilder 生成，不进常量池。

结论：Integer.valueOf 默认缓存 -128 ~ 127，超出范围会 new 新对象，== 结果为 false。

Integer a = 100, b = 100;
System.out.println(a == b);      // true，命中缓存，同一对象
Integer c = 128, d = 128;
System.out.println(c == d);      // false，超出缓存，两个对象
System.out.println(c.equals(d)); // true
Integer e = new Integer(100);    // 显式 new，不走缓存（该构造器已废弃）
System.out.println(a == e);      // false

• 自动装箱调用 Integer.valueOf，内部走 IntegerCache（本质是个数组）。
• 缓存上界可通过 -XX:AutoBoxCacheMax= 调大，下界固定 -128。
• Long/Short/Byte/Character 也有类似缓存，Byte 缓存全部 256 个值。

延伸： 包装类比较一律用 equals 或先拆箱成基本类型；new Integer(...) 已废弃，应使用 Integer.valueOf。

Object 是所有类的根，主要有 11 个方法：

• equals(Object)：判断相等，默认是 ==，一般需重写。
• hashCode()：返回哈希值，与 equals 配套重写。
• toString()：返回"类名@十六进制哈希"，建议重写。
• getClass()：返回运行时 Class 对象，final 方法。
• clone()：浅拷贝，未实现 Cloneable 会抛 CloneNotSupportedException。
• finalize()：GC 前回调，已废弃。
• notify() / notifyAll() / wait() / wait(long) / wait(long,int)：线程通信，必须在 synchronized 块内调用。

延伸： wait/notify 为什么定义在 Object 而不是 Thread？因为等待的"锁"是对象监视器，锁属于对象。wait 会释放锁并进入等待队列，notify 随机唤醒一个，notifyAll 唤醒全部。

结论：Throwable 是根，分 Error 和 Exception；Exception 又分受检与非受检。

• Error：JVM 层面的严重问题，程序通常无法恢复，如 OutOfMemoryError、StackOverflowError，不应 catch。
• Exception：
  • 受检异常（checked）：RuntimeException 及其子类之外的 Exception（IOException、SQLException 等），编译器强制处理——要么 catch，要么 throws。
  • 非受检异常（unchecked）：RuntimeException 及其子类（NPE、IndexOutOfBounds、IllegalArgument），编译器不强制。

throw 与 throws：

• throw 是语句，抛出一个具体异常对象，执行到即中断。
• throws 写在方法签名上，声明本方法可能抛出哪些异常，把处理责任交给调用方。

public void read(String path) throws IOException {          // 声明
    if (path == null) throw new IllegalArgumentException("path is null");  // 抛出
    new FileInputStream(path);
}

延伸： 为什么要分两类？受检异常适合"调用方有办法恢复"的场景；非受检多代表编程错误，应修复而非 catch。Spring 大量把受检异常包装成 RuntimeException，避免 throws 侵入业务接口。

结论：finally 一定执行；try 的 return 值会先被暂存，再执行 finally，最后返回暂存值——所以 finally 里改基本类型或引用本身不生效，改对象内容生效，finally 里再 return 则直接覆盖。

机制（字节码层面）：编译后，try 的 return 表达式先求值并存到一个临时局部变量槽（istore），随后 finally 的字节码被插入执行，最后再 load 该槽并 ireturn。因此 finally 修改局部变量不影响已存入槽的返回值。

static int f() {
    int x = 1;
    try { return x; }           // 1 被存入临时槽
    finally { x = 2; }          // 改的是 x 本身 → 仍返回 1
}
static int g() {
    try { return 1; }
    finally { return 2; }       // finally 的 return 覆盖 → 返回 2
}
static StringBuilder h() {
    StringBuilder sb = new StringBuilder("a");
    try { return sb; }          // 引用被暂存
    finally { sb.append("b"); } // 改堆对象内容 → 返回 "ab"
}

延伸： finally 里写 return 会吞掉 try 中未处理的异常，是 bug 温床；改对象内容生效是因为返回的是引用的拷贝，仍指向同一堆对象。

结论：它自动关闭实现了 AutoCloseable 的资源，编译器生成 close 调用，并正确处理"异常抑制"。

try (BufferedReader br = new BufferedReader(new FileReader("a.txt"))) {
    return br.readLine();
}   // 退出时自动调用 br.close()

• 资源必须实现 AutoCloseable/Closeable，声明在 try 的括号里，多个用 ; 分隔，按声明逆序关闭。
• 编译后展开为 try-finally，但比手写更强：
  • try 体和 close 同时抛异常时，close 的异常会被 addSuppressed 挂到主异常上（用 getSuppressed() 取），主异常不丢失。
  • 手写 finally 里 close 抛异常会直接覆盖 try 的业务异常。

延伸： 自定义资源只需实现 AutoCloseable 的 close 即可享受该语法；注意关闭顺序是"后声明的先关"。

结论：浅拷贝只复制对象本身、其中的引用仍共享；深拷贝递归复制所有引用对象，两个对象完全独立。

三种实现：

1. 构造器/工厂手动复制：显式 new 出所有成员对象，最可控、最快。
2. 重写 clone：先 super.clone() 拿浅拷贝，再对每个引用字段单独 clone（字段类型也要支持克隆）。
3. 序列化：序列化再反序列化，自动深拷贝，代码省事但最慢，且要求全部字段可序列化。

class User implements Cloneable {
    String name; Dept dept;
    @Override public User clone() throws CloneNotSupportedException {
        User u = (User) super.clone();   // 浅拷贝，dept 仍与原对象共享
        u.dept = new Dept();             // 手动深拷贝引用字段
        u.dept.name = this.dept.name;
        return u;
    }
}

延伸： 性能排序大致是手动构造器/拷贝构造 > clone > 序列化（反射 + IO 开销大）。追求高性能可用专门的映射工具，或用不可变对象从设计上规避拷贝需求。

结论：Java 只有值传递。传引用类型时，传的是"引用（地址）的拷贝"。

public static void swap(int a, int b) { int t = a; a = b; b = t; }   // 无效，改的是副本

public static void change(User u) { u.name = "b"; }                  // 生效，改的是同一堆对象

public static void reassign(User u) { u = new User("c"); }           // 无效，只改了副本引用

• 基本类型：拷贝数值，方法内修改不影响外部。
• 引用类型：拷贝引用值，通过引用改对象内容会影响外部；但让形参重新指向新对象，外部引用不变。

所以"Java 对对象是引用传递"是错的——若是引用传递，swap 就能真正交换两个对象引用。

延伸： 回答这题的关键是区分"改对象内容"和"改引用本身"；C++ 的 & 参数才是真正的引用传递。

结论：for-each 是语法糖，编译后对集合就是 Iterator（对数组退化为下标循环）。

for (String s : list) { /* ... */ }
// 编译后等价于
for (Iterator<String> it = list.iterator(); it.hasNext();) {
    String s = it.next();
}

• 遍历中调用 list.remove() 会改变 modCount，而迭代器的 expectedModCount 未同步，下次 next() 抛 ConcurrentModificationException（fail-fast）。
• 正确姿势：用迭代器自身的 remove，或 Java 8 的 removeIf。

Iterator<String> it = list.iterator();
while (it.hasNext()) { if (cond(it.next())) it.remove(); }
list.removeIf(this::cond);

延伸： for-each 拿不到索引、也不能直接删除；需要索引就用普通 for。另注意 list.remove(int) 与 list.remove(Object) 的重载歧义坑。

结论：intern() 返回该字符串在常量池中的规范表示——池里已有就返回池中对象，没有就把当前对象"登记"进池并返回。

String a = new String("hello");
String b = a.intern();
System.out.println(b == "hello");   // true
System.out.println(a == "hello");   // false

• JDK 7 起字符串常量池移到堆中：intern 时若池中没有，直接把堆里这个对象的引用放进池，而不是复制一份。所以对"此前从未进过池"的字符串，s.intern() == s 在 JDK 7+ 下可以成立。
• 用途：大量重复字符串去重、作为 key 时省内存。
• 代价：被 intern 的字符串长期驻留池中不易回收，滥用会造成内存问题。

延伸： "ja" + "va" 编译期折叠后进池，只有字面量的 intern 比较才会为 true；JDK 7 前后 intern 语义的差异是高频考点。

split 按正则分割，不是按普通字符：

"a.b.c".split(".");      // 空数组！"." 是正则里"任意字符"
"a.b.c".split("\\.");    // ["a","b","c"] 才正确
"a,b,,".split(",");      // ["a","b"]，末尾空串被丢弃（limit = 0）
"a,b,,".split(",", -1);  // ["a","b","",""]，limit=-1 保留末尾空串

substring 的内存问题：

• JDK 6 中 substring 返回的对象共享原 char[]，父串大、子串小时会长时间持有大数组，造成内存泄漏。
• JDK 7 起改为复制出新数组，该问题已消除。

其他易错点：equals 与 == 混用；indexOf 找不到返回 -1；replace 替换全部、replaceAll 才走正则；String 在循环里用 + 拼接性能差。

延伸： 面试问 substring 内存泄漏，必须答"JDK 6 才有、JDK 7 已修复"，笼统说"substring 会内存泄漏"会暴露知识陈旧。

• "" 是长度为 0 的 String 对象，可以安全调用方法：s.isEmpty() 为 true、s.length() 为 0。
• null 表示不指向任何对象，调用任何方法都抛 NullPointerException，但 s == null 判断是安全的。

String a = "";
System.out.println(a.length());   // 0
String b = null;
System.out.println(b == null);    // true
System.out.println(b.length());   // NullPointerException

判断空字符串的正确写法：if (s == null || s.isEmpty())——顺序不能反，必须先判 null 再调用方法。

延伸： 集合/Map 中要用 null 还是 "" 表达"无值"是有取舍的；参数校验常用 StringUtils.isBlank 同时覆盖 null、空串、纯空白。

结论：泛型在编译期提供类型检查并省略强转，编译后类型参数被擦除，运行时几乎不可见。

类型擦除：

• 类型参数在编译后被替换成它的上界（无界则为 Object）。
• 所以 List<String> 与 List<Integer> 运行时都是 List，getClass() 相同。
• 由此带来限制：不能 new T()、不能 instanceof T、不能定义泛型数组、不能仅靠泛型参数区分重载、静态成员不能用类型变量。

List<String> a = new ArrayList<>();
List<Integer> b = new ArrayList<>();
System.out.println(a.getClass() == b.getClass());  // true，都是 ArrayList

延伸： 擦除的初衷是兼容 Java 5 之前已有的二进制代码。需要运行时类型可用 Class<T> 字面量或 TypeToken 方案；擦除也意味着通过反射能往 List<Integer> 塞进 String，取出时才 ClassCastException。

• List<? extends T>：上界通配符，是"生产者"。可以读，读出来是 T；不能写（null 除外），因为具体元素类型未知。
• List<? super T>：下界通配符，是"消费者"。可以写 T 及其子类；读出来只能当 Object。

PECS：Producer Extends, Consumer Super——谁生产用 extends，谁消费用 super。

static void copy(List<? extends Number> src, List<? super Number> dst) {
    for (Number n : src) dst.add(n);   // src 只读，dst 只写
}

若读写都要，就别用通配符，直接声明 List<Number>。

延伸： List<?> 是无界通配符，等价于 List<? extends Object>，只能读成 Object、不能写。JDK 的 Collections.copy 就是 PECS 的典型应用。

结论：桥接方法是编译器为"泛型重写"生成的合成方法，用于在类型擦除后仍能保持多态分派。

class Node<T> { public void set(T t) { } }
class MyNode extends Node<String> {
    @Override public void set(String s) { }   // 想重写的方法
}

擦除后父类是 set(Object)、子类是 set(String)，签名不一致，多态会失效。编译器自动生成桥接方法：

// 编译器在 MyNode 中生成的合成方法
public void set(Object o) { set((String) o); }   // 转型后转调真正的 set(String)

这样 Node<String> n = new MyNode(); n.set("x") 的动态分派就会命中桥接方法，再转调真实方法。

延伸： 反射遍历 getDeclaredMethods() 会看到 isBridge() == true 的合成方法；泛型接口实现、协变返回类型都会产生桥接方法，这是"擦除后如何保持多态"的标准答案。

结论：反射是运行期"自省并操作"类的能力，可以获取字段、方法、构造器并调用，是框架的基石。

Class<?> c1 = Class.forName("com.demo.User");   // 全限定名，会触发类初始化
Class<?> c2 = User.class;                       // 类字面量，不触发初始化，最快
Class<?> c3 = new User().getClass();            // 运行时对象的实际类型
Class<?> c4 = ClassLoader.getSystemClassLoader().loadClass("com.demo.User"); // 不初始化

• 拿到 Class 后可用 getDeclaredFields/Methods/Constructors 获取成员，setAccessible(true) 突破私有访问。
• 核心调用是 method.invoke(obj, args) 和 constructor.newInstance()。

延伸： X.class 最快且不触发静态块；反射是 Spring IoC、MyBatis 映射、注解处理的基础。注意数组类型也有 Class（int[].class）。

优点：

• 运行期动态获取类型信息、创建对象、调用方法，支撑高度可配置可扩展的框架（Spring、MyBatis、JUnit）。
• 能突破封装访问私有成员，测试与序列化框架需要。

缺点：

• 性能开销：方法查找、参数装箱、访问权限检查，比直接调用慢。
• 编译期无法类型检查，错误延迟到运行期才暴露。
• 破坏封装，可读性差，存在安全风险（可读写私有字段）。

优化：

• 缓存 Class/Method/Field/Constructor 对象，避免重复查找。
• setAccessible(true) 跳过访问检查。
• 热点路径用 MethodHandle、LambdaMetafactory 或字节码生成（ASM/CGLIB）替代。

延伸： HotSpot 对反射做了膨胀优化（调用若干次后从本地实现切换到生成的字节码访问器），差距已明显缩小；但热路径仍应把反射限制在初始化阶段。

// JDK 动态代理核心
Object proxy = Proxy.newProxyInstance(
    target.getClass().getClassLoader(),
    target.getClass().getInterfaces(),
    (p, method, args) -> method.invoke(target, args));

选择：有接口优先 JDK 代理；无接口或需要代理类自身方法时用 CGLIB。Spring AOP 传统上按"有无接口"自动选择，Spring Boot 2.x 起默认强制使用 CGLIB 代理。

延伸： CGLIB 通过 ASM 生成字节码，因此 final 类无法被代理；JDK 代理要求目标必须实现接口，两者都只能增强 public/protected 可见范围内的方法。

四种：

• 成员内部类：定义在类中，持有外部类实例引用，可访问外部类所有成员。
• 静态内部类：static 修饰，不持有外部实例，可独立创建，最常用（如 Builder）。
• 局部内部类：定义在方法内，作用域限于该方法。
• 匿名内部类：无名字、边定义边实例化，常用于回调/Runnable/Comparator（Java 8 后多被 Lambda 取代）。

为什么访问局部变量要 final（Java 8 起是 effectively final）：

• 局部变量在栈上，随方法结束而销毁，而内部类对象可能在方法返回后仍存活。
• 编译器实际是把局部变量的值拷贝进内部类的合成字段（按值捕获），不是引用。
• 若变量之后还能被修改，拷贝值与原值就不一致，语义矛盾，所以强制它不可变。

void m() {
    int x = 10;                                  // 事实上 final
    Runnable r = () -> System.out.println(x);    // x 被拷贝进 lambda
}

延伸： Lambda 与匿名内部类的这个限制同源。需要可变捕获时，用数组、AtomicInteger 或成员变量代替。

结论：注解是附加在代码上的元数据，本身不改变程序逻辑，需由编译器或运行期反射读取处理。

元注解（修饰注解的注解）：

• @Retention：保留策略。SOURCE（仅源码）/ CLASS（编译期，默认）/ RUNTIME（运行期可反射读取，最常用）。
• @Target：可标注的位置（TYPE、METHOD、FIELD、PARAMETER 等）。
• @Documented：是否进入 javadoc。
• @Inherited：子类是否继承该注解。
• @Repeatable：是否可重复标注（Java 8）。

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface MyLog { String value() default ""; }

// 反射处理
Method m = clazz.getMethod("doIt");
if (m.isAnnotationPresent(MyLog.class)) {
    System.out.println(m.getAnnotation(MyLog.class).value());
}

延伸： 注解属性只能是基本类型、String、Class、枚举、注解及其数组。Spring 的 @Transactional、@Autowired 都依赖 RUNTIME 注解 + 反射/后置处理器实现。

结论：序列化把对象转成字节流以便存储或传输，反序列化还原对象；类需实现 Serializable。

• serialVersionUID：序列化版本号。反序列化时若类的 UID 与流中不一致，抛 InvalidClassException。不显式声明时由编译器按类结构计算，类一改就变，导致旧数据无法反序列化，所以应显式声明。
• transient：修饰的字段不参与序列化，还原后为默认值（null/0/false）。
• static 字段天然不参与序列化（属于类而非对象）。

class User implements Serializable {
    private static final long serialVersionUID = 1L;
    private String name;
    private transient String password;   // 不被序列化
}

延伸： 需要自定义逻辑可实现 writeObject/readObject。反序列化有安全风险（可构造恶意对象触发 RCE），不可信输入不要直接反序列化。

结论：Cloneable 是标记接口（内部无方法），不实现它调用 clone() 会抛 CloneNotSupportedException；Object.clone 默认是浅拷贝。

class User implements Cloneable {
    String name;
    List<String> tags;
    @Override public User clone() {
        try {
            return (User) super.clone();   // tags 与原对象指向同一个 List！
        } catch (CloneNotSupportedException e) {
            throw new AssertionError(e);
        }
    }
}

陷阱：

• 默认 clone 只复制字段值，引用字段仍共享，改原对象的 List 会影响克隆对象。
• clone 机制绕开构造器，若对象在构造器/初始化块里有逻辑，克隆对象可能处于不一致状态。
• final 字段无法在 clone 后重新赋值，深拷贝实现受限。

延伸： 正因为这些坑，Effective Java 建议用拷贝构造器或静态工厂替代 clone；"标记接口 + 不走构造器"的设计被公认为失败设计。

结论：SPI（Service Provider Interface）是"接口由框架定义、实现由第三方提供、运行期按约定发现并加载"的扩展机制。

原理：

• 框架定义接口；实现方在 jar 内的 META-INF/services/接口全限定名 文件里写实现类全名。
• 框架用 ServiceLoader.load(接口) 遍历并实例化所有实现。

ServiceLoader<MyPlugin> loader = ServiceLoader.load(MyPlugin.class);
for (MyPlugin p : loader) p.run();

与 API 的区别：

• API：接口和实现都由提供方定义，调用方被动使用（调用方驱动）。
• SPI：接口由调用方（框架）定义，实现放在外部插件（实现方驱动），框架依赖抽象、插件依赖框架。

应用：

• JDBC：java.sql.Driver 是 SPI 接口，各驱动在 jar 里提供 services 文件，DriverManager 通过 ServiceLoader 发现驱动。
• Spring Boot 自动装配：早期是 META-INF/spring.factories，新版本用 META-INF/spring/...AutoConfiguration.imports，本质都是 SPI 思想。
• Dubbo：自研 ExtensionLoader，用 @SPI + @Adaptive，解决了 JDK SPI 的问题。

延伸： JDK SPI 的缺点：一次性加载全部实现（浪费）、无法按名获取、不支持依赖注入——这正是 Dubbo/Spring 自研 SPI 的动机。

结论：Class.forName 默认会执行类的初始化（跑静态代码块），loadClass 只加载不初始化（懒加载）。

• Class.forName(String)：默认 initialize = true，会走完加载、链接、初始化全过程，静态变量赋值和静态代码块都会执行。
• ClassLoader.loadClass(String)：默认只做"加载"，不初始化；其 resolve 参数默认 false，也不做链接解析。
• 类加载器方面：forName 使用调用者的类加载器（也可显式指定），loadClass 使用当前 ClassLoader。

Class.forName("com.mysql.cj.jdbc.Driver");                      // 触发静态块，注册驱动
ClassLoader.getSystemClassLoader().loadClass("com.demo.User");  // 不跑静态块

延伸： 老代码用 Class.forName 加载 JDBC 驱动，正是利用它触发静态块完成注册；只想拿到 Class 元信息、不想产生副作用就用 loadClass。结合"加载→验证→准备→解析→初始化"五阶段回答更加分。

结论：按"是否阻塞、是否多路复用、是否异步"分为 BIO、NIO、AIO。

• BIO：read/write 阻塞，连接数大时线程爆炸；适合连接数少且固定的场景。
• NIO：基于 Channel/Buffer/Selector，一个线程用 Selector 轮询多个 Channel，就绪才处理；适合高并发的长连接海量场景（Netty、网关）。
• AIO：发起 read 即返回，内核完成后回调；理论上更高效，但 Linux 上实现不佳、生态支持弱，实际很少用。

延伸： 面试常问"为什么 AIO 没流行"——要答 Linux 异步 IO 的历史局限以及 Netty 在 Linux 上仍以 epoll 多路复用为主。术语上严格说 NIO 是"同步非阻塞"，别混成"异步"。

三大组件：

• Channel：双向通道，可读可写（区别于单向流）；FileChannel、SocketChannel、ServerSocketChannel、DatagramChannel。
• Buffer：数据容器，靠 position/limit/capacity 三个指针工作；flip() 由写模式切读模式，clear() / compact() 复位。
• Selector：多路复用器，一个线程管理多个 Channel，select() 阻塞到有事件就绪，通过 SelectionKey 拿到 OP_ACCEPT/READ/WRITE/CONNECT 事件。

Reactor 模式：

• 单 Reactor 单线程：一个线程既 accept 又处理业务，简单但扛不住高并发。
• 单 Reactor 多线程：Reactor 只管 IO 就绪，业务丢线程池。
• 主从 Reactor 多线程：mainReactor 只处理 accept，subReactor 处理读写；Netty 的 EventLoopGroup 就是这一模型。

Selector selector = Selector.open();
ServerSocketChannel ssc = ServerSocketChannel.open();
ssc.configureBlocking(false);
ssc.register(selector, SelectionKey.OP_ACCEPT);
while (true) {
    selector.select();
    for (SelectionKey k : selector.selectedKeys()) { /* 按事件分发处理 */ }
}

延伸： Selector 在 Linux 上底层是 epoll；Buffer 与 DirectByteBuffer 的配合是 Netty 高性能的基础。

结论：零拷贝是减少数据在内核态与用户态之间不必要的拷贝与上下文切换的技术，常用于文件传输与消息中间件。

传统 read + write 有 4 次拷贝：

• 磁盘 → 内核缓冲区（DMA）
• 内核缓冲区 → 用户缓冲区（CPU 拷贝）
• 用户缓冲区 → socket 缓冲区（CPU 拷贝）
• socket 缓冲区 → 网卡（DMA）

Java 中的实现：

• FileChannel.transferTo/transferFrom：在 Linux 下 FileChannel 到 SocketChannel 会走 sendfile，数据不经过用户空间。
• MappedByteBuffer（FileChannel.map）：mmap 把文件映射到用户空间地址，读写像操作内存，减少一次拷贝。
• DirectByteBuffer：堆外内存，避免 JVM 堆与本地内存之间的一次额外拷贝。
• 框架层：Kafka 用 sendfile 发送消息、RocketMQ 用 mmap、Netty 用 FileRegion。

try (FileChannel in = FileChannel.open(Path.of("a.txt"));
     FileChannel out = FileChannel.open(Path.of("b.txt"), CREATE, WRITE)) {
    long pos = 0;
    while (pos < in.size()) pos += in.transferTo(pos, in.size() - pos, out);
}

延伸： 真正的零拷贝（sendfile）是数据完全不落用户态；mmap 是"少一次拷贝"。答这题要能说清楚拷贝次数与是否经过用户空间。

结论：float/double 用二进制浮点表示，无法精确表示 0.1 这类十进制数，累加会累积误差；金额必须用 BigDecimal 或整数分。

System.out.println(0.1 + 0.2);             // 0.30000000000000004
System.out.println(1.0 - 0.9);             // 0.09999999999999998
System.out.println(new BigDecimal(0.1));   // 0.1000000000000000055511151231257827
System.out.println(new BigDecimal("0.1")); // 0.1 ← 必须用字符串构造

BigDecimal 的陷阱：

• 构造必须用 String（或 BigDecimal.valueOf(double)，它内部用 Double.toString），直接传 double 会把误差原样带进来。
• equals 同时比较 value 和 scale：new BigDecimal("1.0").equals(new BigDecimal("1.00")) 为 false；compareTo 只比值，返回 0。判等要用 compareTo。
• 除法必须指定精度与舍入模式（RoundingMode），否则除不尽时抛 ArithmeticException。
• 不可变，每次运算都产生新对象，别在循环里反复拼接字符串。

延伸： 金额也可用 long 以"分"为单位存储，性能更好但要小心单位换算；多币种、高精度计算用 BigDecimal 配合 setScale 更稳妥。

结论：浮点数遵循 IEEE 754，NaN 表示"非数"，规范规定 NaN 与任何值（包括自身）比较都为 false，以保证 NaN 的唯一性与可传播性。

double nan = 0.0 / 0.0;
System.out.println(nan == nan);                  // false
System.out.println(nan != nan);                  // true ← 老写法
System.out.println(Double.isNaN(nan));           // true ← 推荐

System.out.println(0.0 == -0.0);                 // true，数值相等
System.out.println(Double.compare(0.0, -0.0));   // 1，compare 区分正负零

• 判 NaN 用 Double.isNaN / Float.isNaN。
• 排序、TreeSet、判等比较用 Double.compare（把 NaN 视为最大、区分 ±0.0），保证与 equals 语义一致。
• 有意思的是：Double.valueOf(nan).equals(Double.valueOf(nan)) 返回 true，因为包装类 equals 用 doubleToLongBits 比较，而不是 ==。

延伸： 用 == 比较 Double 对象会踩 NaN 与 ±0.0 的坑；BigDecimal 没有 NaN 表示，需要自己用 null 或业务约定处理。

结论：JPMS 是 Java 9 引入的模块系统，用 module-info.java 声明模块边界（requires/exports/opens），实现强封装与可靠依赖。

// module-info.java
module com.demo.app {
    requires java.sql;                          // 依赖其他模块
    exports com.demo.app.api;                   // 导出包给外部访问
    opens com.demo.app.entity to spring.core;   // 仅对该模块开放反射
}

与反射的冲突：

• 强封装下，未 exports 的包，模块外部连 public 类都访问不到；未 opens 的包，反射访问其非 public 成员会抛 InaccessibleObjectException。
• Java 9+ 对 JDK 内部 API 做了强封装，反射操作 java.lang 等内部字段会被拒绝，需要启动参数 --add-opens java.base/java.lang=ALL-UNNAMED 或 --add-exports。
• Spring、MyBatis、Hibernate 等框架大量用反射操作实体私有字段，所以在 Java 17/21 上常需配置 add-opens。
• 未命名模块（classpath 上的普通 jar）默认对所有模块开放自己的包，所以未做模块化的应用受影响较小。

延伸： 模块化对 jlink 裁剪运行时、减少启动开销有帮助，但工程采用率不高，多数项目仍停留在 classpath 模式。答题时给出"冲突点 + add-opens 解法 + 实际影响有限"即可。

结论：二元运算会先做「二元数值提升」（binary numeric promotion）：只要一侧是 double，另一侧也升为 double；否则有一侧是 float 就都升 float；否则有一侧是 long 就都升 long；否则两侧都升为 int（byte/short/char 参与运算也先升 int）。编译器只在「赋值/传参」时检查窄化，运算过程本身不会帮你保精度。

要点：

• byte b = 1; b = b + 1; 编译失败，因为 b+1 已经是 int，必须写 (byte)(b+1)——这是最经典的坑。
• 溢出发生在提升「之前」：long x = 24 * 60 * 60 * 1000 * 1000; 右侧全是 int 常量，按 int 算已经溢出，事后再升 long 也救不回来。写成 24L * 60 才安全。
• 精度丢失：int a = 123456789; float f = a; 得到 1.23456792E8，float 只有 24 位有效尾数，超过 2^24 的整数无法精确表示。
• char 是无符号 16 位，char c = 'A'; int i = c + 1; 得到 66，但不会自动转回 char。
• 复合赋值自带隐式强转：b += 1 能编译，等价于 b = (byte)(b+1)，这正是它和 b = b+1 行为不同的原因。

延伸：涉及金额、时间戳、哈希时优先显式用 long/L 后缀，或用 Math.multiplyExact/addExact，溢出时抛 ArithmeticException 而不是静默回绕。

结论：位运算不是为了炫技，而是把「多个布尔状态」压进一个整数，或用掩码从一个大整数里抠出指定比特。权限系统、HashMap 的容量、线程池状态都靠它。

要点：

• 六种运算符：& 与、| 或、^ 异或、~ 取反、<< 左移、>> 算术右移（保留符号）、>>> 逻辑右移（补 0）。对负数务必区分 >> 和 >>>。
• 掩码提取：(value >> offset) & mask。从 int 取低 8 位要写 value & 0xFF，因为 byte 转 int 会做符号扩展，不 & 就可能是负数。
• 位标志：用第 n 位表示一种能力，1<<n 是标志位。判断用 (flags & FLAG) != 0，置位用 flags |= FLAG，清除用 flags &= ~FLAG，切换用 flags ^= FLAG。
• 进制：0b 二进制、0 八进制、0x 十六进制，下划线做可读分隔 0xFF_FF；Integer.toBinaryString/toHexString 用于调试。
• 常见坑：int 上 1 << 32 等于 1（移位量对 32 取模），要写 1L << 32；位运算优先级低于 ==，必须加括号。

延伸：JDK 里 Integer.SIZE、HashMap 的 tableSizeFor（容量向上取整到 2 的幂）、ThreadPoolExecutor 的 ctl（高 3 位存运行状态、低 29 位存线程数）都是位运算的经典工程案例。

结论：优先级本身不难记，难点在「位运算 / 短路逻辑 / 自增 / 三元」混用时的隐性错误。工程上的最佳实践是：不确定就加括号，需要明确求值顺序就别省。

要点：

• 位运算低于相等比较：a & b == c 实际是 a & (b==c)。因为 b==c 是 boolean，编译器通常直接报错反而帮你发现了；但 x & y | z == w 这类混用极易误判，务必加括号。
• 短路差异：&& || 会短路，& | 不会。a != null & a.equals(b) 在 a 为 null 时照样 NPE——这是把逻辑与写成按位与的经典事故。
• 自增自减与赋值：arr[i++] = i 这类表达式依赖求值顺序，结果常出乎意料。Java 保证从左到右求值，但别指望靠这个写「聪明」代码。
• 三元运算符：条件 ? 值1 : 值2，嵌套时结合性从右到左，a?b:c?d:e 等价于 a?b:(c?d:e)。
• 字符串拼接：只要一侧是 String，+ 就是拼接，"1"+2+3 得到字符串 "123" 而不是 6；全是常量时编译器会在编译期折叠。
• 移位与运算耦合：~x & 0xF 是先 ~x 再 &0xF，想先 & 就得加括号。

延伸：Sonar、IDE 检查普遍建议对 & | ^ 与条件表达式显式加括号；这类题面试官主要看你会不会「用括号消灭歧义」。

结论：这些 API 主要替掉「手写判空 + trim + 拼接 + 手动缩进」的样板代码，并在 Unicode 语义上修正了老方法的缺陷。

要点：

• isBlank()：判断是否为空或仅含空白（按 Character.isWhitespace），比 str.trim().isEmpty() 更可读，对全角空格等也更友好。
• strip()/stripLeading()/stripTrailing()：按 Unicode 空白裁剪。trim() 只处理 <= U+0020，遇到全角空格、\u00A0 不生效——这是常年老坑，strip 才是正确姿势。
• repeat(n)：重复拼接，n<0 抛 IllegalArgumentException，n==0 返回空串。
• indent(n)：给每一行加缩进并统一行尾为 \n，写多行文本模板时很实用。
• formatted(args)：等价于 String.format(this, args)，让格式化调用更贴近字符串本身。
• lines()：按行切分为 Stream，替代 split("\n") 的正则开销。
• 坑：strip 不会删中间空白；indent 会改写行尾；repeat 大数量会直接产生大对象。

延伸：JDK 15+ 的文本块（"""…"""）写 SQL/JSON 比拼接可读得多；但文本块的行尾与缩进由编译器处理，别把业务缩进和字面量缩进搞混。

结论：java.util.Objects 把「判空、比较、哈希、字符串化」这些高频操作集中起来，避免手写 NPE 判断和重复代码。

要点：

• requireNonNull(obj)：参数校验最简写法，null 抛 NPE；requireNonNull(obj, "msg") 可带信息，比手写 if(obj==null) throw 更短且不会漏掉某条分支。
• requireNonNullElse(obj, default)：null 时给默认值；requireNonNullElseGet(obj, Supplier) 延迟计算默认值。
• equals(a, b)：null 安全比较，先比引用再走 equals，省掉 (a==null?b==null:a.equals(b)) 的啰嗦写法。
• hashCode(Object... values)：重写 hashCode 的标准写法，自动处理 null。
• deepEquals / hash：对数组做「内容级」比较或哈希（普通 equals/hashCode 对数组是引用语义，这是常见 bug）。
• toString(obj, default)：null 时返回默认串。
• checkIndex(index, length)（JDK 9+）：边界检查，越界抛 IndexOutOfBoundsException，替代手写 if。

延伸：重写 equals/hashCode 时用 Objects.equals 与 Objects.hash 最省心；但 Objects.hash 每次会创建数组并装箱，性能极敏感的类建议手写。

结论：规范上 hashCode 与内存地址没有任何关系，它只要求「equals 相等则 hashCode 必须相等」。Object.hashCode 的默认实现由 JVM 决定，HotSpot 默认用随机数算法（Marsaglia 异或移位等）生成一个值，和对象实际地址没有稳定映射。

要点：

• 为什么不能和地址绑定：GC 会移动对象（复制、整理），地址是变的。若 hashCode 跟着地址走，对象一移动哈希值就变，HashMap 立刻失效。所以规范刻意不把它定义成地址。
• 默认实现是策略：HotSpot 可用 -XX:hashCode=N 切换不同策略（含「地址参与」「固定常量」「线程局部随机」等），说明它本来就是实现细节，绝不可依赖。
• 一致性哈希问题：默认 hashCode 每次进程启动可能不同，所以不要把它持久化（写库、跨 JVM 传参）。
• 重写规则：equals 用来比较的字段，hashCode 必须也用到，否则「相等」的两个对象会落到不同桶，HashMap 里再也捞不出来。
• 典型事故：只重写 equals（用 id 比较）却没重写 hashCode（还在用地址），put 进去后 get 不到。

延伸：String、Integer 等常用类都重写了 hashCode（String 用 31 乘累加），所以它们能安全地当 HashMap 的 key；自定义类做 key 时务必成对重写 equals/hashCode。

结论：NaN 是「非数」，它不等于任何值（包括自己），与任何数比较都返回 false；Infinity 可以正常比大小，但参与运算可能产出 NaN。它们混进 TreeSet/TreeMap 或当作 Map key 时，行为和直觉严重不符。

要点：

• 比较：NaN == NaN 为 false，NaN < 1、NaN > 1 也全为 false；必须用 Double.isNaN(x) 判断。
• equals 与 == 分裂：Double.valueOf(NaN).equals(Double.valueOf(NaN)) 是 true（equals 比位模式），但用 == 比是 false。这导致「集合里能命中，代码里却判不相等」。
• 排序集合：TreeSet/TreeMap 依赖 Double.compareTo，它把 NaN 当成「比任何数都大」且与自身相等（返回 0），所以 TreeSet 能放一个 NaN，但语义很反直觉。
• 当 HashMap 的 key：NaN 作为 key 能互相命中（equals 为 true），但 0.0 与 -0.0 的 equals 却是 false（位模式不同），这是历史遗留的不一致。
• Infinity：1.0/0.0 得正无穷，-1.0/0.0 得负无穷，0.0/0.0 得 NaN；Infinity 可正常排序。
• 排序建议：用 Double.compare(a, b) 而不是 a-b 或 > <，它显式处理 NaN 与 -0.0。

延伸：这就是 Float/Double 不适合当集合 key 的原因；需要数值稳定比较时优先用 BigDecimal 或转成整数字符串。

结论：乱码本质是「用 A 编码写出的字节，被用 B 解码」。三种根因：①编解码 charset 不一致；②中途用单字节字符集（ISO-8859-1）把多字节序列当成独立字符处理；③字节被按固定长度截断，切出了半个字符。

要点：

• Java 里 String 内部是 UTF-16 码元序列：getBytes(charset) 把 UTF-16 转成目标字节，new String(bytes, charset) 反向解码。两边 charset 不同就是乱码。
• 根因①：读文件 / 收 HTTP 时没显式指定 charset（如 new String(bytes) 用了平台默认编码），或 JDBC url 忘了 characterEncoding=utf8mb4。
• 根因②：某处先 new String(bytes, "ISO-8859-1")（Latin-1 每字节映射一个字符、无损），后面又当 UTF-8 用，中文就变成「ä½ å¥½」这类双重编码。
• 根因③：按字节长度截断字符串（如按 100 字节切日志），把 3 字节的汉字劈成两半，解码出现替换符 U+FFFD（�）。
• 定位方法：打印 hex 看是否为合法 UTF-8 多字节序列（如「你」是 0xE4 0xBD 0xA0），在链路每一跳打印 charsetName。
• 注意：GBK/GB2312 是双字节且与 UTF-8 不兼容；UTF-8 是 1~4 字节变长，所以「按字节截断安全」的前提是别切在字符中间。

延伸：新项目全链路 UTF-8（文件、JVM -Dfile.encoding=UTF-8、HTTP、DB utf8mb4、容器 locale）；JDK 18 起 file.encoding 默认为 UTF-8，很多老 bug 才「突然好了」。

结论：JDK 9 引入 Compact Strings（JEP 254），把 String 的存储从 char[]（每字符固定 2 字节）改为 byte[] + 一个 coder 标志：内容全是 Latin-1 时用 1 字节/字符存，含非 Latin-1 才用 2 字节/字符存。

要点：

• 动机：绝大多数真实字符串（ASCII、英文 key、URL、数字）都在 Latin-1 范围内，用 char[] 每个字符浪费一半内存，也浪费缓存带宽。
• 结构：private final byte[] value; private final byte coder; coder 取 LATIN1 或 UTF16 两个值之一，UTF16 时长度等于 value.length/2。
• 收益：纯 ASCII 字符串的堆占用和内存带宽近乎减半，GC 压力也更小。
• 代价：charAt 等操作需要判断 coder，但 JIT 后开销很小；换来的是实打实的内存节省。
• 破坏性：靠反射读 String.value 是 char[] 的老代码（旧版 Spring、部分序列化库、Unsafe 黑魔法、JOL 分析脚本）会失效或报错——这是升级 JDK 9+ 的常见踩坑点。
• 顺带纠正：JDK 7 起 substring 就不再共享底层数组（避免大数组无法释放），Compact Strings 之后更是复制，「substring 泄漏大数组」已是过时说法。

延伸：堆分析里看到大量 [B（byte 数组）往往就是 String 的 value；可以用 -XX:-CompactStrings 关闭（极少需要）。

结论：少量、可读性优先用 + 或 formatted；循环内、热点路径用 StringBuilder；日志用参数化占位符（log.info("{}", x)）而不是先拼好字符串。

要点：

• • 拼接：编译期常量会被编译器直接折叠（"a"+"b" 编译成 "ab"）；运行时非循环场景编译器用 invokedynamic + StringConcatFactory 优化，性能已很好，不必为了一两处拼接改 StringBuilder。
• 循环里用 + 是灾难：每次迭代都 new 一个 StringBuilder，整体 O(n²)；必须显式复用 StringBuilder。
• String.format：每次都要解析格式串、装箱变长参数、内部再建 Formatter 和 StringBuilder，实测比直接拼接慢一个数量级，只适合日志/输出等非热点。
• formatted 只是语法糖，底层同样走 Formatter。
• 数字/日期热路径：用预建的 DecimalFormat（它不是线程安全的，需 ThreadLocal 或每次 new），不要每轮都 format。
• 日志：SLF4J 的 {} 占位符在未达到日志级别时根本不拼接，比字符串拼接省；但别在参数里塞耗时计算。
• 字符串模板现状：JDK 21 起以预览特性（JEP 430）出现，后续版本对 API 做过调整，至今仍未转正、需 --enable-preview，生产代码不要依赖。

延伸：判断标准是「这行代码每秒执行多少次」。低频处可读性优先，高频处 StringBuilder 优先，用 JMH 实测而不是拍脑袋。

结论：异常链把「底层原因」挂在「上层异常」上，让堆栈可追溯。initCause/构造器传 cause 表示因果关系（A 因 B 而起），addSuppressed 表示「主异常之外还有被压制的异常」（典型是 try-with-resources 里 close 抛了异常）。

要点：

• 因果链：throw new ServiceException("保存失败", e)，e 成为 cause，printStackTrace 打印出 "Caused by: …"。跨层抛异常时保留 cause，别写成 new X(e.getMessage()) 丢掉现场。
• 自环禁止：new X(e) 之后再 x.initCause(x) 会抛 IllegalArgumentException，同一个对象不能既是被 cause 又是 cause。
• addSuppressed：JDK 7 起配合 try-with-resources。try 体抛 A、close 抛 B 时，A 是主异常，B 被挂到 A 上，通过 getSuppressed() 读取。
• 老写法的坑：在 finally 里 close 会吞掉异常——要么吞掉 try 体的，要么吞掉 close 的；try-with-resources 正是为解决它而生。
• 手动场景：批量操作里「主异常 + 每个失败项的错误」，也可用 addSuppressed 汇总。
• 细节：addSuppressed(null) 抛 NPE；getSuppressed 默认返回空数组，别假设非空。

延伸：全局异常处理器打日志时要同时遍历 getSuppressed，否则会漏掉资源关闭失败的信息。

结论：抛异常慢，但慢的根源不是 try-catch，而是构造异常时的 fillInStackTrace（填充栈轨迹）。只在罕见分支抛异常时可忽略其开销；把异常当控制流（每轮循环都抛/捕获）才会成为性能热点。

要点：

• try-catch 本身几乎零成本：JIT 不会为 try 块生成额外运行时检查，异常表只是方法元数据，正常路径无开销。
• 真正的开销：new Exception() 会调用 fillInStackTrace，遍历整个线程栈、为每一帧抓定位信息，栈越深越慢，远比普通对象分配贵。
• 优化手段：①别用异常做正常流程控制；②热路径确实需要时，可重写 fillInStackTrace 直接返回 this（牺牲可诊断性换性能）；③Throwable 构造器支持 writableStackTrace=false，但不同 JDK 版本表现有差异，须实测。
• 用异常做控制流的坏处不止性能：会掩盖真正的异常、让栈难读、破坏分支预测友好的代码结构。
• 何时无所谓：每秒几次的失败分支，不必优化，可读性优先。

延伸：给出量级直觉即可——抛出+捕获的成本主要在栈填充；高频 RPC 失败场景可用错误码代替异常，用 JMH 验证而不是靠传言。

结论：受检异常强迫调用方处理，理论上更安全，但实践中常导致「层层 throws」或「无脑空 catch」。现代共识是：调用方能合理恢复的用受检（如 IOException），其余（参数非法、状态错误、业务失败）用非受检。全局异常处理则集中在 Web 边界统一转码。

要点：

• 受检异常的争议：①大多数异常调用方根本处理不了，只能往上抛，污染每个方法签名；②函数式接口（Function/Stream）不能抛受检异常，Lambda 里用很别扭；③鼓励空 catch 吞异常，比不检查更糟。
• 框架取向：Spring 把受检的 SQLException 翻译成非受检的 DataAccessException；JPA 用非受检的 PersistenceException；Lambda 里常见套路是自定义 ThrowingConsumer 包装。
• 分层设计：DAO 抛数据访问异常 → Service 翻译成带错误码的业务异常（保留 cause）→ Controller 不写 try-catch，交给全局处理器。
• 统一出口：@RestControllerAdvice + @ExceptionHandler，返回统一结构（code/message/traceId）；对未捕获异常兜底返回 500，但不把堆栈暴露给前端。
• 校验异常：@Valid 抛 MethodArgumentNotValidException、约束违反抛 ConstraintViolationException，需单独映射到 400。
• 日志分级：业务异常 WARN（可预期），系统异常 ERROR（要告警），并把 cause 打全；别混淆 HTTP 状态码与业务码。
• 红线：永不写空 catch；至少 log 且保留 cause。

延伸：RPC 场景异常不能直接跨进程传，需映射为错误码 + 消息；分布式下建议在网关层做统一异常转码。

结论：反射慢就三件事——每次调用要做访问检查与方法解析、参数要装箱进 Object[]、以及目标方法多变导致 JIT 无法内联（甚至无法稳定去虚化），因此难以走优化后的直接调用路径。

要点：

• 访问检查：Method.invoke 会做访问权限与参数类型校验；setAccessible(true) 可绕过部分检查（并抑制安全检查），是常见的加速手段。
• 装箱与数组：invoke(Object obj, Object... args) 会把基本类型装箱并构造 Object[]，产生分配与拆装箱。
• 方法解析：要按名字和签名在方法表里定位目标方法，虽然有 Method 对象缓存，但每次仍有解释/边界开销。
• JIT 内联失败：JIT 靠类层次分析（CHA）内联调用点；反射用的是 Method 对象，JIT 难以确定唯一目标，导致代码无法内联，也就享受不到常规优化。
• 加速手段：①把 Method/Field 缓存进静态 Map，别重复 getDeclaredMethod；②setAccessible(true)；③真正追求性能应上 MethodHandle/VarHandle 或代码生成（ASM/ByteBuddy），而不是死磕反射。
• 补充：JDK 18（JEP 416）用 MethodHandle 重构了核心反射实现，反射性能已有改善，但稳定内联仍是 MethodHandle/VarHandle 的主场。

延伸：Spring/MyBatis 通过缓存 + 生成代理把反射开销摊薄；这也说明反射的真正代价是「牺牲编译期安全与可维护性」，性能只是其中一项。

结论：MethodHandle（JDK 7）和 VarHandle（JDK 9）是「方法/字段的直接引用」，由 JVM 在字节码层面按签名精确解析，能像普通方法一样被 JIT 内联，因此避开了反射的访问检查与装箱瓶颈。VarHandle 主要用来替代 Unsafe 做字段的原子/有序访问。

要点：

• MethodHandle：通过 MethodHandles.lookup().findVirtual/findStatic 获取；invoke/invokeExact 调用。invokeExact 要求签名完全匹配（返回类型都不能自动转型），JIT 可据此内联，性能接近直接调用。
• 绑定与适配：bindTo 可固定第一个参数（接收者），适合把方法当函数传递；asType 做类型适配，但会引入适配开销。
• VarHandle：对字段/数组元素提供 get/set、getVolatile、compareAndSet、compareAndExchange、getAndAdd 等操作，是 java.util.concurrent 里替代 sun.misc.Unsafe 的官方方案，适合无锁数据结构与原子字段更新。
• access mode：VarHandle 支持 Plain、Opaque、Acquire/Release、Volatile 多种访问模式，对应不同的可见性与重排序约束。
• 对比本质：反射是「运行时、带检查、难内联」；MethodHandle/VarHandle 是「弱类型的函数/字段引用，调用点可被优化」。
• 代价：API 更底层更难写，错误常到运行时才暴露（WrongMethodTypeException）；invoke/invokeExact 是 signature polymorphic 方法，编译器特殊处理，容易踩坑。

延伸：Lambda 的底层就是 invokedynamic + MethodHandle；JUC 的部分新实现也在用 VarHandle 取代 Unsafe。

结论：泛型是「编译期擦除」，数组是「运行时保留类型」的，二者语义冲突。数组在运行时会检查存入元素的真实类型（否则抛 ArrayStoreException），而擦除后泛型数组无法在运行时知道 T 是什么，会破坏类型安全，所以语言直接禁止「generic array creation」。

要点：

• 数组是协变的：Object[] arr = new String[1]; arr[0] = 1; 编译通过、运行时抛 ArrayStoreException——它的安全正是依赖「运行时知道元素类型」。
• 泛型是不变且擦除的：List 与 List 运行时都是 List，T 在字节码里不存在，无法运行时检查。
• 冲突后果：若允许 new T[10]，编译器就无法保证数组元素类型一致，类型安全会崩。
• 变通做法：①用 List 代替数组；②用反射 Array.newInstance(clazz, n) 显式提供 Class（会有 unchecked 警告）；③@SuppressWarnings("unchecked") 强转 Object[]；④用 Guava/自建容器。
• 变长参数即数组：T... 本质是数组，所以会产生 unchecked generic array creation 警告——这正是 @SafeVarargs 存在的原因。
• 经典案例：ArrayList 内部 elementData 是 Object[]，对外 get 时强转 E。

延伸：理解了「数组要运行时类型、泛型只有编译期类型」，这题和 @SafeVarargs、桥接方法就串成一条线了。

结论：@SafeVarargs 表示「这个可变参数方法/构造器对泛型参数数组的使用是类型安全的」，用来压住编译器的 unchecked generic array creation 警告。它是你向编译器做的承诺，用错了会掩盖真实漏洞。

要点：

• 为什么报警：T... args 会被编译成 T[]，而泛型数组本不能创建，编译器只能用 Object[] 代替并给 unchecked 警告。
• 使用前提：方法内①不写入这个数组（不向 args[i] 赋值），②不把它泄漏出去（不 return、不传给外部可写的地方）。满足这两点才算真安全。
• 允许加的范围：static 方法、final 实例方法、构造器（不能被重写从而破坏安全）；普通可重写实例方法不能加。
• 危险反例（不该加 @SafeVarargs）：

@SafeVarargs
static <T> void bad(List<T>... lists) {
    Object[] arr = lists;        // 别名泄漏
    arr[0] = List.of(1);         // 塞入错误类型
}

• 正确用法：只读遍历、不写不泄漏；下游消费用 Arrays.asList 或直接遍历。
• JDK 9 起也可用于 private 实例方法。

延伸：这题考的是「你知不知道 @SafeVarargs 是承诺而不是免责声明」。只会说「加它能去掉警告」会被追问到答不上来。

结论：不能。类型擦除后两个方法签名都是 f(List)，属于方法签名冲突（name clash），编译器直接报错。泛型实参不同不构成重载，返回值不同也不构成重载。

要点：

• 擦除后签名相同：List 与 List 擦除后都是 List，两个 f 变成同签名方法，JVM 不允许一个类里出现两个同签名方法。
• 合法的重载：参数个数不同，或「擦除后的原始类型」不同——如 f(List) 与 f(Set)、f(List) 与 f(Collection)（擦除后是 List 与 Collection，可以共存）。
• 桥接方法：子类重写泛型方法时编译器生成 bridge method 以适配擦除，这也是反射里会看到一个「多出来的」合成方法的原因。
• 命名冲突：一个类继承的两个泛型接口用不同实参、且擦除后方法签名相同，会产生冲突，需要显式重写来消歧。
• 实践影响：想用重载区分 List/List 做不到，只能换方法名（findUsers/findOrders）或加一个类型令牌参数。

延伸：Jackson 用 TypeReference/JavaType 携带真实类型，就是在绕开擦除——和下一题的 getGenericSuperclass 是同一套知识。

结论：方法体里拿不到单个泛型参数（List 的 String），因为它已被擦除；但类/字段/方法签名上的泛型信息会以 Signature 属性写进 class 文件，可以通过 getGenericSuperclass/getGenericInterfaces/Field.getGenericType 读到。这是 Jackson 的 TypeReference、MyBatis 的 Mapper 解析、Spring 的 ResolvableType 能工作的基础。

要点：

• 原理：擦除擦掉的是「运行时的类型实参」，而声明处的泛型信息保留在字节码的 Signature 属性里，反射的 generic 系列 API 读的就是它。
• 套路一（超类型令牌）：new TypeReference<List>(){} 生成一个匿名子类，把父类型实参具体化，于是 getGenericSuperclass() 能返回 ParameterizedType，拿到 List。
• 套路二：Field.getGenericType()、Method.getGenericReturnType() 返回 Type；若是 ParameterizedType，用 getActualTypeArguments() 取实参。
• 套路三：递归解析父类直到找到实参——Spring 的 ResolvableType 就是干这个的，别自己造轮子。
• Type 有五种：Class、ParameterizedType、GenericArrayType、TypeVariable、WildcardType，必须逐一判断；getActualTypeArguments 里可能是未确定的 TypeVariable。
• 局限：方法体内 new 出来的泛型集合、局部变量的泛型，都拿不到真实类型；只能依赖「写在声明处」的信息。

Type t = new TypeReference<List<String>>() {}.getType();
if (t instanceof ParameterizedType p) {
    Type arg = p.getActualTypeArguments()[0]; // class java.lang.String
}

延伸：JDK 16+ 的 instanceof 模式匹配让这段判断更简洁；但核心认知不变——泛型信息只有「写死在声明中」才可反射获取。

结论：switch 表达式能直接产出值（不用 break 和临时变量），配合枚举可以做到「穷尽 + 编译期检查」，箭头语法还能彻底避免贯穿（fall-through）。但 switch 对 null 会抛 NPE。

要点：

• 两种形态：语句式 switch（老）与表达式式 switch（可以赋给变量或直接 return）。表达式必须穷尽所有可能（枚举列全或写 default），否则编译不过。
• 箭头语法 case X -> expr; 不会贯穿、不需要 break；多标签 case A, B -> … 很简洁。
• yield：块体里返回值用 yield 值; 而不是 return。
• 枚举的坑：switch 表达式为 null 时抛 NPE（不像 if 可以判空），要提前判空；枚举新增常量后，无 default 且未处理的 case 会编译报错（这是好事，穷尽性检查）。
• 模式匹配 switch（JDK 21 正式）：case String s -> … 可按类型分支，配合 sealed 接口能保证穷尽。
• 传统贯穿问题：冒号语法忘写 break 会贯穿；箭头语法从语法层面杜绝。
• 常量限制：case 标签必须是编译期常量（枚举常量、final 常量、字面量），不能是变量。

延伸：另一种更 OO 的写法是把行为放进枚举（抽象方法 + 每个常量实现），比大型 switch 更符合开闭原则；switch 表达式适合简单映射。

结论：JDK Proxy 用 JDK 自带能力「运行时生成实现相同接口的新类」并转发调用（基于反射），只能代理接口；CGLIB 用 ASM 生成「目标类的子类」并覆写方法（基于字节码，不要求接口）；ByteBuddy 是 CGLIB 的现代化继任者，用统一 API 生成/改写字节码，灵活度最高，Spring 6+ 与 Mockito 都在用。

要点：

• 共同点：都在运行时用字节码技术造一个新类，增强逻辑通过拦截回调织入。
• JDK Proxy：Proxy.newProxyInstance 生成实现全部传入接口的 class，每个方法体调用 InvocationHandler.invoke(proxy, method, args)；必须靠反射调目标方法，这也是它略慢的原因之一。目标对象必须实现接口。
• CGLIB：生成目标类的子类、覆写非 final 方法，通过 MethodInterceptor 拦截，内部用 FastClass 索引调用以规避反射。缺点：无法代理 final 类/方法/private 方法。
• ByteBuddy：建立在 ASM 之上，API 更安全（不用手写字节码），支持 subclass（类 CGLIB）、redefine、rebase、javaagent 运行时增强。
• 性能：三者都是「生成一次、调用多次」，差别在运行期调用路径——CGLIB/ByteBuddy 的 FastClass/委托可避开反射，JDK Proxy 每次走反射（JDK 18 后有改善但仍不如直接）。
• 兼容性踩坑：JDK 9+ 模块化下，CGLIB/ByteBuddy 增强 JDK 内部类需要 --add-opens；final 方法无法被代理，是「事务/AOP 不生效」的经典原因。

延伸：Spring AOP 的选择策略——目标实现了接口默认用 JDK Proxy，否则用 CGLIB；Spring Boot 2.x 起默认 proxyTargetClass=true 强制 CGLIB，因为能少踩接口缺失的坑。

结论：ObjectInputStream 反序列化时会自动调用目标类（及其可达对象）的 readObject/readResolve/readExternal 等「魔法方法」。攻击者可精心构造一条从可触发类到危险操作（执行命令、加载远程类）的调用链（gadget chain），在没有任何业务代码参与的情况下触发。根因是「反序列化把数据当代码执行」。

要点：

• 触发机制：readObject 会按流里的类描述符实例化对象并调用其 readObject；若某个类的 readObject 又调用了其他方法，就形成链。攻击者不需要这些类出现在你的代码里，只要 classpath 上有（如 Commons Collections、Spring、Groovy 等）就能被串起来。
• 经典链条：CommonsCollections（经 InvokerTransformer/TransformedMap 触发反射调用 Runtime.exec）、Spring 链、Jdk7u21（AnnotationInvocationHandler）等。
• 危害：远程命令执行（RCE）、SSRF、DoS（深层嵌套导致栈溢出、哈希碰撞）。
• 入口极多：HTTP 反序列化、RMI、JMS、缓存里存的对象（Redis）、Shiro、Dubbo 等，凡是 readObject 的地方都是入口。
• 防御总原则：永远不要反序列化不可信数据。具体手段：
  1. 对象输入过滤：ObjectInputFilter（JEP 290）设白名单，可注册 ProcessWideFilter 全局生效；JDK 17 的 JEP 415 支持上下文相关过滤器；
  2. 白名单校验：ValidatingObjectInputStream（Commons IO）或自定义 resolveClass 检查类名；
  3. 换协议：用 JSON 替代原生序列化，并关闭多态默认类型（@JsonTypeInfo 的 enableDefaultTyping 是另一个坑）；
  4. 升级存在已知 gadget 的依赖版本；
  5. 隔离：把反序列化放到低权限进程/沙箱。
• 现状：原生序列化在跨语言、安全、版本兼容上全面落后，新系统应默认用 JSON/Protobuf。

延伸：理解「数据即代码」是关键；面试里能画出 gadget chain 的触发点，比只会说「别用 Java 序列化」高一个层次。

结论：安全做法是「能用 JSON/Protobuf 就别用原生序列化」；必须用时加对象输入过滤 + 白名单 + 版本兼容设计。Serializable 的代价不只是安全，还有性能（反射式读写、体积大）和兼容性（serialVersionUID、字段增删即失效）。

要点：

• 性能代价：原生序列化要写类元数据、走反射（虽有缓存），体积比二进制协议大，序列化/反序列化都不便宜。
• 兼容性代价：serialVersionUID 不一致即 InvalidClassException；即使一致，增删字段也可能语义不兼容；不同 JDK 版本对某些类（HashMap、String）的序列化形式还变过。
• 安全代价：见上一题的 gadget chain。
• 侵入性：类被迫实现 Serializable，还可能被迫把内部结构暴露给序列化器（除非自定义 writeObject/writeReplace）。
• 设计技巧：显式声明 private static final long serialVersionUID；敏感字段标 transient；跨版本用自定义 readObject/writeObject + readResolve（保护单例不被反序列化破坏）。
• Externalizable：完全由你控制 writeExternal/readExternal，体积更小、性能更好，但要求类必须有 public 无参构造器（反序列化时先 new 再 readExternal），且没有默认兼容性处理——字段变更要自己维护版本。适合体积/性能敏感、结构稳定的场景。
• 现代选择：JSON（Jackson）、Protobuf/Thrift（跨语言、Schema 演进友好）、Kryo/FST（仅在完全可信的同构进程间用，且配白名单）。

延伸：把「序列化方式」当架构决策：缓存里存对象优先 JSON/Protobuf，既避开 gadget 风险，又避免跨语言和升级时的隐性不兼容。

结论：这是 JPMS 强封装的结果——JDK 9 起，对 java.base 等模块内部包（如 sun.misc、java.lang.reflect 的私有成员、jdk.internal）的深度反射默认被拒绝，抛 InaccessibleObjectException 或 IllegalAccessError。解决方式是按需在启动参数里显式 --add-opens/--add-exports，或升级依赖库到模块友好的版本。

要点：

• 报错形态：setAccessible(true) 失败抛 InaccessibleObjectException，错误信息里通常明确给出「unable to make X accessible: module A does not "opens B" to C」，照着这行改参数最快。
• 启动参数：--add-opens java.base/java.lang=ALL-UNNAMED 表示把该包向未命名模块（classpath 应用）开放深度反射；--add-exports 是「编译期可见」的对应项。
• 优先级：最佳是升级框架（Spring/Hibernate/Jackson/Mockito 的新版本都已适配），其次是加 --add-opens，最差是退回 JDK 8。
• 为什么 JDK 17 突然爆炸：JDK 16 起默认开启强封装（JEP 396），JDK 17 进一步收紧（JEP 403）把 sun.misc.Unsafe 的内存访问方法也标记为将要移除；所以老代码在 8/11 上「能跑」的反射，到 17 就失败了。
• 常见受影响场景：CGLIB/ByteBuddy 增强 JDK 类、序列化库反射读 String.value/Collections 内部、老版 Mockito 反射注入。
• 排查手段：跑起来加 --illegal-access 相关的诊断、用 -Xlog 看警告、JDeps 分析依赖对 JDK 内部 API 的使用（jdeps --jdk-internals）。
• 云环境注意：参数要同时在开发、CI、容器启动脚本里配置，否则「本地好、线上挂」。

延伸：升级 JDK 前用 jdeps 扫一遍内部 API 依赖，能把「反射被拒」这类问题提前暴露在评估阶段，而不是上线后才发现。

结论：finalize 被废弃（JDK 9 起标记 deprecated，后续版本进一步标记为待移除）的原因是：执行时机和是否执行都不确定、会拖慢 GC、允许对象「复活」、异常会被吞掉。官方替代是显式的 AutoCloseable（try-with-resources），以及内部基于 PhantomReference + 引用队列的 Cleaner。

要点：

• finalize 的问题：
  1. 不保证执行：只有对象被 GC 且终结器线程有空时才跑，程序退出时可能根本不跑；
  2. 时机不确定：可能很晚甚至永不执行；
  3. 性能：带 finalize 的对象至少要额外经历一轮 GC 才能回收，吞吐下降；
  4. 安全：finalize 里可把自己赋给静态字段「复活」对象，异常被静默忽略导致资源泄漏；
  5. 阻塞：finalize 在单线程上执行，慢的 finalize 会拖住整个终结队列。
• PhantomReference + ReferenceQueue：当对象仅剩虚引用时，引用被放入队列，专门线程出队做清理。它是唯一「能感知对象即将被回收」的正规机制，且 get() 恒返回 null，无法复活对象。
• Cleaner（JDK 9，java.lang.ref.Cleaner）：把清理动作注册成 Runnable，对象不可达后由 Cleaner 线程执行。清理动作不能持有被清理对象（否则对象永远不可达），要用静态内部类持有要释放的资源。
• 最佳实践：显式资源管理优先（AutoCloseable + try-with-resources），Cleaner 只作「用户忘 close」的兜底。

public class FileHandle implements AutoCloseable {
    private static final Cleaner CLEANER = Cleaner.create();
    private final Cleaner.Cleanable cleanable;
    private final State state;                   // 静态内部类，含要释放的资源

    FileHandle(File f) throws IOException {
        this.state = new State(f);               // State 不引用 FileHandle
        this.cleanable = CLEANER.register(this, state);
    }
    public void close() { cleanable.clean(); }
}

延伸：JDK 里 DirectByteBuffer 的堆外内存回收正是靠 Cleaner（旧实现是 sun.misc.Cleaner），这也解释了「为什么要靠 GC 才能回收堆外内存」。

结论：Java 集合分两大分支——Collection（单元素）与 Map（键值对），Collections 是工具类而非容器。

Iterable
└── Collection
    ├── List（有序、可重复、有索引）
    │   ├── ArrayList
    │   ├── LinkedList（同时实现 Deque）
    │   └── Vector → Stack
    ├── Set（不可重复）
    │   ├── HashSet → LinkedHashSet
    │   └── SortedSet → TreeSet
    └── Queue / Deque
        ├── LinkedList
        ├── PriorityQueue
        └── BlockingQueue → ArrayBlockingQueue / LinkedBlockingQueue
                            / SynchronousQueue / DelayQueue

Map（键唯一）
├── HashMap → LinkedHashMap
├── Hashtable → Properties
├── SortedMap → TreeMap
└── ConcurrentMap → ConcurrentHashMap

• List/Set/Queue 都继承 Collection；Map 独立成体系，因为操作的是键值对。
• 选择口诀：要索引/顺序用 List，要去重用 Set，要用键查值用 Map，并发场景选 JUC 下的实现。

延伸： 注意 Collection（接口）与 Collections（工具类，提供 sort/unmodifiableList 等静态方法）一字之差；Stack 是遗留类，实现栈优先用 ArrayDeque。

选择：

• 绝大多数场景选 ArrayList：随机访问多、遍历多、尾部追加多。
• LinkedList 实际很少用：它的"O(1) 插入"只在已持有节点引用时成立；按位置插入仍需先 O(n) 遍历到该位置。
• 需要频繁头尾操作当队列用时，优先 ArrayDeque 而非 LinkedList。

延伸： ArrayList 允许 null，非线程安全；LinkedList 因实现 Deque 可当双端队列，但性能不如 ArrayDeque。

结论：默认容量 10（首次 add 时才分配），扩容为原容量的 1.5 倍，扩容时复制整个数组。

• 无参构造把内部数组设为空数组，第一次 add 才分配默认容量 10（懒加载省内存）。
• add 前先 ensureCapacityInternal 检查容量，不足则 grow。
• grow 用位运算 oldCapacity + (oldCapacity >> 1) 得到 1.5 倍，再 Arrays.copyOf 复制。

private Object[] grow(int minCapacity) {
    int oldCapacity = elementData.length;
    // 1.5 倍：右移一位相当于除以 2
    int newCapacity = oldCapacity + (oldCapacity >> 1);
    if (newCapacity - minCapacity < 0) newCapacity = minCapacity;
    return elementData = Arrays.copyOf(elementData, newCapacity);
}

延伸： 扩容要复制数组，成本不低；能预估规模时用 new ArrayList<>(expectedSize) 预分配，避免多次扩容。使用 Arrays.asList 得到的 List 是固定长度的，不支持 add。

• 线程安全：Vector 的方法都加了 synchronized，ArrayList 没有。
• 扩容策略：Vector 默认扩容 2 倍（也可指定 capacityIncrement），ArrayList 是 1.5 倍。
• 初始化：Vector 无参构造默认容量 10 且立即分配；ArrayList 首次 add 才分配。
• 性能：Vector 每次操作都要加锁，单线程下更慢。

现状：Vector 属于遗留类，已不推荐。需要线程安全时，读多写少用 CopyOnWriteArrayList，或使用 Collections.synchronizedList 包装。

延伸： Stack 继承 Vector，同样是遗留类，且因继承了 Vector 可在任意位置插入，破坏了栈语义；实现栈首选 ArrayDeque。

结论：HashSet 内部就是一个 HashMap——元素作为 key，value 是一个固定的占位 Object。

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

    public boolean add(E e) { return map.put(e, PRESENT) == null; }  // 新增返回 null
    public boolean contains(Object o) { return map.containsKey(o); }
}

• 唯一性完全复用 HashMap 的 key 唯一机制：先比 hash，再比 equals。
• 所以存自定义对象到 HashSet 必须同时重写 equals 和 hashCode，否则"相等"的两个对象哈希不同、会进不同桶，去重失效。
• add 返回 true 表示之前不存在（put 新值返回 null）。

延伸： LinkedHashSet = LinkedHashMap（保留插入顺序）；TreeSet = TreeMap（红黑树，按比较器排序，去重靠 compareTo 返回 0 而非 equals）。

• 返回值约定：负数表示前者小，0 表示相等，正数表示前者大。
• 一个类只能有一种自然排序，但可以定义多个 Comparator 应对不同排序需求。

list.sort(Comparator.comparing(User::getAge).thenComparing(User::getName));
list.sort(Comparator.comparing(User::getAge).reversed());

延伸： 用减法实现比较（a - b）在 int 上可能溢出，应改用 Integer.compare。Comparator 认为"相等"必须返回 0，否则会破坏集合语义。

Integer[] arr = {1, 2, 3};
List<Integer> l1 = Arrays.asList(arr);
l1.set(0, 9);
System.out.println(arr[0]);   // 9！写回了原数组

List<String> l2 = List.of("a", "b");
l2.set(0, "c");               // UnsupportedOperationException

int[] nums = {1, 2, 3};
System.out.println(Arrays.asList(nums).size());  // 1，基本类型数组被当成一个元素

延伸： 想要可变列表用 new ArrayList<>(Arrays.asList(...))；unmodifiableList 是视图而非副本，删掉对原列表的引用后才能保证真正不可变。

结论：直接用集合的 remove 会触发 fail-fast，抛 ConcurrentModificationException；应使用 Iterator.remove 或 removeIf。

// 错误：抛 ConcurrentModificationException
for (String s : list) { if (cond(s)) list.remove(s); }

// 正确一：迭代器自己的 remove（会同步 modCount）
Iterator<String> it = list.iterator();
while (it.hasNext()) { if (cond(it.next())) it.remove(); }

// 正确二：Java 8 的 removeIf
list.removeIf(this::cond);

• for-each 底层就是 Iterator，next() 时校验 modCount == expectedModCount，不相等即抛异常。
• Iterator.remove 内部会同步 expectedModCount，所以安全。
• 倒序索引 for 循环删除也安全（不会跳过元素），但不如 removeIf 清晰。

延伸： fail-fast 只是"尽力检测"，不保证一定抛出。另注意 list.remove(int) 与 list.remove(Object) 的重载歧义坑。

结论：1.7 是数组 + 链表；1.8 是数组 + 链表 + 红黑树（链表长度 ≥ 8 且数组长度 ≥ 64 时树化）。

1.7：

• 数组（Entry[]）+ 链表，插入用头插法，新元素放在链表头部。
• 并发扩容时头插会形成环形链表，导致 get 死循环。

1.8：

• 数组（Node[]）+ 链表 + 红黑树；链表长度到 8 且数组容量到 64 才转红黑树，红黑树节点降到 6 退化为链表。
• 插入改为尾插，规避扩容成环问题（但依然非线程安全）。
• 新增 TreeNode（树节点）、ForwardingNode（扩容转移节点）。
• hash 扰动简化：由 1.7 的 4 次移位异或改为 1 次 (h = key.hashCode()) ^ (h >>> 16)。

延伸： 引入红黑树是为了解决极端哈希冲突下链表查询退化为 O(n) 的问题，把最坏情况降到 O(log n)；但仍保留链表，因为树节点内存开销约为普通节点的两倍，多数桶冲突很少。

结论：核心是"算桶下标 → 桶空就放 → 冲突则按链表/红黑树处理 → 判断扩容 → 必要时树化"。

流程：

1. 计算 hash = (h = key.hashCode()) ^ (h >>> 16)。
2. 若 table 为空，先 resize() 初始化。
3. index = (n - 1) & hash 定位桶。
4. 桶为空 → 直接 new Node 放入。
5. 桶不空：头节点 key 相同则记录；是红黑树走 putTreeVal；是链表则尾插，遍历中遇相同 key 就覆盖，否则插到尾部，插完若链表长度 ≥ 8 考虑树化。
6. 若 key 已存在 → 新 value 覆盖旧 value 并返回旧值。
7. ++size > threshold → resize() 扩容。

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 { /* 冲突处理：覆盖 / 链表尾插 / 红黑树插入 */ }
    if (++size > threshold) resize();               // 插入后判断扩容
    return null;
}

延伸： onlyIfAbsent 为 true 时（putIfAbsent）不覆盖已有值；扩容判断在插入之后，所以可能出现"刚插入就扩容"。

结论：为了让 hashCode 的高位也参与桶下标计算，减少哈希冲突——因为下标只用到 hash 的低位。

• 桶下标是 (n - 1) & hash。当 n 较小（如 16）时只有 hash 的低 4 位参与运算，高位信息被浪费。
• 若两个 key 的 hashCode 只有高位不同、低位相同，就会落到同一个桶，冲突加剧。
• h >>> 16 把高 16 位移到低位再与自身异或，等于把高位的特征"混入"低位，让高位也影响下标。
• 只用一次移位加异或，兼顾效果与性能（1.7 做了 4 次，1.8 简化为 1 次）。

static final int hash(Object key) {
    int h;
    return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}

延伸： 这是"高位下移、异或混合"的经典扰动。null key 的 hash 固定为 0，所以 null 永远落在下标 0 的桶。

结论：为了让 (n - 1) & hash 等价于 hash % n，同时保证元素分布均匀。

• 取模运算慢，而 n 是 2 的幂时，hash & (n - 1) 与 hash % n 结果一致，位运算远比除法取模快。
• n - 1 的二进制是全 1（如 16 - 1 = 1111），与 hash 相与会保留 hash 的低位，分布更均匀。
• 若容量不是 2 的幂，n - 1 中存在 0 位，参与运算的有效位变少，某些下标永远取不到，冲突更多。
• 因此传入的初始容量会被 tableSizeFor 向上取整到最近的 2 的幂，扩容也始终乘 2。

static final int tableSizeFor(int cap) {   // 把 cap 上调为最接近的 2 的幂
    int n = cap - 1;
    n |= n >>> 1; n |= n >>> 2; n |= n >>> 4; n |= n >>> 8; n |= n >>> 16;
    return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1;
}

延伸： 容量为 2 的幂还有一个好处：扩容成 2 倍后，元素新位置只可能是"原下标"或"原下标 + 旧容量"，这正是 1.8 rehash 优化不用重算 hash 的基础。

结论：0.75 是"空间利用率"与"哈希冲突概率"之间的折中，也是官方基于泊松分布统计得出的经验值。

• 负载因子 = 元素数 / 容量。越大越省空间但冲突越多，越小冲突少但浪费空间且扩容更频繁。
• 官方注释指出：负载因子为 0.75 时，桶内节点数近似服从参数约 0.5 的泊松分布，冲突概率随负载上升而快速增大，超过 0.75 后链表变长、查询恶化明显。
• 每次扩容都要 rehash，代价高，所以不能设得过小（如 0.5 会频繁扩容）；也不能接近 1.0（冲突严重）。
• 阈值 threshold = capacity × loadFactor，即 16 × 0.75 = 12，元素超过 12 就触发扩容。

延伸： 同一个泊松分布数据也解释了树化阈值为什么定 8（详见下一题）。负载因子可调，但一般不调。

结论：8 是按泊松分布统计出的"链表长度达到 8 的概率极低"的经验阈值；6 是为了留出缓冲，避免在 7 附近反复转换。

• 官方注释：负载因子 0.75 下，桶内节点数近似泊松分布，链表长度达到 8 的概率极小（约为 6e-8 量级）。也就是说正常情况下几乎不会树化，只有哈希被恶意构造或出现极端冲突时才触发。
• 树节点 TreeNode 的内存开销约为普通 Node 的两倍，阈值设太小会浪费内存，所以定在 8，是空间与时间的折中。
• 退化阈值取 6 而不是 7：若等于 7，元素在 7/8 之间反复增删会导致"链表 ↔︎ 红黑树"频繁互转，性能抖动；取 6 留出了缓冲带。

延伸： 还有一个前置条件 MIN_TREEIFY_CAPACITY = 64——若数组长度小于 64，即使链表到 8 也优先扩容而不树化，因为小数组扩容的收益更高。

结论：扩容容量翻倍并把元素重新分配到新数组；1.8 利用"容量是 2 的幂"，元素新位置只可能是原位置或原位置 + oldCap，无需重算 hash。

流程：

1. 容量翻倍（默认 capacity × 2），阈值也翻倍（当容量已达默认初始值以上时）。
2. 遍历旧数组每个桶，把元素搬到新数组。
3. 单节点桶用 newTab[e.hash & (newCap - 1)] = e 直接定位。
4. 链表/红黑树按 (e.hash & oldCap) == 0 分成两组：为 0 的留在原下标 j，为 1 的移到 j + oldCap。

// 1.8 关键：用 oldCap 那一位判断留在原桶还是移动
if ((e.hash & oldCap) == 0) {   // 该位为 0 → 位置不变
    if (loTail == null) loHead = e; else loTail.next = e;
    loTail = e;
} else {                        // 该位为 1 → 移到 j + oldCap
    if (hiTail == null) hiHead = e; else hiTail.next = e;
    hiTail = e;
}

延伸： 因为容量是 2 的幂，扩容后新下标只看 hash 新增的那一位，1.8 这样拆分不用逐个重算 hash，比 1.7 的 rehash 高效；同时 1.7 头插的成环问题也被尾插规避。

结论：HashMap 没有任何同步，多线程 put/扩容会产生数据覆盖、数据丢失，1.7 还会因头插在扩容时形成环形链表导致死循环。

三种典型问题：

• 数据覆盖：两个线程同时 put 到同一个空桶，都判断桶为空，后写的覆盖先写的。
• size 不准 / 数据丢失：size 用普通变量自增，非原子；并发扩容时新旧表交替，可能丢元素。
• 1.7 死循环：并发扩容时链表用头插（transfer 里反转链表），两个线程可能互相引用形成环，之后 get 到该桶会 CPU 100%。

// 1.7 transfer 头插（并发成环的核心）
void transfer(Entry[] newTable) {
    for (Entry<K,V> e : table) {
        while (e != null) {
            Entry<K,V> next = e.next;
            e.next = newTable[i];   // 头插，并发时可能成环
            newTable[i] = e;
            e = next;
        }
    }
}

延伸： 1.8 改尾插后不再成环，但覆盖与丢失问题依旧存在，所以并发场景必须用 ConcurrentHashMap（用 Collections.synchronizedMap 性能差）。

结论：Hashtable 用全表 synchronized 保证线程安全，并发性能差，已被 ConcurrentHashMap 取代；HashMap 允许 null，更适合单线程。

延伸： Hashtable 禁止 null 是因为它直接调用 key.hashCode()，且 put 里显式校验 value 非空；HashMap 对 null key 特判为 hash = 0。Properties 继承自 Hashtable。

结论：LinkedHashMap 在 HashMap 基础上加了一条双向链表维护顺序，默认按插入顺序，构造时传 accessOrder = true 则按访问顺序；重写 removeEldestEntry 即可实现 LRU。

• 每个 Entry 多了 before/after 两个指针，串成双向链表；哈希结构仍复用 HashMap。
• accessOrder = false（默认）：遍历顺序即插入顺序；为 true：每次 get/put 后把该节点移到链表尾部（最近访问）。
• 插入后调用 afterNodeInsertion，其中检查 removeEldestEntry，返回 true 就删除链表头（最久未使用）。

class LRUCache<K, V> extends LinkedHashMap<K, V> {
    private final int capacity;
    public LRUCache(int capacity) {
        super(capacity, 0.75f, true);   // accessOrder = true
        this.capacity = capacity;
    }
    @Override
    protected boolean removeEldestEntry(Map.Entry<K, V> eldest) {
        return size() > capacity;       // 超容量就淘汰链表头（最久未用）
    }
}

延伸： LinkedHashMap 遍历有序、性能好，代价是每个条目多两个指针。生产环境的 LRU 更常用 Caffeine/Guava Cache（实现了 W-TinyLFU 等更优淘汰算法）。

结论：TreeMap 底层是红黑树，按 key 的自然顺序或 Comparator 排序，增删查都是 O(log n)。

• 红黑树是自平衡二叉搜索树，通过若干性质（根为黑、红节点的子节点必为黑、任一节点到叶子的路径黑节点数相同等）把树高维持在 O(log n)，避免退化成链表。
• 插入/删除通过"变色 + 旋转"修复平衡。
• TreeMap 用 key 的 compareTo（或 Comparator.compare）比较，返回 0 即认为相等，所以去重靠比较结果而非 equals。
• 有序性带来了范围查询能力：firstKey/lastKey/headMap/subMap 等，这是 HashMap 做不到的。

TreeMap<Integer, String> tm = new TreeMap<>();
tm.put(3, "c"); tm.put(1, "a"); tm.put(2, "b");
System.out.println(tm);             // {1=a, 2=b, 3=c}
System.out.println(tm.firstKey());  // 1

延伸： key 必须可比较，放入不可比较的 key 会抛 ClassCastException。并发有序映射可用 ConcurrentSkipListMap（跳表实现，比红黑树更适合并发场景）。

结论：fail-fast 在遍历中检测到结构被非法修改就立刻抛 ConcurrentModificationException；fail-safe 遍历快照或弱一致视图，不抛异常但可能读不到最新数据。

fail-fast：

• 集合维护 modCount，迭代器持有 expectedModCount；每次 next()/remove() 校验两者相等，不等即抛异常。
• 典型：ArrayList、HashMap、HashSet 的迭代器。
• 只是"尽力检测"，多线程下不保证一定抛出，应作为 bug 提示而非并发控制手段。

fail-safe：

• 遍历基于副本或弱一致视图。CopyOnWriteArrayList 的迭代器基于创建时的数组快照；ConcurrentHashMap 的迭代器弱一致，能看到部分新数据但不抛异常。
• 代价：可能读到旧数据，CopyOnWrite 创建快照有内存开销。

List<String> l = new ArrayList<>(List.of("a", "b"));
for (String s : l) l.add("c");        // fail-fast：ConcurrentModificationException

List<String> cow = new CopyOnWriteArrayList<>(List.of("a", "b"));
for (String s : cow) cow.add("c");    // fail-safe：遍历的是旧快照，不抛异常

延伸： 单线程下"边遍历边改"同样会触发 fail-fast，不是并发才会；JUC 容器的弱一致性迭代器是"以一致性换稳定遍历"的设计取向。

结论：1.7 用分段锁（Segment 继承 ReentrantLock），并发度等于段数；1.8 抛弃 Segment，改为数组 + CAS + synchronized 锁单个桶头节点，锁粒度更细、并发度更高。

1.7：

• 结构是 Segment[] + HashEntry[]，每个 Segment 是一把 ReentrantLock，默认 16 段，理论并发度 16。
• 一次锁住一个段（段内包含多个桶），不同段互不阻塞。
• 并发度初始化后不可变，段太多浪费空间、太少并发低。

1.8：

• 结构回归 Node[] + 链表 + 红黑树（与 HashMap 一致）。
• 桶为空时用 CAS 无锁插入；桶非空时 synchronized 锁住桶头节点，只锁一个桶。
• 并发度等于桶数量（容量量级），扩容时通过 ForwardingNode 支持多线程协助扩容。

延伸： 1.8 敢用 synchronized 是因为 JVM 对锁做了偏向/轻量/自旋等优化，且只锁单个头节点竞争更小，同时省掉了 Segment 的对象开销。

size 计数（1.8）：

• 不再用加锁的 size 字段（1.7 是累加各 Segment 的 count），而是采用类 LongAdder 的方案：一个基础计数 baseCount + 一个 CounterCell[] 数组。
• 无竞争时 CAS 更新 baseCount；CAS 失败说明有竞争，就随机挑一个 CounterCell 做 CAS 累加，把热点分散到不同缓存行，减少伪共享。
• size() 就是 baseCount 加上所有 CounterCell 的 value 之和，并发下只是弱一致的近似值。

final long sumCount() {
    CounterCell[] cs = counterCells;
    long sum = baseCount;
    if (cs != null)
        for (CounterCell c : cs) if (c != null) sum += c.value;
    return sum;
}

协助扩容：

• 扩容时用 sizeCtl 记录状态（负值表示正在扩容，高位是扩容标识、低位是参与线程数）。
• 每个桶搬迁完成后放一个 ForwardingNode 指向新表；其他线程 put 碰到 ForwardingNode 就调用 helpTransfer 一起搬迁。
• 把扩容成本分摊到多个线程，避免单线程扩容期间的长时间停顿。

延伸： 这正是 LongAdder 的核心思想——用空间换并发，避免高竞争下的 CAS 自旋。size() 是弱一致的，不要用它做精确业务判断。

结论：写时复制——每次修改都复制一份新数组并在副本上修改，然后原子替换数组引用；读操作不加锁，直接读当前数组。

• 内部维护 volatile Object[] array，读（get/遍历）直接访问，天然无锁。
• 写（add/remove/set）先加锁，Arrays.copyOf 复制一份，修改副本，再把 array 指向新数组，最后解锁。
• 迭代器基于创建时刻的数组快照，遍历期间看不到后续修改，也不会抛 ConcurrentModificationException（属于 fail-safe）。

public boolean add(E e) {
    synchronized (lock) {
        Object[] es = getArray();
        int len = es.length;
        Object[] newArr = Arrays.copyOf(es, len + 1);  // 复制
        newArr[len] = e;
        setArray(newArr);                              // 原子替换引用
        return true;
    }
}

适用场景：读多写极少，如监听器列表、白名单配置。 不适用：写频繁（每次写都 O(n) 复制）、数据量大、要求强一致实时读取。

延伸： 本质是"用写成本换读的无锁与遍历安全"；CopyOnWriteArraySet 基于同样机制，写多时同样要避免。

• 核心 API：put/take（阻塞）、offer/poll（带超时或不阻塞）、add/remove（抛异常）。
• 常作为 ThreadPoolExecutor 的工作队列：有界队列可触发拒绝策略实现背压。

BlockingQueue<String> q = new ArrayBlockingQueue<>(100);
q.put("task");                                     // 满则阻塞
String t = q.take();                               // 空则阻塞
boolean ok = q.offer("t", 1, TimeUnit.SECONDS);    // 带超时，false 表示超时

延伸： LinkedBlockingQueue 默认容量是 Integer.MAX_VALUE，生产环境不指定容量会持续堆积任务直至 OOM，务必显式设置边界。

结论：PriorityQueue 底层是二叉小顶堆，用数组存储，offer/poll 都是 O(log n)，peek 是 O(1)；它不保证整体有序，只保证队首是优先级最高（最小）的元素。

• 堆是"完全二叉树 + 每个父节点不大于子节点"的结构，用数组按下标映射：父节点 i，左子 2i+1，右子 2i+2。
• offer：把元素放到数组末尾，再"上浮 siftUp"到合适位置。
• poll：取走堆顶，把末尾元素移到堆顶，再"下沉 siftDown"恢复堆序。
• 默认小顶堆（自然顺序），传 Comparator 可改为大顶堆或自定义优先级。

PriorityQueue<Integer> pq = new PriorityQueue<>();           // 小顶堆
pq.offer(5); pq.offer(1); pq.offer(3);
System.out.println(pq.peek());   // 1
System.out.println(pq.poll());   // 1，弹出后自动调整

PriorityQueue<Integer> maxHeap = new PriorityQueue<>(Comparator.reverseOrder());  // 大顶堆

延伸： PriorityQueue 非线程安全（并发用 PriorityBlockingQueue）；它虽然无界但会随元素增加自动扩容；遍历时元素不保证有序，只有逐个 poll 才有序，因为堆只维护偏序关系。

结论：插入和取出各有一套「四语义」方法，区别只在「队列满/空时怎么办」——抛异常、立即返回、永久阻塞、还是限时等待。选错方法会导致线程被莫名阻塞，或异常在生产环境炸掉。

插入方（队列满时）：

• add(e)：抛 IllegalStateException（用于「必须成功」的场景）
• offer(e)：立即返回 false
• put(e)：阻塞直到有空位或被中断（抛 InterruptedException）
• offer(e, timeout, unit)：等待指定时长，超时返回 false

取出方（队列空时）：

• remove()：抛 NoSuchElementException
• poll()：立即返回 null
• take()：阻塞直到有元素或被中断
• poll(timeout, unit)：等待指定时长，超时返回 null

检查方：

• element()：空时抛异常；peek()：空时返回 null

要点与陷阱：

• BlockingQueue 不允许插入 null，put(null) 抛 NPE；因此 poll() 返回 null 只表示「队空」，语义是明确的。
• take()/put() 会响应中断，必须正确处理 InterruptedException，不能吞掉（否则线程池无法优雅停机）。
• 无界队列（LinkedBlockingQueue 默认容量 Integer.MAX_VALUE）的 put/offer 几乎不会满，容量控制形同虚设，任务堆积可能 OOM。
• 生产者消费者模型优先用 put/take（自动反压）；但 ThreadPoolExecutor 内部用的是 offer（非阻塞入队，满了才走拒绝策略），别混淆。

延伸：面试里把这张表背成「抛异常 / 返回布尔 / 阻塞 / 限时」四列，比零散地记方法名可靠得多。

结论：Deque 是双端队列，同一套接口能当栈、当队列、当双端队列三种用法。做栈或队列时，ArrayDeque 在性能与内存上都优于 LinkedList 和老旧 Stack，Java 官方文档也直接推荐用它替代后两者。

三种用法（用不同方法映射）：

• 当栈：push(e)=addFirst、pop()=removeFirst、peek()=peekFirst
• 当队列：offer(e)=offerLast（入尾）、poll()=pollFirst（出首）、peek()=peekFirst
• 当双端队列：addFirst/addLast/removeFirst/removeLast/getFirst/getLast

为什么选 ArrayDeque：

• 底层是循环数组，内存连续、缓存友好；LinkedList 每个元素一个 Node（item+prev+next 三个引用 + 对象头），内存放大且遍历是「指针追逐」，cache miss 高。
• 头尾操作都是 O(1) 且常数很小；LinkedList 虽然也是 O(1)，但每次都要 new Node、跨越对象边界。
• 不支持 null 元素（LinkedList 支持，但用 null 做哨兵容易踩坑）。
• Stack 继承 Vector，所有方法都 synchronized，单线程下纯属性能浪费，已不推荐使用。

延伸：需要阻塞语义时用 LinkedBlockingDeque；需要并发非阻塞时用 ConcurrentLinkedDeque。

结论：Arrays.asList 返回的是「数组的视图」（长度固定、支持 set、不支持 add/remove）；Stream.toList()（JDK 16+）返回不可变 List（改就抛 UnsupportedOperationException）；Collectors.toList() 返回可变列表，但 JDK 不保证其具体类型。

要点：

• Arrays.asList 底层就是传入的数组（JDK 9+ 是 Arrays 内部 ArrayList），改元素（set）会改原数组，原数组改了 List 也可见——双向绑定。
• Arrays.asList(int[]) 会得到 List<int[]>（长度为 1 的单元素列表），因为基本类型数组不能整体放进泛型——经典坑。
• List.of(x)（JDK 9）真不可变，连 null 都不允许，set/add/remove 全抛异常。
• stream().toList()（JDK 16）：不可变、允许 null，是 stream 场景的推荐写法。
• collect(Collectors.toList())：结果可变、允许 null，但返回类型没保证（实现可能变），需要明确类型时用 toCollection(ArrayList::new)。
• Collections.unmodifiableList 是「包装视图」：原 List 变了它也跟着变，只是不能通过它修改。

延伸：判断口诀——要「视图」用 asList（注意基本类型坑），要「快照且不可变」用 List.of/stream().toList()，要「可变且确定类型」用 toCollection(ArrayList::new)。

结论：集合转数组推荐 list.toArray(new T[0])；数组转集合用 Arrays.asList（视图）或 List.of（拷贝、不可变）。基本类型数组与包装类型集合互转必须显式装箱/拆箱，大数组下有明显的对象分配与内存放大。

要点：

• 集合 → 数组：toArray(new T[0]) 是推荐写法（JDK 会按需分配或复用）；老写法 toArray(new T[list.size()]) 在并发下 size 变化可能出错，现在没必要预分配。
• 数组 → 集合：普通对象数组用 Arrays.asList(arr)（视图，改集合即改数组）；要不可变快照用 List.of(arr)；基本类型数组必须先装箱。
• int[] → List：只能循环或 IntStream.of(arr).boxed().collect(toList())，每个元素创建 Integer（缓存范围外全是新对象），大数组里装箱开销和内存放大都很可观。
• List → int[]：list.stream().mapToInt(Integer::intValue).toArray()。
• 想要包装数组：stream().toArray(Integer[]::new)；基本类型数组则必须走 mapToInt/mapToDouble 的 toArray 重载。
• 性能结论：热路径、大数据量优先用原生数组；List 的每个元素都是独立对象，遍历是「指针追逐」，比 int[] 慢数倍并占用数倍内存。

延伸：这也解释了为什么很多高性能库（如 Netty、JDK 内部）宁可用基本类型数组也不用 List。

结论：ArrayBlockingQueue 用「一把 ReentrantLock + 两个 Condition」，入队与出队互斥；LinkedBlockingQueue 用「两把独立的锁」（putLock 与 takeLock）加各自的 Condition，入队和出队可以并发，因此吞吐更高。Executors 默认线程池用 LinkedBlockingQueue，主要因为它默认近似无界（容量 Integer.MAX_VALUE），任务提交几乎不会被阻塞。

要点：

• ArrayBlockingQueue：单锁，读写互斥；数组连续内存、容量固定，天然有界能反压；构造时可选公平锁（fair=true），代价是吞吐下降。
• LinkedBlockingQueue：双锁（putLock/takeLock），生产者与消费者并行，用 AtomicInteger count 跨锁计数；代价是每个元素一个 Node，内存开销大。
• 为什么线程池选它：保证任务提交不受阻塞、实现简单；但默认无界是隐藏的 OOM 风险，生产环境必须显式设容量。
• 关键陷阱：队列无界会让 maximumPoolSize「形同虚设」——只要队列不满就永远不创建非核心线程，任务只会越堆越多。
• 选型建议：追求高吞吐、能容忍内存开销 → LinkedBlockingQueue（指定容量）；追求稳定延迟与可预期内存 → ArrayBlockingQueue。

延伸：看到 newFixedThreadPool 就应想到「队列无界 + 线程数固定」，高负载下会先堆任务而不是扩线程，所以生产上更推荐自己 new ThreadPoolExecutor 并显式指定有界队列。

结论：SynchronousQueue 不存储元素，每个 put 必须等到一个 take（直接交接），容量为 0。CachedThreadPool 用它 + 无限线程 + 空闲回收，模型是「任务不排队，来一个给一个线程」。其余三种队列各有专属场景。

要点：

• SynchronousQueue：不缓存元素，生产者与消费者直接配对；CachedThreadPool 借此实现「有任务没空闲线程就立刻新建线程」（配合 60s 空闲回收）。
• PriorityBlockingQueue：无界、按优先级出队（底层堆），适合「重要任务先跑」；无界所以 put 不会阻塞，优先级由 Comparator 决定，不支持公平。
• DelayQueue：元素必须实现 Delayed，只有到期才能被 take，适合延迟任务、定时重试、订单超时关闭；底层用 PriorityQueue 按到期时间排序。
• LinkedTransferQueue：兼具队列与 SynchronousQueue 能力，transfer(e) 直接把元素交给等待的消费者，无人等待才入队；JDK 7+ 引入，高吞吐、低延迟的生产者-消费者场景。
• DelayQueue 的坑：take() 会按最早到期时间做条件等待；消费者线程里若执行耗时任务会拖住后续到期元素，最好另起线程执行。

延伸：CachedThreadPool 在任务暴增时会无限创建线程（可能 OOM），所以生产环境更常用「定量核心线程 + 有界队列 + 自定义拒绝策略」。

结论：ConcurrentLinkedQueue 是基于 CAS 的无锁非阻塞队列（Michael-Scott 算法），入队/出队不加锁。它不阻塞（不是 BlockingQueue），适合高并发、允许自旋的场景。HOPS 指 head/tail 指针并不总指向真实的头/尾节点，而是滞后若干个节点，目的是减少每次操作都 CAS 更新 tail 的开销。

要点：

• 入队：把新节点 CAS 挂到 tail.next，成功后再「尝试」CAS 更新 tail，但不强求成功——允许 tail 滞后。
• 出队：CAS 更新 head，head 也可能滞后，真实头节点通过 head.next 找到。
• 为什么滞后（HOPS）：如果每次都精确维护 tail，tail 就成了 CAS 热点；让 tail 落后 1~2 个 hop，多数入队只需一次 CAS 就能提交，显著降低竞争、提升吞吐。
• 与 ArrayBlockingQueue 对比：CLQ 无界、无锁、高吞吐，但无阻塞语义，size() 需要遍历（O(n) 且弱一致），不适合需要精确大小或有界反压的场景。
• 内存：每个元素一个 Node，指针追逐，缓存不友好。
• 适用：高并发生产 + 消费快、不需要阻塞、不需要精确 size 的场景。

延伸：无锁不等于更快——高竞争下 CAS 自旋反而浪费 CPU；吞吐与延迟的取舍要压测决定，别盲目「无锁崇拜」。

结论：跳表用多层索引链表实现有序映射，相比红黑树最大的优势是「无锁并发实现更简单」——插入/删除只需局部 CAS，不需要旋转。ConcurrentSkipListMap 因此能提供线程安全的有序 Map，而 TreeMap 只能靠外部加锁。

要点：

• 跳表结构：底层是完整有序链表，上层是稀疏索引；查找从最高层往右扫描，过大就下一层，平均 O(log n)。
• 相比平衡树：无需旋转（并发下红黑树的旋转难以无锁化），实现简单、并发扩缩友好；代价是索引层额外空间（期望约 2 倍指针）与随机化（层数随机，最坏 O(n) 但概率极低）。
• 并发实现：用 volatile + CAS 更新指针，删除用「标记节点」做逻辑删除以避免 ABA。
• 与 TreeMap：TreeMap 非线程安全、红黑树、按 key 的 Comparable/Comparator 排序；ConcurrentSkipListMap 线程安全、跳表、同样有序，且支持并发读；size() 是估算（遍历计数）。
• 与 ConcurrentHashMap：CHM 不保证有序；需要「有序 + 并发」时用 ConcurrentSkipListMap，典型如按时间排序的索引、排行榜、区间查找。
• 性能：单线程下 TreeMap 通常更快；多线程并发读写时 ConcurrentSkipListMap 吞吐更好。

延伸：理解「跳表是为并发而生的有序结构」这题就通透了；面试常追问「为什么不用红黑树做并发」，答案就落在「旋转无法无锁化」。

结论：没有 ConcurrentArrayList 是设计取舍——「并发 + 数组 + 可随机访问 + 可变长度」很难同时高效：数组扩容、中间插入删除都要整体搬移，无法细粒度无锁化，强行做要么退化成全局锁，要么语义奇怪。官方给了 CopyOnWriteArrayList 用于读多写少，其余场景用别的结构。

可用的替代方案：

• CopyOnWriteArrayList：写时复制整个数组，读无锁、写 O(n) 且内存瞬时翻倍；适合读远多于写的场景（监听器列表、白名单、配置快照）。
• Collections.synchronizedList：包装 + 全局锁，简单但吞吐低，且迭代仍需手动加锁。
• ConcurrentLinkedQueue/ConcurrentLinkedDeque：只需要顺序访问、不需要下标时用。
• ConcurrentHashMap：如果「List」本质是按 key 索引（下标即 key），用 Map<Integer, E> 反而更合适。

为什么不做通用「分段数组 + 无锁扩容」：

• 随机访问要跨段定位，size/迭代语义（弱一致？强一致？）难以定义；
• 数组搬移与 CAS 难以无冲突，收益抵不过复杂度。

延伸：需要并发可变列表且随机访问，往往说明设计本身有问题——要么读多写少（COW），要么需求其实是队列或映射。

结论：CHM 的迭代器基于创建时的 table 快照，遍历中不抛 ConcurrentModificationException，能保证「不重复、不会漏掉已存在的」，但可能看到遍历中新增的元素、也可能看不到刚删除的——这就是弱一致。size() 用 CounterCell 分散计数，只能给出估算值，并发写时可能不准。

要点：

• 弱一致 vs fail-fast：HashMap/TreeMap 靠 modCount 在并发修改时抛 CME；CHM 故意不抛，代价是「看到的内容是模糊的」，不保证强一致。
• 迭代实现：迭代器遍历 table 的每个槽，槽内按链表/树顺序读，构造时并不锁整张表。
• size()：JDK 8 用 baseCount + CounterCell[]（类似 LongAdder）分散计数，sumCount 汇总；并发写时读到的只是某一瞬间的近似值。
• 因此：并发下不要用 size()==0 做判空或临界判断（isEmpty 同样是近似的），需要精确计数请用 LongAdder 或外部原子计数。
• 弱一致的好处：读操作无需加锁，读多写少场景吞吐极高。
• 注意：keySet/values/entrySet 都是视图，同样弱一致；别依赖遍历期间的一致性来写业务逻辑。

延伸：把「弱一致」当作并发容器用法的基本原则——遍历时看到的是「某个时间点的近似快照」，而不是锁住的完整真相。

结论：toMap 默认遇到重复 key 直接抛 IllegalStateException（Duplicate key），必须传合并函数决定保留策略；值为 null 时 toMap 也会 NPE。groupingBy 的第二个参数是下游收集器，可做计数、求和、再分组等聚合。

要点：

• toMap：toMap(k, v) 冲突即抛异常；toMap(k, v, (a,b)->a) 保留先出现的；toMap(k, v, mergeFn, LinkedHashMap::new) 可指定返回的 Map 类型并保序。
• toMap 的 null 坑：内部走 map.merge，merge 不接受 null value，会 NPE；合并函数也不能返回 null。
• groupingBy：默认返回 Map<K, List>；下游收集器示例——groupingBy(k, counting()) 计数、groupingBy(k, summingInt(f)) 求和、groupingBy(k, mapping(f, toList())) 映射后收集、groupingBy(k, toMap(...)) 做多级分组。
• 保序问题：groupingBy 默认返回 HashMap（无序），要保序传 LinkedHashMap::new。
• partitioningBy 只分 true/false 两组，是 groupingBy 的特例。
• 下游用 toList() 得到的 List 可能是不可变的，别假设可以再往里加。

Map<Dept, Integer> cnt = list.stream()
    .collect(groupingBy(Employee::dept, summingInt(Employee::salary)));
Map<String, String> codeToName = list.stream()
    .collect(toMap(Item::code, Item::name, (a, b) -> a)); // 冲突保留先出现的

延伸：复杂分组优先手写循环或复用已有分组结果，嵌套收集器过深会显著牺牲可读性。

结论：LinkedHashMap 可以按「插入顺序」或「访问顺序」迭代，accessOrder=true 时 get/put 会把节点移到链表尾，这是实现 LRU 的基础，但也会让「读操作修改结构」。TreeMap 的 subMap/headMap/tailMap 是视图而非副本，与原 Map 互相影响，越界操作还会抛异常。

要点：

• 迭代顺序：HashMap 是散列顺序（与插入无关，不可依赖）；LinkedHashMap 保插入顺序（默认）或访问顺序（accessOrder=true）；TreeMap 按 key 排序。
• accessOrder：get、getOrDefault、put、compute 等会经 afterNodeAccess 把节点移到链表尾；但 containsKey 不算访问，不会调整顺序，别弄混。
• TreeMap 视图：subMap/headMap/tailMap 是 SortedMap 视图，改视图即改原 Map；一旦在视图外插入越界 key，或对视图做超出边界的操作，可能抛 IllegalArgumentException。
• keySet/values/entrySet 也是视图，反映原 Map 的实时内容。
• LRU 落地：重写 removeEldestEntry，容量超限时移除链表头（最久未访问）——但它是同步的、非线程安全，高并发请用 Caffeine。

延伸：TreeMap 的视图适合做「按区间统计」，但别把它当成独立快照去持有，否则原 Map 变化会以难以预测的方式影响视图。

结论：这三个方法把「先查再放」合并成对 ConcurrentHashMap 近似原子的一步操作，能避免竞态并减少一次哈希查找；但 computeIfAbsent 在 CHM 里会持有 bin 锁执行映射函数，函数里做慢操作或递归操作同一个 Map 会死锁或性能骤降。

要点：

• computeIfAbsent(k, f)：key 不存在（或映射为 null）时用 f 计算并放入；典型用法是「多值 Map 分组」map.computeIfAbsent(k, x -> new ArrayList<>()).add(v)。
• merge(k, v, remapping)：key 不存在直接用 v，存在则用 remapping 合并；remapping 返回 null 会删除该 key。
• 并发坑：CHM.computeIfAbsent 在整个计算期间持有对应 bin 的锁，若 f 里又去改同一个 CHM（尤其同 bin）可能死锁或抛 IllegalStateException（递归更新）；f 执行久会阻塞对该 bin 的其他写入。
• 性能取舍：相比 get + put 少一次哈希查找；但若 value 构造昂贵且命中率高，先用 get 判断反而更快（computeIfAbsent 命中时也会进入锁路径）。
• HashMap 版本非线程安全，并发环境下必须换 CHM 或外部加锁。
• 别滥用：computeIfAbsent 里别做 I/O、远程调用等慢操作。

延伸：需要「缓存语义」（失效、并发加载去重、容量控制）时用 Caffeine 的 get(key, loader) 或 Guava Cache，computeIfAbsent 并不具备这些完整能力。

结论：HashMap 扩容要重新分配 table 并把元素搬移（JDK 8 用高低位拆分减少 hash 计算，但仍需搬移），代价 O(n) 且瞬时内存翻倍。预估容量能避免反复扩容。关键是：容量会向上取整到 2 的幂，且传入值被当成阈值的反推值，所以设置时要「除以负载因子」。

要点：

• 正确姿势：new HashMap<>(expectedSize) 里的参数会被 tableSizeFor 向上取整到 2 的幂，同时构造器把 threshold 设为该值；首次 put 时以此作为容量。真正「不扩容」需要 initialCapacity 满足 tableSizeFor(cap) * 0.75 >= expectedSize。
• 例子：要放 1000 个元素，new HashMap<>(1000) 得到容量 1024、阈值约 768，到 768 就会扩容；应传约 1334（1000/0.75）或直接用 Guava 的 Maps.newHashMapWithExpectedSize(1000)（它内部就是先算 expectedSize/0.75+1 再取整）。
• 其他集合：ArrayList 建议 new ArrayList<>(expected) 避免多次 grow；HashSet 同理（底层 HashMap，构造参数同样会被取整）。
• 不要过度估计：设太大会直接浪费内存；大多数场景默认 16 足够，只有明确大规模时才预估。
• 扩容细节：JDK 8 rehash 用 (e.hash & oldCap) 判断留在原位还是偏移 oldCap，省去重算 hash，但搬移与可能的树化仍存在。

延伸：面试答「除以负载因子」比只答「传个大概的数」高一档；能说清 tableSizeFor 与 threshold 的关系，说明你真看过源码。

结论：理论上头/中插入 LinkedList O(1) 对比 ArrayList O(n)，但实战中「随机访问 + 遍历」占多数，ArrayList 因内存连续、CPU 缓存友好、无额外对象开销，往往全面胜出——即便在「LinkedList 主场」的头部插入上，小规模下也常是 ArrayList 更快。

要点：

• 缓存友好性：ArrayList 元素在连续内存（引用数组）里，遍历预取友好、命中率高；LinkedList 每个节点分散在堆上，遍历是「指针追逐」，每次跳内存、cache miss 高。
• 内存开销：LinkedList 每个元素一个 Node（item+prev+next 三个引用 + 对象头，通常 24~32 字节），还可能内存碎片；ArrayList 只有数组 + 少量冗余容量。元素越多，LinkedList 内存放大越明显。
• 中间插入：LinkedList 插入本身 O(1)，但「找到位置」是 O(n) 遍历且遍历慢；ArrayList 插入要 arraycopy 搬移，但 System.arraycopy 是内存块操作、常数极低。
• 适用面：只有「频繁头尾增删 + 不随机访问 + 元素不多」时 LinkedList 才可能有优势；而栈/队列场景 ArrayDeque 又全面更好。
• 结论：现代代码几乎不用 LinkedList；需要链表语义时优先 ArrayDeque 或专用结构。

延伸：这类题别只背「增删快/查询快」的口诀，要能说出「缓存局部性」和「常数因子」——这才是面试官想听的实战认知。

结论：用「对象头 + 字段 + 对齐 + 引用大小」逐项累加，或用 JOL（Java Object Layout）实测。关键变量：集合的容量冗余、装箱、Node 开销、指针压缩（-XX:+UseCompressedOops 时引用 4 字节）都会显著改变结果。

要点：

• 参照系：对象头通常 12 字节（数组对象头 16 字节），对象大小按 8 字节对齐；开启指针压缩（堆 < 32GB 时默认）引用是 4 字节，否则 8 字节。
• ArrayList 100 万：数组本身约 100 万 × 4 字节 = 4MB；但每个 Integer 对象（缓存范围外）约 16 字节，合计约 16MB + 数组，共约 20MB——装箱是大头。
• 对比：同一个 100 万用 int[] 只要 4MB；这就是「能用基本类型数组就别用包装集合」的量化理由。
• LinkedList 100 万：每个 Node 约 24~32 字节 + 每个元素（若是 Integer）16 字节 + 两个方向指针，轻松上百 MB。
• HashMap 100 万：table 约 200 万个槽（负载因子 0.75，容量取 2^21），每槽 4 字节约 8MB，再加每个 Node 约 32 字节与 key/value，通常数百 MB。
• 估算工具：JOL（org.openjdk.jol）打印对象布局，堆 dump 用 MAT 看 retained size；别凭感觉。

延伸：面试里能给出「Integer 对象约 16 字节、压缩指针 4 字节」这类量级，比只会说「大概几十 MB」可信得多。

结论：HashMap 用 key 的 hashCode 定位桶、用 equals 比较。如果 key 放入后其参与 hashCode/equals 的字段被修改，hashCode 就变了，再 get 会被定位到错误的桶，导致「明明在却取不到」；若它还被不断作为新 key 反复 put，就会堆出大量逻辑相等的条目——内存泄漏。

要点：

• 定位失效：桶位置由 hash 决定，hash 变了就取不到；除非新旧 hash 恰好落同一桶且 equals 仍为 true（通常也变了）。
• 泄漏机制：遍历修改中的对象作为 key 反复 put，每次 hash 不同都被当作新 key，entry 只增不减；这些 key 指向的对象可能早已无用，却因被 Map 强引用而无法回收。
• 典型场景：缓存以「可变实体」为 key，实体字段一更新，缓存命中率骤降、内存持续增长。
• 解决：①key 用不可变对象（String、Integer、LocalDate、record 或自建不可变值对象）；②必须用可变对象时，只用稳定字段（如 id）参与 hashCode/equals；③缓存应交给带淘汰策略的组件（Caffeine/Guava Cache），裸 HashMap 无上限即泄漏。

延伸：判断标准很简单——「作为 key 后，参与 hashCode 的字段是否还会变」。会变，就不适合当 key。

结论：WeakHashMap 的 key 是弱引用（WeakReference）。当 key 对象没有其他强引用时，GC 会回收它，随后 ReferenceQueue 里的条目在下次操作 map 时被清理，对应 value 一并释放。它适合「给对象挂额外元数据」——对象没了，数据也没必要留。

要点：

• 实现：Entry 继承 WeakReference，key 是弱引用；map 内部维护一个 ReferenceQueue，每次 get/put/size 前先把已入队的失效 Entry 清掉（expungeStaleEntries），所以 size() 也是「懒清理」后的近似值。
• 对比强引用缓存：HashMap 的 key 被强引用，对象永不回收（泄漏）；WeakHashMap 允许 key 自然消失。
• 致命前提：value 不能强引用 key（否则 key 无法回收，弱引用形同虚设）。
• 陷阱：
  1. 不能当缓存用：没有容量上限、没有过期策略、GC 时机不确定，条目可能突然消失；
  2. 用不可变对象（String 字面量、Integer 缓存值）做 key 无效——它们被常量池/缓存强引用，永不回收；
  3. 需要确定的清理时机时，应自己做引用队列 + 定期清理，或用 Caffeine 的 weakKeys/weakValues。
• 相关：ThreadLocalMap 的 key 也是弱引用（WeakReference），保证 ThreadLocal 对象没人用后能回收；但 value 是强引用，忘记 remove 仍会泄漏。

延伸：能说清「key 弱、value 强」和「懒清理」这两点，就抓住了 WeakHashMap 的全部要害。

结论：长生命周期对象（单例、ApplicationContext、静态注册表）持有一个集合，集合里装着短生命周期对象（监听器、订阅者），后者被强引用，永远不会回收——本质是「生命周期错配」导致的泄漏。

要点：

• 典型：静态 List 里 add 了页面/会话级监听器，页面销毁却不 remove；事件总线（Guava EventBus）、观察者模式、WebSocket 会话表、Spring 事件监听器注册都容易出现。
• 为什么难发现：集合作为 GC Root 可达对象一直引用监听器，而监听器又可能引用页面、Activity、大对象，整条链路都活着。
• 解决方案：
  1. 显式注销：在生命周期结束（close/onDestroy）时 remove，最好用 try-finally 或框架提供的 unregister；
  2. 用弱引用集合（但注意监听器若被别处强引用则无效）；
  3. 用有界 + 过期策略：Caffeine/Guava Cache 存监听器，设 weakKeys/expireAfterAccess；
  4. 改为订阅-取消模型（如 Reactor 的 Disposable、RxJava 的 CompositeDisposable.dispose()）。
• 排查：用 MAT 找「某个集合 retained size 异常大」，看 GC root 路径是否指向单例/静态字段。
• 红线：静态集合 + 无界增长 = 必然泄漏，哪怕用了弱引用也要小心。

延伸：别只盯集合——ThreadLocal、无上限缓存、内部类隐式持有外部实例，同样是「生命周期错配」这类泄漏的常见来源。

结论：System.arraycopy 是最底层的原生拷贝（可指定源/目标偏移与长度，支持区域内重叠复制）；Arrays.copyOf 是封装，自动分配新数组并按类型截断/补零；clone 按对象语义浅拷贝整个数组，返回 Object 需转型。性能上三者最终都走 JVM intrinsic（优化成内存块复制），差别主要在语义与是否新建数组。

要点：

• System.arraycopy(src, srcPos, dest, destPos, length)：不创建数组，由调用方提供目标；异常更严格（越界、类型不匹配抛异常）；支持同一数组内重叠复制。
• Arrays.copyOf(original, newLength)：内部 new 数组 + System.arraycopy；newLength 大于原长补默认值（0/null），小于则截断；有各基本类型重载，避免装箱。
• clone()：数组 clone 是浅拷贝，元素引用仍指向原对象；返回类型为 Object（数组除外，JLS 规定数组 clone 返回实际类型），没有长度参数。
• 选型：①在已有数组里搬移/局部复制 → System.arraycopy；②要「复制成长度可变的新数组」→ Arrays.copyOf/copyOfRange；③快速整份复制且类型已知 → arr.clone()，可读性最好；④对象/二维数组要独立副本必须自己做深拷贝。
• 性能：一维基本类型数组复制，三者本质相同（intrinsic），差异可忽略；二维数组 clone 只复制外层引用，不是深拷贝。

延伸：这题的陷阱在「浅拷贝」——数组 clone、copyOf 对对象元素都只复制引用，改副本里的对象会影响原数组，深拷贝必须显式处理。

结论：进程是资源分配的基本单位，线程是 CPU 调度的基本单位，同一进程内的线程共享内存与文件句柄等资源。

• 进程拥有独立地址空间；线程共享所属进程的堆、方法区、文件描述符，但各自拥有独立的程序计数器、虚拟机栈、本地方法栈（私有栈）。
• 进程切换要切换页表、刷新 TLB，开销大；线程切换只需保存/恢复寄存器和栈，开销小，但同进程线程切换仍要陷入内核态。
• 一个进程崩溃不影响其他进程；而一个线程抛出未捕获异常，通常会导致整个 JVM 进程退出。
• 因为线程更轻量，Java 用「多线程」做并发；但也因此线程间通信靠共享内存（必须同步），而进程间通信要走 IPC（管道、socket、共享内存等）。

延伸： 追问「协程」时答：协程是用户态调度、切换不陷入内核，JDK 21 的虚拟线程就是这种思路。

结论：继承 Thread、实现 Runnable、实现 Callable + FutureTask、使用线程池；工程中一律优先线程池。

• 继承 Thread：重写 run()，写法简单，但受单继承限制，且「线程对象」与「任务」耦合。
• 实现 Runnable：把任务与执行分离，可再继承别的类，是推荐的基础方式，但无返回值、不能抛受检异常。
• 实现 Callable + Future/FutureTask：有返回值、可抛异常、可取消。
• 线程池：复用线程、控制并发数、统一管理生命周期，生产环境首选。

// Callable + FutureTask
FutureTask<Integer> task = new FutureTask<>(() -> 1 + 1);
new Thread(task, "calc").start();
System.out.println(task.get()); // 阻塞直到取到结果 2

延伸： 严格说线程池不算全新的底层方式，它最终还是创建 Thread；面试时先答前三种，再补充线程池是工程实践方式更稳妥。

结论：Runnable 无返回值、不能抛受检异常；Callable 有返回值且能抛异常，其返回值通过 Future 获取。

• Future 是「凭据」：get() 阻塞取结果，isDone() 判断完成，cancel() 尝试取消（任务已开始则依赖中断）。
• get(long timeout) 可避免无限阻塞，超时抛 TimeoutException。
• Future 的短板是「获取结果只能阻塞或轮询」，无法编排回调，这正是 CompletableFuture 出现的原因。

延伸： 追问「get() 抛什么异常」：任务内部异常会被包装成 ExecutionException；get() 自身还可能抛 InterruptedException（等结果时被中断）。

结论：Java 用 Thread.State 定义了六种状态，注意它把「就绪 + 运行」合并成了 RUNNABLE（对应操作系统层面是否分到 CPU 由 JVM 之外决定）。

                 new Thread()
   NEW ────start()────► RUNNABLE ────run()结束/异常────► TERMINATED
                          │  ▲
      synchronized 未抢到 │  │ 抢到锁
                          ▼  │
                       BLOCKED

   RUNNABLE ──wait()/join()/park()──► WAITING ──notify()/notifyAll()/被打断──► RUNNABLE
   RUNNABLE ──sleep(t)/wait(t)/join(t)──► TIMED_WAITING ──超时/被唤醒──► RUNNABLE

• NEW：已创建未 start。
• RUNNABLE：可运行（含操作系统里的就绪与运行），也包括正在进行 IO 而未被阻塞的线程。
• BLOCKED：等待进入 synchronized 临界区（等锁）。
• WAITING：无限期等待，需被显式唤醒（notify、join 结束、LockSupport.unpark）。
• TIMED_WAITING：限时等待，超时自动返回。
• TERMINATED：run 执行完毕或异常退出，不可复生。

延伸： 常见坑：调用 Lock.lock() 未抢到锁时状态是 WAITING 而非 BLOCKED，因为 AQS 用的是 LockSupport.park。

结论：sleep 是 Thread 的静态方法，只让出 CPU 不释放锁；wait 是 Object 的实例方法，会释放持有的监视器锁并进入等待队列。

• sleep 不释放锁，所以它常被用来「模拟耗时」；若在临界区内 sleep，其他线程会一直等锁。
• wait 释放锁后线程进入该对象的等待集（wait set），被唤醒后还需重新竞争锁才能从 wait() 返回。

延伸： 追问「sleep(0) 有用吗」：它让当前线程让出 CPU 但保留锁，语义上等价于「提示调度器可以切换」。

结论：join 让当前线程等待目标线程结束，yield 只是提示调度器让出 CPU、当前线程回到就绪态，不保证一定让出。

• t.join()：当前线程阻塞直到 t 执行完毕，底层是 wait/notify（循环判断 t.isAlive()），join 前会获取 t 对象的锁；join(t) 带超时。
• Thread.yield()：静态方法，把当前线程从运行态退回 RUNNABLE，让调度器重新选择；不释放锁、不改变其他状态。
• 典型用法：主线程 fork 多个子线程后逐个 join，等全部完成再汇总结果（这也是 CountDownLatch 的简易替代）。
• yield 语义弱、依赖具体 JVM 实现，不可用于同步逻辑；需要严格协调请用并发工具类。

延伸： join 本质是「等待线程终止」这条 happens-before 规则的具体实现：线程内所有操作 happens-before 其他线程从 join 返回。

结论：修饰实例方法、静态方法、代码块三种用法，锁对象分别是「当前实例」「Class 对象」「括号里的对象」。

• 关键点：锁的是「对象」不是「方法」，只有锁的是同一个对象才会互斥。
• 常见坑：用 synchronized(this) 包住对 String 常量、Integer 缓存对象的加锁（如 synchronized("abc")），可能与其他代码共享同一把锁而意外互斥。
• 锁对象建议用 private final Object lock = new Object();，避免外部可见被外部抢锁。

延伸： 追问「锁为什么不能是 String 字面量」：字符串常量池会复用同一对象，跨类可能锁到同一个，导致无关业务互相阻塞。

结论：因为等待/唤醒围绕的是「对象的监视器锁（monitor）」，而任何对象都可以作为锁，所以方法只能定义在 Object 上。

• Java 的同步机制是「以对象为锁」，每个对象都有一把监视器锁和一个等待集，wait/notify 操作的正是这个等待集，与「是哪个线程」无关。
• 若定义在 Thread 上，则只能针对某个线程等待/唤醒，无法表达「所有在对象 X 上等待的线程」，与锁模型不匹配。
• 必须在 synchronized 内：wait 会「释放锁并进入等待集」，前提是当前线程必须持有该对象的锁，否则抛 IllegalMonitorStateException；同时这也避免了 wait 与其期望条件之间的竞态（检查条件 + 进入等待必须原子）。
• notify 同样要持有锁，因为它要操作该对象的等待集。

延伸： 为什么用 while 而不是 if 包住 wait？被唤醒后条件未必成立（被虚假唤醒/被多个 notify 唤醒但只该走一个），必须循环重新检查条件。

结论：interrupt 不是强杀，而是「设置中断标志」，线程是否响应由自己决定；正确姿势是捕获 InterruptedException 后恢复中断标志或退出循环。

• t.interrupt() 置位中断标志；若线程正阻塞在 wait/sleep/join/LockSupport.park，会抛 InterruptedException 并清除中断标志。
• Thread.interrupted() 返回并清除当前线程标志；isInterrupted() 只查询不清除。
• 优雅停止：用 volatile boolean running 或 Thread.currentThread().isInterrupted() 做循环条件，捕获中断后 break，并在 catch 里 Thread.currentThread().interrupt(); 把中断传递上去。

public void run() {
    while (!Thread.currentThread().isInterrupted()) {
        try {
            doWork();
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt(); // 恢复标志，向上传递
            break;                              // 退出循环，结束线程
        }
    }
}

延伸： 不要用 stop()（已废弃，会释放所有锁导致数据不一致），也不要吞掉 InterruptedException 而不恢复标志。

结论：JMM（Java 内存模型）是规范，定义了多线程下共享变量的读写规则；它抽象出「主内存（共享）+ 工作内存（线程私有）」的模型，用来屏蔽底层缓存与指令重排差异。

• 主内存：所有共享变量所在处（可理解为堆）；工作内存：每个线程的私有副本（可理解为 CPU 缓存 + 寄存器的抽象）。
• 线程对共享变量的操作必须经过「读主内存到工作内存 → 修改 → 写回主内存」，因此默认情况下线程 A 的修改对 B 不立即可见 = 可见性问题。
• 有序性问题：编译器、CPU 会在不改变单线程语义的前提下对指令重排，多线程下就会出问题。
• 原子性问题：i++ 不是原子操作（读-改-写三步），需要同步。
• JMM 通过 volatile、synchronized、final 提供的 happens-before 规则，来给出「什么情况下保证可见与有序」的契约。

延伸： JMM 还定义了 8 种内存交互操作（lock/unlock/read/load/use/assign/store/write），面试可一笔带过，重点讲 volatile 与 happens-before。

结论：volatile 保证可见性和有序性，但不保证原子性。

• 可见性：写 volatile 变量会立即刷回主内存并使其他线程的缓存行失效；读时会从主内存重新读取。
• 有序性：禁止编译器和 CPU 对 volatile 操作前后进行特定重排，从而充当内存屏障。
• 实现原理（JMM 层）：通过插入内存屏障实现——写前 StoreStore，写后 StoreLoad；读前 LoadLoad，读后 LoadStore。x86 上写屏障通常编译成带 lock 前缀的指令，同时兼顾可见性与屏障效果。
• 不保证原子性：volatile int i; i++ 仍是三步操作，多线程下会丢失更新，需用 synchronized 或 AtomicInteger。

延伸： volatile 的典型场景是「一写多读的状态标志」和 DCL 单例；long/double 的 32 位原子性问题也常被追问（非 volatile 的 long 读写可能撕裂，volatile 可保证）。

结论：happens-before 是 JMM 给出的「前一个操作的结果对后一个操作可见」的判定规则，符合规则就无需额外同步也能保证可见性与有序性。

1. 程序顺序规则：同一线程内，书写在前的操作 hb 在后的操作。
2. 监视器锁规则：对同一把锁的 unlock hb 后续对它的 lock。
3. volatile 变量规则：对 volatile 变量的写 hb 后续对该变量的读。
4. 线程启动规则：Thread.start() hb 新线程中的任意操作。
5. 线程终止规则：线程内所有操作 hb 其他线程检测到该线程终止（如 join() 返回）。
6. 线程中断规则：interrupt() 的调用 hb 被中断线程检测到中断。
7. 对象终结规则：对象构造函数执行结束 hb 其 finalize() 开始。
8. 传递性：A hb B 且 B hb C，则 A hb C。

延伸： 注意 hb 是「可见性保证」而非「时间先后」；两条操作没有 hb 关系就是数据竞争，结果不确定。

结论：两者都是可重入互斥锁；synchronized 由 JVM 隐式管理、写法简单，ReentrantLock 由 AQS 实现、功能更灵活，非必要不加锁即优先 synchronized。

• 选择原则：能用 synchronized 就用，代码简洁、无需担心忘记解锁；需要「超时、可中断、多条件、公平」时才用 ReentrantLock。
• ReentrantLock 的典型场景：定时锁、可中断锁、读写分离、多条件队列（如阻塞队列）。

延伸： 两者都可用的情况下，synchronized 不易因异常漏解锁而出错；Lock 必须写在 try 外 lock、try 内业务、finally 里 unlock。

结论：Condition 是 AQS 提供的「多等待队列」条件变量，把 Object 的 wait/notify 单一等待集拆成多组，可精准唤醒。

• await() 释放锁并进入该 Condition 的等待队列；signal() 把等待队列首节点移入 AQS 同步队列等待重新竞争锁；signalAll() 唤醒全部。
• 一个 Lock 可 newCondition() 多次，得到多个独立条件队列，避免 notifyAll 的「惊群」。
• 相比 wait/notify：Condition 的 await/signal 必须在 lock/unlock 之间调用，否则抛 IllegalMonitorStateException；且支持 awaitUninterruptibly()、awaitNanos() 等增强。
• 典型应用：有界阻塞队列中 notFull 与 notEmpty 两个条件，生产者只唤醒消费者、消费者只唤醒生产者。

延伸： 追问「signal 是立即唤醒吗」：不是，只是把节点从条件队列转移到同步队列，被唤醒线程要重新抢到锁才从 await 返回。

结论：ThreadLocal 的本质是「以 ThreadLocal 为 key、存在 Thread 自己身上的一个 Map（ThreadLocalMap）」，每个线程各存一份互不干扰。

• 结构：Thread 持有 ThreadLocalMap，Map 的 Entry 是 ThreadLocal 的弱引用作 key、值为强引用；所以数据实际挂在 Thread 上，而非 ThreadLocal 上。
• 一个 ThreadLocal 可以对应多个线程的多份值；同一个线程里不同 ThreadLocal 是不同的 key。
• 内存泄漏根因：Entry 的 key 是弱引用，ThreadLocal 实例被回收后 key 变成 null，但 value 仍被 Map 强引用；若线程长期存活（线程池），这些 value 就一直无法回收。
• 正确用法：用完必须 finally { tl.remove(); }；线程池场景尤其重要，否则不仅泄漏还会把上个请求的数据带给下个请求。

private static final ThreadLocal<User> CTX = new ThreadLocal<>();
try {
    CTX.set(user);
    // ... 业务
} finally {
    CTX.remove();   // 线程池中必须清理，防止泄漏与上下文串味
}

延伸： 追问「为什么 key 用弱引用」：这样 ThreadLocal 对象本身可被回收；但 value 的清理依赖 Map 的探测式清理（get/set 时顺带清除 key 为 null 的 Entry），不主动 remove 就有风险。

结论：七大参数决定线程池「怎么建线程、怎么排队、满了怎么办」；执行流程是「核心线程 → 队列 → 非核心线程 → 拒绝」。

        提交任务 execute()/submit()
                 │
                 ▼
      运行线程数 < corePoolSize ？ ──是──► 新建核心线程执行
                 │否
                 ▼
            任务队列未满？ ──是──► 入队等待
                 │否
                 ▼
      运行线程数 < maximumPoolSize ？ ──是──► 新建非核心线程执行
                 │否
                 ▼
            执行拒绝策略 handler

七大参数：corePoolSize（核心线程数）、maximumPoolSize（最大线程数）、keepAliveTime（非核心线程空闲存活时间）、unit（时间单位）、workQueue（任务队列）、threadFactory（线程工厂，可自定义名字）、handler（拒绝策略）。

四种拒绝策略：

延伸： 易错点：核心线程满了不是直接建新线程，而是先入队——所以无界队列会让 maximumPoolSize 形同虚设。

结论：四种内置线程池分别是 Fixed、Single、Cached、Scheduled；阿里规约禁止是因为它们用无界队列或超大最大线程数，容易 OOM。

• 无界队列：任务堆积只增不减，堆内存被打满。
• Cached/Scheduled：maximumPoolSize 近似无限，来多少任务建多少线程，可能耗尽内存或引发 OOM。
• 正确做法：用 new ThreadPoolExecutor(...) 显式指定有界队列（如 ArrayBlockingQueue）与合理的拒绝策略，并自定义 threadFactory 命名线程。

延伸： 追问「SynchronousQueue 有何特点」：不存储元素，生产者必须等消费者接手，适合任务与线程数匹配、要求快速交接的场景。

结论：CompletableFuture 把 Future 的「阻塞取值」升级为「链式回调 + 多任务编排」，是异步编程的主力。

• 创建：supplyAsync（有返回值）、runAsync（无返回值），默认用 ForkJoinPool.commonPool，也可传入自定义线程池。
• 串行转换：thenApply（同类型转换，Function）、thenAccept（消费结果）、thenRun（不关心结果）。
• 扁平化：thenCompose（结果是另一个 CompletableFuture 时用它做「扁平化」，避免嵌套）。
• 组合：thenCombine（合并两个独立结果）、allOf（等全部完成）、anyOf（任一完成）。
• 异常：exceptionally（兜底返回值）、handle（无论成败都处理）、whenComplete（观察，不改变结果）。

CompletableFuture<String> f1 = CompletableFuture.supplyAsync(() -> "A");
CompletableFuture<String> f2 = CompletableFuture.supplyAsync(() -> "B");
CompletableFuture<String> both = f1.thenCombine(f2, (a, b) -> a + b)
        .exceptionally(ex -> "fallback");           // 合并 + 兜底

CompletableFuture<Void> all = CompletableFuture.allOf(f1, f2);
all.thenRun(() -> System.out.println(f1.join() + f2.join())); // allOf 无返回值，需 join 取

延伸： 注意 allOf 返回 CompletableFuture<Void>，要汇总结果需再对每个 future join()；thenApply 与 thenCompose 的差别就是「映射 vs 扁平化」。

结论：三者都是同步器，Latch 是一次性「等一批任务完成」，Barrier 是「多线程互相等齐再出发」且可重用，Semaphore 是「限流互斥（控制并发数）」。

• CountDownLatch：countDown() 减 1，await() 等到 0；只能单向等待一次。
• CyclicBarrier：每个线程到 await() 处等待，凑齐 N 个一起继续，可传入 barrierAction 在到达时执行，适合多轮迭代。
• Semaphore：acquire() 拿许可（无许可则阻塞）、release() 归还，可做限流、控制同时访问某资源的线程数。

延伸： 追问「Latch 与 Barrier 关键差别」：Latch 是「我做完了通知别人」，计数减到 0 主线程走人；Barrier 是「大家到齐了才一起走」，且能重置后重复使用。

结论：new 对象不是原子操作，可能出现「引用已赋值但对象未初始化」的中间态，所以 DCL 的实例字段必须用 volatile 禁止这种重排。

• 对象创建的三步：① 分配内存；② 执行构造初始化；③ 把引用赋给变量。②和③之间可能重排成 ①→③→②。
• 若发生重排，B 线程在第一次 null 检查时看到引用非 null，就会拿到一个「半初始化」对象。
• volatile 写后插屏障，禁止 ③ 提前到 ② 之前，从而保证其他线程看到引用非 null 时对象已初始化完毕。

// ❌ 错误版：instance 没有 volatile，可能读到半初始化对象
public class Singleton {
    private static Singleton instance;
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) instance = new Singleton(); // 可能重排
            }
        }
        return instance;
    }
}

// ✅ 正确版：加 volatile，禁止 2、3 步重排
public class Singleton {
    private static volatile Singleton instance;
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) instance = new Singleton();
            }
        }
        return instance;
    }
}

延伸： 更推荐的写法是静态内部类（类加载保证线程安全且惰性）或枚举单例；DCL 加 volatile 是面试考点，不是最优工程写法。

结论：synchronized 的字节码是 monitorenter/monitorexit，底层靠对象头 Mark Word 与 monitor 实现，并通过「偏向锁 → 轻量级锁 → 重量级锁」升级来降低开销。

• 同步代码块：编译为 monitorenter / monitorexit（正常、异常各一个 exit，保证释放）。
• 同步方法：用方法访问标志 ACC_SYNCHRONIZED 隐式加解锁。
• 锁信息存在对象头的 Mark Word 里，锁升级只升不降（一个线程持有并释放后仍保留升级后的状态）：
  • 偏向锁：第一个线程获取后，Mark Word 记录线程 ID，之后该线程重入无需 CAS（某较新版本已默认禁用/移除，JDK 15 起偏向锁默认关闭）。
  • 轻量级锁：出现竞争时，用 CAS 把 Mark Word 指向栈上的 Lock Record，失败则自旋。
  • 重量级锁：自旋失败或竞争激烈，膨胀为 monitor，未抢到的线程进入阻塞（内核态，开销大）。
• 为什么足够好：JDK 6 起做了大量优化（自适应自旋、锁消除、锁粗化、偏向/轻量级锁），在无竞争或低竞争下开销已接近 CAS，且由 JVM 自动管理、不会漏解锁。

延伸： 面试常问「锁升级为什么只升不降」：降级收益有限且实现复杂，HotSpot 选择不降级以简化；但竞争消失后新线程仍可快速获取。

结论：AQS（AbstractQueuedSynchronizer）用「一个 volatile 的 state + 一个 CLH 变体的双向等待队列 + 模板方法」把「排队、阻塞、唤醒」的通用逻辑抽出来，子类只需实现状态获取/释放。

• state：volatile int，语义由子类定义（ReentrantLock 中表示重入次数，Semaphore 中表示许可数，CountDownLatch 中表示剩余计数）。
• CLH 队列：FIFO 双向队列，节点 Node 记录线程与 waitStatus，未抢到锁的线程入队后通过 LockSupport.park 阻塞。
• 模板方法：acquire/release 是最终方法，tryAcquire/tryRelease/tryAcquireShared/tryReleaseShared 交由子类重写。

// AQS 关键字段（简化）
private volatile int state;          // 同步状态
private transient Node head, tail;   // CLH 变体双向队列

protected boolean tryAcquire(int arg) {    // 子类实现
    throw new UnsupportedOperationException();
}
public final void acquire(int arg) {       // 模板方法：抢 → 排队 → 自旋/阻塞
    if (!tryAcquire(arg) &&
        acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
        selfInterrupt();
}
public final boolean release(int arg) {    // 释放并唤醒后继节点
    if (tryRelease(arg)) { Node h = head;
        if (h != null && h.waitStatus != 0) unparkSuccessor(h);
        return true; }
    return false;
}

流程：acquire 先 tryAcquire 一次，失败则 addWaiter 入队，acquireQueued 中自旋（前驱是 head 时再试一次），仍失败则 park；release 时 tryRelease 成功后唤醒 head 的后继。

延伸： AQS 支持独占（ReentrantLock）与共享（Semaphore、CountDownLatch）两种模式；追问可补「自旋 + park 结合」是为了兼顾响应速度与 CPU 占用。

结论：差异只在 tryAcquire 里——公平锁多了一行 hasQueuedPredecessors() 判断，有前驱排队就让位，非公平锁直接 CAS 抢。

• 非公平锁：线程无论队列里有没有人，先 compareAndSetState(0, 1) 抢一把，抢到就跑，没抢到才排队。
• 公平锁：先判断队列中有无前驱节点，有则老老实实排队，保证先来后到。
• 因此公平锁吞吐通常更低（多了判断、且频繁上下文切换），但能避免线程饥饿。
• ReentrantLock 默认非公平，可通过 new ReentrantLock(true) 指定公平。

// 非公平：直接 CAS 抢锁
final boolean nonfairTryAcquire(int acquires) {
    if (compareAndSetState(0, acquires)) { setExclusiveOwnerThread(Thread.currentThread()); return true; }
    if (Thread.currentThread() == getExclusiveOwnerThread()) { // 重入
        setState(getState() + acquires); return true;
    }
    return false;
}
// 公平：先看队列前面有没有人
final boolean fairTryAcquire(int acquires) {
    if (!hasQueuedPredecessors() && compareAndSetState(0, acquires)) { // 多这一行判断
        setExclusiveOwnerThread(Thread.currentThread()); return true;
    }
    // 重入逻辑同上
    return false;
}

延伸： 非公平不代表「乱序到底」，它只在「刚释放锁的瞬间」允许插队，队列内仍基本 FIFO，所以效率高又不会严重饥饿。

结论：读写锁让「读读并发、读写/写写互斥」，写锁可降级为读锁、读锁不能升级；StampedLock 在此之上提供乐观读，读性能更高但不支持重入。

• ReentrantReadWriteLock：把 state 高 16 位当读锁、低 16 位当写锁；支持公平/非公平；适合读多写少。
• 锁降级：持有写锁时再获取读锁，然后释放写锁——保证这段「更新 + 读取」不被其他写打断。读锁不能升级为写锁，因为升级需等待其他读锁释放，而自己持有读锁会导致永久等待（死锁）。
• StampedLock：提供 writeLock()、readLock()、tryOptimisticRead()。乐观读先返回一个 stamp，读取后用 validate(stamp) 校验期间有没有写发生，没发生就无需加锁，性能更高。

long stamp = lock.tryOptimisticRead();   // 乐观读：不加锁
int x = this.x, y = this.y;              // 读取共享数据
if (!lock.validate(stamp)) {             // 期间有写过 → 退化为悲观读
    stamp = lock.readLock();
    try { x = this.x; y = this.y; } finally { lock.unlockRead(stamp); }
}
// 用 x、y 计算

延伸： StampedLock 不可重入、不支持中断，且乐观读期间必须「先拷数据再校验」，校验失败要重读；适合读极多、写极少的场景。

结论：CAS（Compare And Swap）是「比较内存值与期望值，相等才更新」的原子操作，靠 CPU 的 cmpxchg 指令实现；它存在 ABA 问题，用带版本号的 AtomicStampedReference 解决。

• 三个操作数：内存地址 V、旧的预期值 A、新值 B；V==A 时把 V 更新为 B，否则不做，返回是否成功，失败通常自旋重试。
• Java 中通过 Unsafe.compareAndSwapInt 等调用底层原子指令，不加锁即可保证原子性。
• ABA 问题：线程 1 读到的值是 A，线程 2 把它改成 B 又改回 A，线程 1 的 CAS 仍成功，但它并不知道中间发生过变化。对「只关心最终值」的场景无害，对「栈/链表等结构」可能出错。
• 解决：用版本号，AtomicStampedReference 每次修改同时递增 stamp，比较时值 + 版本都一致才更新。

AtomicStampedReference<Integer> ref = new AtomicStampedReference<>(100, 0);
int stamp = ref.getStamp();
// 只有值与版本号都是 (100, 0) 时才更新为 50，版本 +1
boolean ok = ref.compareAndSet(100, 50, stamp, stamp + 1);

延伸： CAS 的三大缺点：自旋消耗 CPU（高竞争下空转）、只能保证单个变量原子性（多个变量需 AtomicReference 封装或加锁）、存在 ABA。

结论：原子类分「基本类型 / 引用类型 / 数组 / 字段更新器 / 累加器」五类，均基于 CAS；LongAdder 通过「分段累加 + Cell 分散热点」大幅降低高并发下的 CAS 冲突。

• 基本类型：AtomicInteger、AtomicLong、AtomicBoolean。
• 引用类型：AtomicReference、AtomicStampedReference（带版本，解 ABA）、AtomicMarkableReference（带布尔标记）。
• 数组：AtomicIntegerArray 等，可对数组元素原子更新。
• 字段更新器：AtomicIntegerFieldUpdater 等，对普通 volatile 字段做原子更新，省对象。
• 累加器：LongAdder、DoubleAdder、LongAccumulator，适合高并发计数统计。

LongAdder 快的原理：

• AtomicLong 所有线程 CAS 同一个 value，高并发下大量自旋失败，是单点热点。
• LongAdder 内部维护一个基础值 base 加一个 Cell 数组；线程按哈希分散到不同 Cell 上累加，冲突少了；sum() 时把 base 与所有 Cell 汇总。
• Cell 用 @Contended / 填充字节（padding）避免伪共享（多个 Cell 落在同一缓存行导致缓存行来回失效）。

延伸： LongAdder 的 sum() 不是强一致快照，只适合计数；若需要「原子读改写并立即判断」，还得用 AtomicLong。

结论：InheritableThreadLocal 能在「创建子线程时」把父线程的值复制给子线程，但线程池复用线程会失效；TransmittableThreadLocal（阿里开源）通过装饰任务，解决线程池场景的上下文传递。

• InheritableThreadLocal：重写 childValue，在 new Thread() 时把父线程的 InheritableThreadLocalMap 复制到子线程。问题：线程池里的线程是复用的，创建时机远早于任务提交，拿到的可能是「第一次创建时」的旧值或错值。
• TransmittableThreadLocal（TTL）：在任务提交时捕获当前上下文快照，任务执行前后做 set/restore，执行完恢复原值，因此每次提交都能带上正确的上下文。
• 使用方式：用 TtlExecutors.getTtlExecutorService(pool) 装饰线程池，或对 Runnable/Callable 做 TtlRunnable/TtlCallable 包装。

// 线程池场景：需要 TTL 而非 InheritableThreadLocal
TransmittableThreadLocal<String> ctx = new TransmittableThreadLocal<>();
ExecutorService pool = TtlExecutors.getTtlExecutorService(
        Executors.newFixedThreadPool(4));
ctx.set("req-1");
pool.submit(() -> System.out.println(ctx.get())); // 正确输出 req-1

延伸： 追问「MDC 链路追踪怎么传」：Logback 的 MDC 底层也是 ThreadLocal，异步/线程池场景同样需要 TTL 或框架提供的包装方案。

结论：ForkJoinPool 用于把大任务「分治（fork）」成小任务并行处理再「合并（join）」结果，其核心是工作窃取：空闲线程从其他线程队列尾部偷任务，提高 CPU 利用率。

• 每个工作线程维护一个双端队列（deque）：自己产生的子任务从头部取（LIFO，局部性好），空闲线程从其他线程队列尾部窃取（FIFO，减少冲突）。
• 任务需继承 RecursiveTask<V>（有返回值）或 RecursiveAction（无返回值），在 compute() 里判断是否达到阈值，否则 split 后 fork。
• 相比普通线程池，ForkJoin 的子任务由同一批线程以更轻量的方式调度，避免为每个子任务建线程。
• 适合「可递归拆分、子任务独立、结果可合并」的计算型任务，如大数组求和、归并排序、并行流底层。

class SumTask extends RecursiveTask<Long> {
    private final int[] a; private final int lo, hi;
    SumTask(int[] a, int lo, int hi) { this.a = a; this.lo = lo; this.hi = hi; }
    protected Long compute() {
        if (hi - lo <= 1000) {                 // 阈值足够小，直接算
            long s = 0; for (int i = lo; i < hi; i++) s += a[i]; return s;
        }
        int mid = (lo + hi) >>> 1;             // 否则拆分
        SumTask l = new SumTask(a, lo, mid), r = new SumTask(a, mid, hi);
        l.fork(); return r.compute() + l.join(); // 一个 fork，一个直接算
    }
}

延伸： 注意并行粒度——拆分过细会导致任务调度开销超过收益；fork 后建议先 compute 一个子任务再 join，避免线程空等。

结论：死锁需同时满足「互斥、请求与保持、不可剥夺、循环等待」，破其一即可；排查用 jstack <pid> 会直接打印死锁线程与锁持有关系。

• 互斥：资源同一时刻只能被一个线程占用。
• 请求与保持：持有资源的同时又在请求别的资源。
• 不可剥夺：已获得的资源不能被强制抢走。
• 循环等待：多个线程形成首尾相接的环形等待链。
• 预防：最常用「破坏循环等待」——所有线程按同一顺序加锁；或加超时 tryLock(timeout) 主动放弃。

Object a = new Object(), b = new Object();
new Thread(() -> { synchronized (a) { sleep(100);
    synchronized (b) { System.out.println("T1"); } } }).start();
new Thread(() -> { synchronized (b) { sleep(100);
    synchronized (a) { System.out.println("T2"); } } }).start();
// 两个线程各持一把锁又互相等，形成循环等待 → 死锁

排查：

top -Hp <pid>              # 找到 CPU/负载异常的线程
printf '%x\n' <tid>        # 线程号转 16 进制
jstack -l <pid> > /tmp/s.txt   # 输出线程栈
grep -A 30 "deadlock" /tmp/s.txt  # jstack 会自动报告 Found one Java-level deadlock

延伸： jstack 会打印「Found one Java-level deadlock」并列出各线程 waiting to lock 与 locked 的对象；线上还可用 Arthas 的 thread -b 直接定位阻塞源头。

结论：核心线程数没有万能公式，CPU 密集型取「核数 + 1」，IO 密集型取「核数 × (1 + 等待时间/计算时间)」，但必须结合压测和监控落地。

• CPU 密集型（加解密、计算）：线程数 ≈ CPU 核数 + 1，多一个用于补偿偶发页缺失等问题。
• IO 密集型（DB、RPC、文件）：线程数 ≈ 核数 × (1 + 等待时间/计算时间)，因为线程大部分时间在等待 IO，可多开。
• 排队论思路：先按公式估一个初值，再用真实流量压测，观察 CPU 利用率、队列积压、RT 与拒绝次数，逐步收敛；不要迷信公式。
• 监控：给 ThreadPoolExecutor 自定义子类或在提交处埋点，采集 corePoolSize、maximumPoolSize、activeCount、queue.size、completedTaskCount、rejectedCount，接入监控看板/告警。
• 动态调参：ThreadPoolExecutor 提供 setCorePoolSize、setMaximumPoolSize、setKeepAliveTime（队列容量不易动态改），可结合配置中心下发，实现不重启调参；注意最大线程数不能小于核心线程数。

ThreadPoolExecutor pool = new ThreadPoolExecutor(
    8, 16, 60, TimeUnit.SECONDS,
    new ArrayBlockingQueue<>(200),                 // 有界队列，防 OOM
    r -> new Thread(r, "biz-" + r.hashCode()),     // 命名线程，便于排查
    new ThreadPoolExecutor.CallerRunsPolicy());    // 背压，避免任务被丢

pool.setCorePoolSize(12);       // 运行期动态调整（配合配置中心）
int active = pool.getActiveCount();
int queued = pool.getQueue().size();               // 监控活跃线程与队列积压

延伸： 关键业务建议「线程池隔离」——不同依赖用不同池，避免一个慢接口拖垮全部；队列务必有界，无界队列在流量突增时是 OOM 的定时炸弹。

结论：每个线程内部持有一个 Parker 对象（在 Thread.parker 字段），它内部维护一个二元许可（permit），初值为 0。park() 消费许可：许可 >0 就立即返回，否则阻塞；unpark(t) 把目标线程许可置 1 并唤醒它。

• 关键在于许可是可预先发放、且最多累积 1 次的。所以 unpark 可以先于 park 执行——先把许可发出去，之后 park 发现许可已存在，直接消费返回，不会阻塞。连续 unpark 两次只算一次许可，不会「欠两个」。
• park() 底层是 Unsafe.park(isAbsolute, time, blocker)，最终落到 Parker 的 _counter 判断 + 互斥量/条件变量的 native 等待。
• park 不要求持有任何锁；unpark 也不需要目标线程在 park 中——这正是它比 wait/notify 灵活的地方。
• park(Object blocker) 只是把阻塞对象记录到线程的 parkBlocker，供 jstack 打印，便于定位「谁阻塞在哪」，没有锁语义。

为什么这么设计： 许可模型让「唤醒」不必与「等待」配对先后，避免了 wait/notify 那种「先 notify 后 wait 会丢失信号」的竞态。代价是不支持多个许可累积，也不需要（AQS 靠状态和队列来记录等待者数量，不靠许可计数）。

延伸： AQS 的 LockSupport.park(this) 传入的是节点或当前锁对象，jstack 中会显示 parking to wait for <0x...>，排障时很有用。

结论：wait/notify 是对象监视器（monitor）层面的等待通知，必须先持有 synchronized 锁；park/unpark 是线程级的阻塞原语，不需要锁，也不抛中断异常。二者设计目标不同。

• wait/notify 绑定在某个对象的监视器上：wait 必须在 synchronized(obj) 内调用，notify 只能唤醒等待该 obj 监视器的线程，且只能随机唤醒一个或全部，无法精确指定。
• park/unpark 以线程为对象，unpark(t) 精确唤醒指定线程，park 无需持锁，因此在实现锁、信号量等同步器时更底层、更灵活（AQS 内部就只用 park/unpark）。
• notify 的「信号」不可预存：先 notify 后 wait，wait 会永远睡下去；而 park 的许可能预存，这也是「先 unpark 再 park」成立的原因。
• 中断语义不同：wait 抛 InterruptedException 并清除中断位；park 遇中断直接返回且不抛异常，由调用方自行 Thread.interrupted() 判断。

延伸： 选择原则——实现业务同步用 Condition（语义清晰、支持多条件队列）；实现同步器底层原语用 park/unpark（无锁约束、许可机制）。

结论：Node.waitStatus 用一个 volatile int 表示节点在队列中的状态，只有 CANCELLED(1) 是正数，其余为负或 0，源码里用 > 0 判断「节点已被取消」正是利用这一约定。

• 0：默认初始值。新 addWaiter 出来的节点、以及刚刚把后继唤走的头节点都可能处于 0。
• SIGNAL(-1)：后继节点需要被唤醒。当前节点在释放锁时，负责 unpark 它的后继。入队阻塞前，前置节点会被 CAS 设成 SIGNAL。
• CANCELLED(1)：节点因超时或中断被取消，是唯一大于 0 的状态。判断队列里「有没有被取消的前驱」就靠 waitStatus > 0。
• CONDITION(-2)：节点当前在条件队列（ConditionObject）中等待，而不是在同步队列。
• PROPAGATE(-3)：共享模式下，releaseShared 需要把唤醒继续向后传播，这个状态用于避免共享信号丢失。

为什么只有 CANCELLED 是正数： 状态判断常写成 if (pred.waitStatus > 0) 跳过 或 if (... < 0) 需要唤醒，用正负号把「已取消」和「有效等待」区分开，可以用一次比较表达「是否为有效节点」，减少判断次数。这是 AQS 作者 Doug Lea 的经典位技巧。

延伸： shouldParkAfterFailedAcquire 会把前驱的 CANCELLED 状态通过 pred = pred.prev 剪掉，并在必要时清理 head 之后的取消节点，避免队列无限增长。

结论：acquire 是一条「先试抢占、失败就入队、入队后循环竞争、必要时挂起」的流水线，由五个方法串联：tryAcquire → addWaiter → acquireQueued → shouldParkAfterFailedAcquire → parkAndCheckInterrupt。

public final void acquire(int arg) {
    if (!tryAcquire(arg) &&
        acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
        selfInterrupt();               // 争到锁但曾被中断，补上中断标记
}

• tryAcquire(arg)：由子类实现。非公平锁直接 CAS 抢 state 并设置持有者；公平锁先看 hasQueuedPredecessors()，队列有前驱就放弃抢占。
• addWaiter(Node.EXCLUSIVE)：把当前线程包成独占节点，先 CAS 快速接到队尾（tail），失败则进 enq() 自旋 + CAS 保证入队。
• acquireQueued(node, arg)：自旋。若 node.prev == head（有资格竞争）就 tryAcquire，成功则把 node 设为新 head 并返回；否则调用下一环决定是否挂起。
• shouldParkAfterFailedAcquire(pred, node)：前驱 SIGNAL 则返回 true 可以 park；前驱 CANCELLED(>0) 则向前跳过；否则 CAS 把前驱设为 SIGNAL，下一轮再 park。
• parkAndCheckInterrupt()：LockSupport.park(this) 后 return Thread.interrupted()，返回并清除中断标记。

为什么「前驱是 head 才竞争」： 保证 FIFO——只有队首的直接后继有资格抢锁，避免所有节点被唤醒后一起 CAS 造成惊群与无谓自旋。

延伸： 若线程在挂起期间被中断，但最终拿到了锁，acquireQueued 返回 true，外层用 selfInterrupt() 把中断标志补回，保证中断不被吞掉（这是「响应中断但不提前退出」的语义）。

结论：因为 AQS 同步队列是 FIFO 的双向链表，只有 head.next 有资格竞争锁；唤醒其他人只会造成惊群和 CAS 空转，所以 release 只唤醒「第一个有效后继」。

• release 的核心是 tryRelease 成功后调用 unparkSuccessor(head)：
  1. 若 head.waitStatus < 0，先 CAS 把它改回 0（表示「唤醒职责已履行」）；
  2. 取 node.next，若为 null 或已 CANCELLED，就从尾部向前扫描找到离 head 最近的有效节点，再 LockSupport.unpark(s.thread)。
• 为什么要「从尾部向前」找：next 指针在并发入队时可能暂时为 null（节点先接上 tail 的 prev 才补 next），而 prev 一定已就绪，所以从 tail 沿 prev 回溯是可靠的。
• 被唤醒的节点在 acquireQueued 中因「前驱是 head」而获得一次 tryAcquire 机会，抢到就上 head 位。

为什么不全部唤醒： 非公平锁下若把所有等待者都 unpark，它们一起 CAS 抢同一个 state，绝大多数会失败并重新入队，白白消耗 CPU（惊群效应）。只唤醒队首后继，把竞争规模压到最小，也让唤醒顺序接近 FIFO。

延伸： 这也是「非公平锁仍然大致公平」的原因之一：刚释放锁的瞬间若有个新线程恰好来抢，它可能插队成功；但一旦进入队列，就会老老实实排队被逐个唤醒。

结论：独占模式一次只能一个线程持有（acquire/release），共享模式允许多个线程同时持有（acquireShared/releaseShared）。差别集中在 tryAcquireShared 的返回值语义和「唤醒传播」上。

• 独占：tryAcquire 返回 boolean；state 通常表示重入次数（ReentrantLock）或持有标记。
• 共享：tryAcquireShared 返回 int——负值表示失败，0 表示成功但后续共享线程不能再获取，正数表示成功且还能再获取。state 通常表示剩余许可数（Semaphore）或读锁计数（RRWL 的读锁）。
• 共享的关键在唤醒传播：独占节点上 head 后只唤醒一个后继；共享模式下拿到锁的节点会通过 setHeadAndPropagate 继续唤醒后续共享节点，doReleaseShared 也会循环把信号往队尾传，直到没有可传播的目标。

为什么共享需要传播： 独占模式下「一个锁只有一个持有者」，唤醒一个就够；共享模式下可能有多个线程能同时获取（如剩余许可 3），若只唤醒一个，剩下的许可就没人来拿，会导致其他等待者永久阻塞——所以要传播唤醒。

延伸： CountDownLatch、Semaphore、ReentrantReadWriteLock 的读锁都是共享模式；ReentrantLock、写锁是独占模式。

结论：PROPAGATE(-3) 是共享模式专用的中间状态，用来保证「一次释放能唤醒多个共享等待者、且信号不丢失」。它是为修复早期共享唤醒丢失的 bug 而引入的。

• 问题场景：共享锁释放时 doReleaseShared 在无锁状态下循环，两个线程可能同时读写 head 的 waitStatus，一个把它从 SIGNAL 改成 0，另一个又看到 0 认为「无需唤醒」，于是本应传播的唤醒被吞掉，部分共享等待者永远拿不到锁（JDK-6801020）。
• 引入 PROPAGATE 后：setHeadAndPropagate 判断条件放宽为 propagate > 0 || h.waitStatus < 0，看到 -3 也会继续 doReleaseShared，从而把唤醒一路传下去。
• 代码层面 doReleaseShared 对 head 的 CAS 会在 0 与 PROPAGATE 之间切换，正是为了留下「还需要继续传播」的痕迹。

private void doReleaseShared() {
    for (;;) {
        Node h = head;
        if (h != null && h != tail) {
            int ws = h.waitStatus;
            if (ws == Node.SIGNAL) {              // 有后继在等
                if (!h.compareAndSetWaitStatus(Node.SIGNAL, 0)) continue;
                unparkSuccessor(h);               // 唤醒队首后继
            } else if (ws == 0 &&
                       !h.compareAndSetWaitStatus(0, Node.PROPAGATE))
                continue;                          // 留下 PROPAGATE 供后续传播
        }
        if (h == head) break;
    }
}

延伸： 面试里说清「PROPAGATE 是为了解决共享模式下唤醒信号丢包」即可，不必背 CAS 细节，但能说出 setHeadAndPropagate 这个名字会加分。

结论：把 32 位的 state 按高位/低位切开——高 16 位是读锁持有数（sharedCount），低 16 位是写锁持有数（exclusiveCount，即写重入次数）。一个 int 同时承载两种锁的计数，节省内存且让读写在同一个 AQS 上协调。

state (32 bit)
 ┌──────────────────┬──────────────────┐
 │  高 16 位         │  低 16 位         │
 │  读锁持有总数     │  写锁重入次数     │
 └──────────────────┴──────────────────┘
 SHARED_SHIFT   = 16
 SHARED_UNIT    = 1 << 16
 MAX_COUNT      = (1 << 16) - 1 = 65535
 sharedCount(c) = c >>> 16
 exclusiveCount(c)= c & 0xFFFF

• 读锁：采用共享模式，tryAcquireShared 每次给高 16 位加 1（即 state 加 SHARED_UNIT）；每个线程的读重入次数单独存在 ThreadLocal<HoldCounter>（并用 cachedHoldCounter 做缓存），因为读是多个线程共享的，不能像写锁那样只记一个持有者。
• 写锁：采用独占模式，tryAcquire 每次给低 16 位加 1，且只有当高 16 位为 0（没有读锁）时才允许获取；获取成功还会记录 exclusiveOwnerThread。
• 计数上限 65535，超出抛 Error（不是异常），这是用 16 位省空间的代价。

为什么不拆成两个字段： 读写锁必须互相感知——写锁要判断「当前有没有读锁」，读锁要判断「有没有写锁」。共用一个 state 就能用一次 CAS 原子地完成读写状态的判断与更新，而两个独立字段需要额外协调，反而更难做无锁原子操作。缺点是计数被限制在 16 位。

延伸： getReadHoldCount() 会读 ThreadLocal，注意它统计的是当前线程的读重入次数，不是全局读锁总数；全局总数用 getReadLockCount()（读高 16 位）。

结论：因为升级会死锁，降级是安全的。所谓降级指「持有写锁时先获取读锁，再释放写锁」，让线程在放弃写权限后仍保有读权限。

• 不支持升级（读 → 写）：设想线程 A、B 都持有读锁，现在 A 想升级为写锁，它必须等 B 释放读锁；但 B 也在等 A 释放读锁才能升级，或 B 只是持有读锁不释放——双方永远等不到，形成死锁。因此 ReentrantReadWriteLock 直接不支持在读锁上获取写锁（会一直阻塞）。
• 支持降级（写 → 读）：先 writeLock.lock()，再 readLock.lock()，最后 writeLock.unlock()。由于写锁是独占的，降级期间没有其他写者能介入，读锁必然能拿到，不会相互等待。

readWriteLock.writeLock().lock();   // 先持写锁
try {
    // 更新共享数据
    readWriteLock.readLock().lock();   // 降级：先拿读锁
} finally {
    readWriteLock.writeLock().unlock(); // 再放写锁，此后仍持读锁
}
try {
    // 此时其它线程无法写，本线程看到的仍是自己刚写的数据
} finally {
    readWriteLock.readLock().unlock();
}

降级的意义： 保证「释放写权限后，本线程视角的数据不会被其他写者改动」，常用于缓存更新——写完缓存后要立刻再读一次做校验，降级能避免中间被别的写线程插入。

延伸： 降级不是自动的，必须手动按顺序获取读锁；常见的错误是直接 writeLock.unlock() 后再 readLock.lock()，那中间就出现了空窗，其他写线程可能已修改数据。

结论：在非公平模式下，读锁是共享的，源源不断的读请求可以不断「插队」成功，导致写请求长期拿不到锁——这就是写锁饥饿。

• 成因：写锁要成功，必须等到当前没有任何读锁。非公平模式下，新来的读线程不管队列里是否已有等待的写者，只要 state 高 16 位没写锁就 CAS 抢读锁，于是读锁计数始终 >0，排队的写线程永远等不到「读锁归零」的时刻。
• 公平模式缓解：readerShouldBlock() 在公平模式下调用 hasQueuedPredecessors()——若队列里已有等待者（尤其是排在前面的写者），读线程就不能插队，必须排队。这样写者前面的读请求逐渐清空后，写者就能拿到锁。
• 代价：公平模式牺牲吞吐量，且 reentrantReadWriteLock 本身鼓励读多写少；写饥饿严重时更推荐 StampedLock（乐观读不阻塞写）。

为什么这么设计： 非公平模式用「允许插队」换取更高的吞吐（减少线程挂起/唤醒），但代价就是可能饿死写者；公平模式把顺序保证放在吞吐之前。工程上要按读写比例选：读远多于写且能容忍写延迟时可用非公平 + StampedLock，写也不能长时间挨饿时用公平模式。

延伸： ReentrantReadWriteLock 的公平/非公平在构造器 new ReentrantReadWriteLock(true) 指定，默认非公平。

结论：StampedLock 有三种模式——写锁（悲观独占）、悲观读锁（共享）、乐观读（不加锁，只拿 stamp）。核心创新是乐观读：读之前先拿一个版本戳，读完用 validate(stamp) 校验期间有没有写锁介入。

• 写锁 writeLock()：独占，返回 stamp，unlockWrite(stamp) 释放。
• 悲观读锁 readLock()：共享，返回 stamp，unlockRead(stamp) 释放。会阻塞写锁。
• 乐观读 tryOptimisticRead()：不加锁，仅当「当前没有写锁持有」时返回一个非 0 的 stamp（否则返回 0，表示不可乐观）。

long stamp = lock.tryOptimisticRead();
double x = this.x, y = this.y;         // 读共享字段
if (!lock.validate(stamp)) {           // 期间有写锁介入 → 校验失败
    stamp = lock.readLock();           // 退化为悲观读，重读
    try { x = this.x; y = this.y; }
    finally { lock.unlockRead(stamp); }
}
// 此后 x、y 为一致快照

为什么快： 乐观读在读多写少场景下绝大多数时候 validate 都通过，全程无锁、无 CAS、无阻塞，吞吐远高于 ReentrantReadWriteLock。校验失败才退化，代价可控。

注意事项（坑）： StampedLock 不可重入，同一个线程重入会死锁；不支持 Condition；stamp 必须原样传回对应的 unlock，否则状态错乱。所以它适合「纯读多写少、无重入需求」的场景，不适合替换所有读写锁。

延伸： 乐观读读取字段时要注意字段本身不能是「未发布」的共享可变对象，且 validate 之后不要再做写操作再依赖这次读——校验只覆盖 stamp 有效期内。

结论：一个 Lock 可以有多个 Condition，每个 Condition 各有一个条件队列（单向链表，firstWaiter/lastWaiter）；节点在条件队列与 AQS 同步队列之间来回转移，构成完整的等待-通知闭环。

• 节点进入条件队列用 addConditionWaiter()，其 waitStatus 被设为 CONDITION(-2)。
• await：入条件队列 → 释放锁 → 挂起。此时节点在条件队列。
• signal：把条件队列首节点通过 transferForSignal() 转移到同步队列（enq），并把 waitStatus 从 CONDITION 改为 0，必要时把前驱 CAS 成 SIGNAL。节点此时回到同步队列。
• 被唤醒后，节点在同步队列里按 AQS 规则重新竞争锁。

为什么需要两个队列： 条件队列解决「等待某个条件成立」的语义（可以有多个不同条件、不同队列）；同步队列解决「等待获取锁」的语义。二者职责分离，一个锁可以挂多个条件队列，await 才能只唤醒「等同一条件」的线程，比 Object.wait 只有单一等待集更精细。

延伸： Object 只有一个等待集，notify 无法区分等待原因；Condition 支持多等待集（如生产者队列、消费者队列各一个），这是它相对 wait/notify 的核心优势。

结论：await 是一条「入条件队列 → 释放全部锁 → 挂起 → 被 signal 后转入同步队列 → 重新竞争锁 → 恢复重入次数」的完整链路。

public final void await() throws InterruptedException {
    if (Thread.interrupted()) throw new InterruptedException();
    Node node = addConditionWaiter();          // ① 入条件队列
    int savedState = fullyRelease(node);       // ② 释放全部重入锁
    int interruptMode = 0;
    while (!isOnSyncQueue(node)) {             // ③ 还在条件队列就挂起
        LockSupport.park(this);
        if ((interruptMode = checkInterruptWhileWaiting(node)) != 0) break;
    }
    if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
        interruptMode = REINTERRUPT;           // ④ 重新竞争锁，恢复重入次数
    if (node.nextWaiter != null) unlinkCancelledWaiters();
    if (interruptMode != 0) reportInterruptAfterWait(interruptMode);
}

• ① addConditionWaiter 把线程包成 CONDITION 节点接进条件队列。
• ② fullyRelease 一次性释放当前线程的全部重入计数（savedState 保存下来），因为必须完全释放锁，其他线程才能进入。
• ③ 循环 park，直到节点被 signal 转移到同步队列（isOnSyncQueue 为 true）或检测到中断。
• ④ acquireQueued(node, savedState) 在同步队列中重新竞争锁，并用 savedState 恢复原来的重入次数。

为什么保存并恢复 savedState： 锁是可重入的，await 前线程可能持有了 N 次锁。完全释放后，回来时必须恢复到 N 次，否则重入语义被破坏，后续 unlock 次数对不上会导致锁提前释放。

延伸： await 被中断时有两种策略——await 抛 InterruptedException（THROW_IE）；但若节点已被 signal 才中断，则锁获取成功后再补中断（REINTERRUPT），避免信号丢失。这个细节是 Condition 实现里比较精妙的地方。

结论：因为条件队列不参与锁竞争，被唤醒的线程必须重新回到「等待获取锁」的队列，才能安全地继续执行临界区。直接唤醒会让它绕过锁的获取规则，破坏语义。

• signal 要求当前线程必须持有锁（isHeldExclusively() 校验，否则抛 IllegalMonitorStateException）。
• signal 取出条件队列首节点，调用 transferForSignal(node)：
  1. 若 waitStatus 已不是 CONDITION（节点被取消），跳过；
  2. 否则把节点 enq 到同步队列尾，waitStatus 改为 0；
  3. 若前驱被取消或 CAS 设 SIGNAL 失败，就立即 LockSupport.unpark 该节点线程。
• 醒来的线程在同步队列里正常排队竞争锁，抢到后从 await 返回。

为什么不直接唤醒： 条件队列只是一个「等条件」的集合，里面节点的 waitStatus 是 CONDITION，不具备锁竞争语义。若直接让被 signal 的线程抢锁，它会绕过同步队列的 FIFO 排序与 head 后继机制，公平性和正确性都无从保证。转运到同步队列后，一切按 AQS 标准流程走。

延伸： 这也是「一个条件对象的 signal 只影响本条件队列」的原因——不同 Condition 的节点在各自的队列里，signal 只转移本队列的节点，互不干扰。

结论：因为线程被唤醒不等于条件已经成立。wait/await 存在虚假唤醒（spurious wakeup）——没有 notify/signal 也可能返回；即使有 signal，条件也可能被其他线程抢先消费。所以醒来后必须用 while 重新检查条件。

• 虚假唤醒：操作系统实现上，park/pthread_cond_wait 允许在没有被显式唤醒的情况下返回，这是规范允许的行为，Java 的 Object.wait 文档也明确要求用循环包裹条件判断。
• 条件被抢占：即使是被正常 signal 唤醒，也可能有另一个线程先醒来并发执行、改变了条件（如把队列里的元素取走），轮到本线程时条件已不成立。
• 用 if 的后果：只判断一次，一旦虚假唤醒或条件被抢占，线程会在条件不满足时直接向下执行，读到错误状态（如从空队列取元素、抛出异常或得到脏数据）。

// 正确：while 重新检查条件
synchronized (queue) {
    while (queue.isEmpty()) {     // 醒来后仍要再确认一次
        queue.wait();
    }
    return queue.remove();
}
// 错误：if 只检查一次，虚假唤醒或竞争下条件可能已不成立

为什么这么设计： 底层同步原语只保证「被唤醒」这个事件，不保证「条件为真」这个语义——把条件判断交给上层用循环表达，是更通用、更正确的方式，也避免了原语层面为消除虚假唤醒付出不必要代价。

延伸： if 版本在单生产者单消费者且唤醒可靠时「看起来能跑」，但一旦有多个等待者、或 OS 出现虚假唤醒就会出问题，因此任何语言的条件变量都应统一用 while。

结论：Semaphore 内部用一个继承 AQS 的 Sync，state 就是剩余许可数；acquire 对应 AQS 的 acquireShared，release 对应 releaseShared——它是共享模式的典型应用。

• 构造 new Semaphore(n) 把 state 初始化为 n（公平版 FairSync，非公平版 NonfairSync）。
• acquire()：调用 acquireShared(1) → tryAcquireShared。非公平版在 nonfairTryAcquireShared 里用 CAS 自旋尝试 state -= permits，结果 <0 返回负数表示失败；公平版先 hasQueuedPredecessors() 判断不能插队。失败则进入同步队列等待。
• release()：调用 releaseShared(1) → tryReleaseShared 用 CAS 把 state 加上 permits，成功后 doReleaseShared 唤醒等待者（共享模式下的唤醒传播）。
• 因此许可的「加减」就是 state 的原子增减，tryAcquireShared 的返回值（剩余许可）决定了是否能继续唤醒后继。

private void doAcquireSharedInterruptibly(int arg) throws InterruptedException {
    final Node node = addWaiter(Node.SHARED);
    try {
        for (;;) {
            final Node p = node.predecessor();
            if (p == head) {
                int r = tryAcquireShared(arg);          // 返回剩余许可
                if (r >= 0) {                           // >=0 表示获取成功
                    setHeadAndPropagate(node, r);       // 触发共享唤醒传播
                    p.next = null;
                    return;
                }
            }
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                throw new InterruptedException();
        }
    } catch (Throwable t) { cancelAcquire(node); throw t; }
}

典型限流用法： 用 Semaphore(n) 限制同时访问某资源的线程数，acquire 前用 tryAcquire() 或 tryAcquire(timeout) 做非阻塞/限时获取，finally 中 release()。

Semaphore permits = new Semaphore(10);      // 最多 10 个并发
if (permits.tryAcquire(200, TimeUnit.MILLISECONDS)) {
    try { handle(); }                        // 拿到许可才执行
    finally { permits.release(); }           // 必须归还
}

延伸： Semaphore 与 CountDownLatch 都用共享模式，但语义相反——前者 state 增加表示可用许可变多（release），后者 state 减到 0 表示触发。

结论：与 ReentrantLock 不同，Semaphore.release() 不检查当前线程是否 acquire 过许可，任何线程都能 release，甚至 release 次数多于 acquire，导致许可数超过初始值，限流形同虚设。

• 源码层面 tryReleaseShared 只做 state CAS += permits，没有 isHeldExclusively 之类的持有者校验——因为它本质是「信号量」而非「锁」，允许跨线程释放（一个线程生产许可、另一个线程消费许可）。
• 好处：灵活性高，可用于「先发信号后消费」「任务完成后由别的线程归还」等模式。
• 坏处（坑）：业务代码若在异常路径重复 release、或没判断 tryAcquire 是否成功就 release，许可会无限膨胀；此后 acquire 永不会阻塞，限流完全失效，且难以自查。

// 危险：没拿到许可也 release，或被 catch 重复 release
try {
    permits.acquire();
    doWork();               // doWork 抛异常
} finally {
    permits.release();      // 看似正确：finally 保证配对
}
// 但若写成：
permits.acquire();
boolean ok = permits.tryAcquire(0, SECONDS);
doWork();
finally {
    if (ok) permits.release(); // 误判 ok 语义 → 多释放
}

正确做法： acquire 与 release 必须严格配对，且 release 只在确实获取成功时调用；用 tryAcquire 的结果（boolean）决定是否 release，或统一在 if (acquired) try { ... } finally { release(); } 里处理。

延伸： 面试常问「Semaphore 能否当锁用」——可以（初始许可 1），但要自己保证配对，因为它没有可重入性，也没有持有者校验。

结论：Phaser 是可重用的多阶段屏障，支持动态增减参与方；CountDownLatch 是一次性倒计数；CyclicBarrier 可循环但参与方固定。三者解决的问题逐层递进。

• CountDownLatch：适合「一个线程等待多个前置任务完成」（如启动时等待依赖就绪），用完即废。
• CyclicBarrier：适合「一批线程互相等待，到齐后一起进入下一轮」，参与方数量固定，await 返回到达顺序。
• Phaser：把上述能力泛化为「阶段」，每阶段的参与方集合可变化，还能分层扩展以支撑大规模线程。

为什么需要 Phaser： 现实中「阶段数不确定、参与方数量会变」的场景（如分阶段的数据处理流水线、可伸缩的任务编排）用前两者要写很多胶水代码，Phaser 用 phase 模型天然表达，且分层实现避免了单点 CAS 热点。

延伸： CyclicBarrier 的循环靠 generation 换代实现，broker 失败会让当前代次 Generation.broken = true，其他等待线程抛 BrokenBarrierException；Phaser 用 onAdvance 返回 true 来终止。

结论：Phaser 用 phase（从 0 递增）表示「当前是第几阶段」，用 arrive/arriveAndAwaitAdvance 标记到达，等所有注册方都到达后 phase 自增，进入下一阶段；参与方可通过 register/arriveAndDeregister 动态增减。

• state 里打包了 phase、unarrived（未到达数）、parties（总注册数），用 CAS 原子更新。
• 常用 API：
  • register()：增加一个参与方（parties+1）。
  • arrive()：到达但不等待，返回 phase 号；用于纯计数场景。
  • arriveAndAwaitAdvance()：到达并等待所有方到齐，进入下一 phase 后返回新 phase。
  • arriveAndDeregister()：到达并注销自己，后续阶段不再参与。
  • onAdvance(phase, registeredParties)：可重写，返回 true 表示终止 Phaser（默认在 parties==0 时终止）。

Phaser phaser = new Phaser(3);              // 3 个参与方
for (int i = 0; i < 3; i++) {
    new Thread(() -> {
        doStage1();
        phaser.arriveAndAwaitAdvance();     // 等第 0 阶段全部到达
        doStage2();
        phaser.arriveAndDeregister();       // 完成并退出，不再参与
    }).start();
}

为什么能动态： 因为 parties/unarrived 都存在 state 里用 CAS 维护，加减参与方只需原子更新这几个计数，无需重建对象。而 CyclicBarrier 的参与方在构造时写死，无法变更。

灵活点： arrive() 与 arriveAndAwaitAdvance() 分离，让「只登记完成、不阻塞」成为可能；arriveAndDeregister() 让某个参与方「干完就走」，剩余方继续，适合任务数量不均衡的流水线。

延伸： 大规模场景下 Phaser 会把参与方分层（tiered）组织成树状，减少对单个 state 的 CAS 竞争，这是它相比单点 CyclicBarrier 的可扩展性优势。

结论：FutureTask 用 volatile int state 表示状态，取值在 NEW → COMPLETING → NORMAL/EXCEPTIONAL，以及取消路径 NEW → CANCELLED 或 NEW → INTERRUPTING → INTERRUPTED。状态只允许单向流转。

private static final int NEW          = 0;
private static final int COMPLETING   = 1;   // 结果已算出，正在写 outcome
private static final int NORMAL       = 2;   // 正常结束
private static final int EXCEPTIONAL  = 3;   // 抛出异常结束
private static final int CANCELLED    = 4;   // cancel(false) 后
private static final int INTERRUPTING = 5;   // interrupt 前
private static final int INTERRUPTED  = 6;   // interrupt 后

• 正常完成：run() 中 set(result) 先把 state CAS 成 COMPLETING 并写 outcome，再置 NORMAL，最后 finishCompletion() 唤醒所有等待线程。
• 异常完成：setException(ex) 同样经 COMPLETING 写入 outcome，再置 EXCEPTIONAL。
• 取消：cancel(true) 把 state CAS 成 INTERRUPTING，执行 t.interrupt()，再置 INTERRUPTED；cancel(false) 直接置 CANCELLED。
• 为什么要有 COMPLETING/INTERRUPTING 中间态：先置终态就会让 get() 读到还没写完的 outcome。先进入中间态、写完数据再置终态，保证「看到 NORMAL 就一定能看到完整结果」，这是状态机与可见性配合的经典手法。

延伸： state 是 volatile，中间态配合 outcome 的写顺序，让 get() 用「先读 state 再读 outcome」的方式安全拿到结果。

结论：get() 通过 awaitDone 把当前线程做成等待节点挂到 waiters 栈上并 park，任务完成后由 finishCompletion 逐个 unpark；FutureTask 同时实现了 Runnable 和 Future，所以既能被线程执行，又能当结果凭据。

• get() → awaitDone(false, 0)：
  • 自旋检查 state：已完成则 report() 返回结果（NORMAL 直接返回，EXCEPTIONAL 包装成 ExecutionException，CANCELLED 抛 CancellationException）。
  • 未完成则构造 WaitNode 用 CAS 压入 waiters 链表（一个基于 CAS 的栈）。
  • 用 LockSupport.park(this) 挂起，被唤醒后重新检查状态。
  • 若等待期间线程被中断，awaitDone 会 removeWaiter 后抛 InterruptedException，不吞掉中断。
• finishCompletion()：任务到达终态后，把 waiters 全部弹出并 unpark，同时置 runner = null。
• 支持超时的 get(timeout, unit) 走 awaitDone(true, nanos)，内部用 LockSupport.parkNanos 并在超时后抛 TimeoutException。

public V get() throws InterruptedException, ExecutionException {
    int s = state;
    if (s <= COMPLETING)              // 未完成
        s = awaitDone(false, 0L);     // 挂起等待
    return report(s);                 // 按状态返回结果或抛异常
}

为什么能被线程池执行： FutureTask implements RunnableFuture<V> extends Runnable, Future<V>。submit(task) 内部把 Runnable/Callable 包装成 FutureTask，因为它是 Runnable 就能被 execute 调度；因为它是 Future，submit 才能返回它给用户拿结果。这是一个典型的适配器/双身份设计。

Future 的局限与 CompletableFuture： Future 只能阻塞 get() 或轮询 isDone()，无法回调、无法编排、无法组合多个任务、异常处理弱。CompletableFuture 实现 Future 与 CompletionStage，用函数式 API（thenApply/thenCompose/thenCombine/allOf/anyOf）做回调编排，内部用无锁的 Completion 栈（Treiber stack）维护依赖，是 Future 的增强替代。

结论：ScheduledThreadPoolExecutor 的队列是 DelayedWorkQueue，内部是基于数组的二叉最小堆（按到期时间排序），队首 queue[0] 就是最早要执行的任务，take() 返回最近到期的任务并在必要时阻塞等待。

• 堆元素是 RunnableScheduledFuture，比较依据是 getDelay(unit) 与 compareTo（先比 time，再比 sequence 保证 FIFO 稳定）。
• 入队 offer 把任务放到数组末尾后上浮（siftUp）；出队 take/poll 取走 queue[0]，把末尾元素放到根再下沉（siftDown），维持堆序。
• 因为堆不是完全有序，只保证根最小，所以 offer/take 的复杂度是 O(log n)，比链表轮询 O(n) 高效。
• 队列的 size 用一个重入锁 ReentrantLock + 条件 available 保护（数组和堆指针需要互斥），take 在无到期任务时 available.await 挂起，新任务入队后 signal。
• 首元素用 RunnableScheduledFuture[] 数组，扩容按 1.5 倍增长。

为什么用最小堆而不是链表/优先队列： DelayQueue 用 PriorityQueue（也是堆）但每次 take 要轮询过期节点；DelayedWorkQueue 直接以堆根为最近到期任务，配合条件变量精确唤醒，效率更高，且专门为定时任务场景优化（支持 leader/follower 式的等待）。

延伸： DelayedWorkQueue 的 take() 会在等待时释放锁再 park，醒来重新检查，避免长时间持锁阻塞其他提交者。

结论：scheduleAtFixedRate 以固定频率调度，下次执行时间 = 上次开始时间 + period；scheduleWithFixedDelay 以固定间隔调度，下次执行时间 = 上次结束时间 + delay。前者会「追赶」，后者不会。

• scheduleAtFixedRate：周期 = period，从任务启动时刻起算。如果单次执行耗时超过 period，下一次会立即开始、连续补跑（catch-up），不会因为超时而拉长整体周期，但会造成短时间内密集执行。
• scheduleWithFixedDelay：间隔 = delay，从任务完成时刻起算。无论单次执行多久，执行结束后都至少等 delay 再跑下一次，负载更平滑，不会追赶。
• 选择：周期性采样、固定节拍任务用 fixedRate；需要给任务留缓冲、避免拥塞的任务用 fixedDelay。

为什么 fixedRate 不推迟： 它承诺的是「每个周期至少执行一次」的频率语义，把超时视为需要补偿的偏差。若任务持续超时（执行时间 > period），实际上会退化为「一结束就立刻下一次」，等价于串行追赶，可能压垮系统——所以 fixedRate 更适合任务耗时远小于 period 的场景。

延伸： 两者返回的都是 ScheduledFuture，可通过 cancel(false) 取消后续调度；取消后已开始的那次执行不会被打断（除非 cancel(true) 且任务响应中断）。

结论：周期任务若抛出未捕获异常，该任务会被直接取消，之后不再执行任何周期，且异常默认不会打印出来。ScheduledThreadPoolExecutor 的构造器不提供队列参数，因为它强依赖 DelayedWorkQueue 的延迟语义。

• 抛异常后，ScheduledFutureTask.run 内部包装的 call 会抛 ExecutionException，异常沿 run 冒泡到 Worker，FutureTask 状态变成 EXCEPTIONAL，任务被标记完成——后续周期不再触发。因为线程池用 wrapper 兜住了异常，默认连堆栈都不打印，极易被忽略。
• 正确处理：在任务体内 try/catch 兜底，或 afterExecute 里 ((FutureTask) r).get() 捕获并记录；ScheduledExecutorService 也提供 setRemoveOnCancelPolicy 等其他配置，但异常取消是默认语义。
• 不支持自定义队列的原因：ScheduledThreadPoolExecutor 的周期重排（reExecutePeriodic）依赖队列的 Delayed 能力——任务自己算出下次 time 再重新入队。传入普通 BlockingQueue（如 LinkedBlockingQueue）就没有 getDelay 语义，延迟调度与周期重排全部失效。因此构造器只暴露 corePoolSize、ThreadFactory、拒绝策略，队列被写死为 DelayedWorkQueue。

ScheduledExecutorService pool = Executors.newScheduledThreadPool(2);
pool.scheduleAtFixedRate(() -> {
    try {
        doTask();                       // 必须自行兜底
    } catch (Throwable t) {
        log.error("periodic task failed", t);   // 否则任务被静默取消
    }
}, 0, 1, TimeUnit.SECONDS);

延伸： 因为 maximumPoolSize 被设为 Integer.MAX_VALUE、队列无界，所以 ScheduledThreadPoolExecutor 基本不会触发拒绝策略；要关心的是「任务堆积」而非「拒绝」。

结论：ForkJoinPool 给每个工作线程分配一个双端队列（WorkQueue），线程从自己队列的 top 端取任务（LIFO，利于局部性）；空闲线程从其他队列的 base 端「窃取」任务（FIFO，减少竞争），从而实现负载均衡。

• 每个 WorkQueue 用数组 + base、top 两个指针实现轻量双端队列：push/pop 操作 top（自己用），poll/窃取操作 base（别人用）。
• 线程执行 fork() 会把自己的子任务压入自己队列的 top；join() 时优先处理自己队列里的任务（LIFO），任务是「最近 fork 的」局部性最好。
• 空闲线程通过 scan 随机挑选一个受害者队列，从 base 端取任务执行——这就是「窃取」。窃取用 CAS 更新 base，尽量减少与队主的冲突（队主只动 top，窃取者只动 base，冲突概率低）。
• 全局用 ctl（一个 long）做位运算管理并行度、活跃线程数、队列状态，避免中央锁。

为什么这么设计： 若所有线程共享一个队列，取任务就是 CAS 热点；每线程一个队列 + 两端操作（自己走 top、别人走 base），把竞争降到最低。LIFO 让线程优先处理最新产生的子任务，缓存命中率更高；窃取端用 FIFO 则倾向于先执行「更早、更大」的任务，避免细碎任务被反复窃取。

延伸： ForkJoinPool.commonPool() 是 JDK 8+ 的公共池（并行度默认 CPU 核数 - 1），parallelStream 就运行在它上面；要谨慎往 commonPool 里放阻塞任务，会拖慢全局并行度。

结论：RecursiveTask<V> 有返回值、RecursiveAction 无返回值、CountedCompleter 用回调完成计数，三者的选择依据是「是否需要结果」和「是否适合用回调聚合」。

• RecursiveAction：无返回值的递归任务，重写 compute()，常配合 invokeAll(left, right) 拆分执行，适合并行遍历、批量处理。
• RecursiveTask<V>：有返回值的递归任务，重写 compute() 返回 V，适合求和、查找、统计等需要汇总结果的场景。
• CountedCompleter：不靠 join 汇合，而是通过 onCompletion(CountedCompleter) 回调、用「未完成计数」触发父任务，适合「任务数动态、需要提前终止或聚合」的场景（如并行搜索一旦命中就整体收敛），能减少 join 的等待与开销。

// RecursiveTask 示例：数组求和
class SumTask extends RecursiveTask<Long> {
    private final int[] a; private final int lo, hi;
    SumTask(int[] a, int lo, int hi) { this.a = a; this.lo = lo; this.hi = hi; }
    protected Long compute() {
        if (hi - lo <= 1000) {                 // 阈值内直接算
            long s = 0; for (int i = lo; i < hi; i++) s += a[i]; return s;
        }
        int mid = (lo + hi) >>> 1;
        SumTask l = new SumTask(a, lo, mid), r = new SumTask(a, mid, hi);
        l.fork();                              // 一个 fork，一个直接算
        return r.compute() + l.join();         // 再 join 汇总
    }
}

为什么拆到阈值就停： 每次 fork 都有入队和调度的开销，若任务太细，开销超过并行收益反而变慢。设置一个合理的阈值（如 1000 个元素）让叶子任务串行执行，是分治性能的关键调优点。

延伸： invokeAll(a, b) 会 fork 两个子任务然后 join；手动 fork 一个、compute 另一个（如上面的写法）能少一次入队，是常见优化。

结论：ForkJoin 的优势建立在「任务不阻塞、可拆分、CPU 密集」之上；IO 密集任务会阻塞工作线程，让工作窃取失去意义，应改用普通线程池或异步 IO。

• 适合分治：任务可递归二分、叶子可串行、无阻塞，工作窃取能让每个核心都忙起来；典型如归并排序、并行归并、数组统计、树遍历。
• 不适合 IO 密集：工作线程一旦 socket.read() 阻塞，就无法执行队列里的其他任务；而工作窃取的前提是「线程有空就偷任务」，被 IO 卡住的线程偷不了也跑不了，池子并行度被无效占用。若确实要用，可通过 ForkJoinPool.ManagedBlocker 告诉框架「我要阻塞了」，让它临时补偿一个线程，但本质仍是权宜之计。
• 与普通线程池对比：
  • ThreadPoolExecutor：一个共享队列，任务不拆分，线程阻塞不影响其他任务（只要线程数足够），适合 IO 密集、任务粒度大。
  • ForkJoinPool：每线程一个队列 + 可拆分 + 窃取，适合 CPU 密集、细粒度递归。

延伸： parallelStream 默认跑在 ForkJoinPool.commonPool()，里面若有阻塞 IO 会拖慢整个 commonPool（影响其他用到它的代码），所以不要在 parallelStream 里做阻塞操作。

结论：CPU 缓存以 cache line（通常 64 字节）为一致性单位。若两个互不相关的变量落在同一条 cache line 上，一个核心修改它就会让其他核心的整条缓存行失效，导致本无共享的变量产生「伪」竞争——这就是伪共享。

Cache Line (64 bytes)
┌──────────────────────────────┬──────────────────────────────┐
│  变量 a（线程 A 频繁写）       │  变量 b（线程 B 频繁写）       │
└──────────────────────────────┴──────────────────────────────┘
A 写 a → 该 cache line 在 B 的核心里被置为 Invalid
B 写 b → 又重新拉取整条 line → 来回失效 → 性能骤降（伪共享）

• 解决思路：让高频写的变量独占一条 cache line。
  • 手动填充：在变量前后加 7 个 long（或等量字节）做 padding，把相邻变量隔开 64 字节。
  • 注解方式：@sun.misc.Contended（JDK 8+），编译/运行时会自动填充；用户代码使用需加 -XX:-RestrictContended 才生效（JDK 内部类如 LongAdder.Cell、ConcurrentHashMap.CounterCell、Striped64 已内置使用）。
• JDK 中的实际应用：LongAdder/Striped64 的 Cell、Thread 的部分字段、ForkJoinPool 的 WorkQueue、Exchanger 等都用 @Contended 避免伪共享。

// 手动填充示意
final class PaddedLong {
    volatile long value;
    long p1, p2, p3, p4, p5, p6, p7;   // 填充，使 value 独占 cache line
}
// 注解方式（需 -XX:-RestrictContended）
@sun.misc.Contended
static final class Cell {
    volatile long value;
}

为什么在并发里重要： 伪共享不会造成逻辑错误，但会让多线程性能断崖式下降（可能比单线程还慢）。LongAdder 之所以比 AtomicLong 快，一半靠分散热点 Cell，另一半就是靠 @Contended 让每个 Cell 独占缓存行。

延伸： 检查伪共享可用 perf c2c 或 JOL（Java Object Layout）查看对象内存布局；注意 @Contended 会增大内存占用，只在真正的高频写热点上使用。

结论：Disruptor 用定长环形数组（RingBuffer）+ 序号（sequence）+ 无锁 CAS + 内存屏障替代锁和条件变量，并通过缓存行填充与批量处理获得远高于 BlockingQueue 的吞吐。

• 环形数组：容量为 2 的幂，用位运算取下标 index = sequence & (capacity - 1) 代替取模，速度快；事件对象预分配，生产消费不产生 GC（对比 ArrayBlockingQueue 每次入队出队可能涉及对象创建/拷贝）。
• 序号驱动：生产者先 CAS 申请序号、写入数据、再用 lazySet/volatile 发布；消费者用序号判断「是否有新数据可读」。序号本身承担了「锁」的职责。
• 无锁：不像 BlockingQueue 用 ReentrantLock + Condition 做阻塞唤醒（涉及线程挂起/唤醒的系统调用开销），Disruptor 用 CAS 自旋 + 内存屏障，避免了上下文切换。
• 缓存友好：序列号用填充（Sequence 继承 LhsPadding/RhsPadding）避免伪共享；消费者批量消费，减少循环和屏障次数。
• 支持模式：多生产者用 CAS，单生产者更简单；消费者组通过 SequenceBarrier 做依赖编排（如流水线式 handler）。

为什么比 BlockingQueue 快： 锁 + 条件变量的阻塞/唤醒成本高，且队列出队会移动元素造成缓存不友好；Disruptor 的无锁序号 + 预分配 + 位运算 + 填充，把同步开销、GC 开销、缓存失效都压到最低，在低延迟高吞吐场景（如金融撮合）比 ArrayBlockingQueue 快数倍。

延伸： 代价是队列容量固定、实现复杂、不适合长耗时消费（会阻塞环）。Disruptor 适合「快进快出、高吞吐」的事件流，不适合任务耗时差异大的通用线程池场景。

结论：JMM 定义了四种内存屏障——LoadLoad、StoreStore、LoadStore、StoreLoad；它们插入在指令间，禁止特定类型的重排序。volatile 读写和 CAS 正是通过不同组合的屏障来实现可见性与有序性。

• volatile 写：前面插 StoreStore（保证之前的普通写先落盘），后面插 StoreLoad（保证写对后续读可见，且不让它被重排到后面）。
• volatile 读：后面插 LoadLoad（后续读不提前到 volatile 读之前）和 LoadStore。
• CAS / 原子类：底层是 CPU 的 lock cmpxchg，lock 前缀等价于一个全屏障（同时具备四种屏障效果），因此 CAS 既能保证原子性又能保证可见性与有序性。
• 在 x86 上，StoreLoad 是唯一需要显式指令（mfence 或 lock addl）的屏障，其他三种 x86 天然有序，所以 JIT 在 x86 上通常只在 volatile 写后面发一条带 lock 前缀的指令。

为什么需要 StoreLoad： 它是唯一无法被其他三种替代的屏障（写缓冲/Store Buffer 会导致后续读先于前面的写完成），开销最大但也是最关键的。JMM 把「volatile 写 + 后续 volatile 读」作为建立 happens-before 的核心，靠的就是它。

延伸： 理解了屏障就能理解「为什么 volatile 不能保证原子性」——它只解决可见性与有序性，i++ 的「读-改-写」仍需 CAS 或锁保护。

结论：优先级反转指低优先级线程持有高优先级线程需要的锁，导致高优先级线程被动等待，自己也被中优先级线程抢占，最终「高优先级最长等待」的反常现象。解决办法是优先级继承或优先级天花板。

• 典型链路：低优先级线程 L 持有锁 → 高优先级线程 H 请求同一锁被阻塞 → 中优先级线程 M 抢占 CPU（因为 M 优先级高于 L）使 L 迟迟不能释放锁 → H 实际上在等 M 跑完，优先级被「反转」。
• 经典案例：1997 年 NASA 火星探路者号因该问题反复重启，最终通过开启 VxWorks 的优先级继承解决。
• 优先级继承：当 H 因等待 L 持有的锁而阻塞时，临时把 L 的优先级提升到 H 的级别，让它尽快执行完并释放锁；释放后恢复 L 原优先级。
• 优先级天花板：给锁设定一个「天花板优先级」（等于所有可能持有该锁的线程中的最高优先级），任何线程一旦持有该锁就被提升到天花板，从源头上避免反转。

Java 中的情况： Java 的线程优先级（Thread.setPriority）只是建议，由 JVM 映射到 OS 优先级，且各平台行为不一致（Linux 上通常不起作用），所以 Java 里很少直接说优先级反转，但概念仍应掌握。真正的解决办法是缩短临界区、避免长耗时操作持锁、减少锁竞争。

延伸： 实时操作系统（RTOS）中优先级反转是必须处理的问题；Java 应用里更常见的等价问题是「长事务/慢 IO 持有锁导致其他线程排队」，本质相同。

结论：虚拟线程若在 synchronized 块或方法内阻塞，会被「固定（pin）」在载体线程（carrier thread）上，无法被卸载，从而占住一个宝贵的平台线程——这就是 pinning。JDK 21 的阶段是「存在该限制 + 提供诊断」，真正移除限制在后续版本（JEP 491）落地。

• 虚拟线程运行在少量载体线程上，遇到阻塞（如 IO、park）时会卸载，把载体线程让给其他虚拟线程，这是它高并发的核心。但 synchronized 的监视器是 JVM 层面的 ObjectMonitor，进入时绑定在载体线程上，阻塞时无法卸载，载体线程被「钉住」。
• 后果：大量虚拟线程若都卡在 synchronized 里，会把载体线程占满，其他虚拟线程无法调度，吞吐退化为平台线程。
• JDK 21 的做法：保留该限制，官方明确建议用 ReentrantLock 替代 synchronized（ReentrantLock 基于 AQS + LockSupport.park，park 支持虚拟线程卸载），并提供诊断开关 -Djdk.tracePinnedThreads=full（或 short）打印发生 pinning 的堆栈。
• 后续版本改进：JDK 24 的 JEP 491（Synchronize Virtual Threads without Pinning） 让虚拟线程在 synchronized 中阻塞时也能卸载，从根本上移除了这一限制。

// 有 pinning 风险
synchronized (lock) {
    blockingIo();          // 阻塞时载体线程被钉住，无法调度其他虚拟线程
}
// 推荐：改用 ReentrantLock
reentrantLock.lock();
try {
    blockingIo();          // park 可卸载虚拟线程，载体线程得以复用
} finally {
    reentrantLock.unlock();
}

为什么这么设计（历史包袱）： synchronized 的监视器实现早于虚拟线程，其「锁绑定线程」的语义与虚拟线程「可挂起、可卸载」的模型天然冲突。彻底改造遗留的同步原语代价高，因此先给诊断与替代方案，再在后续版本通过 JEP 491 完成底层消除。

延伸： 除 synchronized 外，调用 native 方法、Object.wait 也会导致 pinning；用虚拟线程时应统一优先 ReentrantLock，并监控 pinning 事件。

结论：虚拟线程数量可达百万级，每个虚拟线程一份 ThreadLocalMap 会成倍放大内存占用；而虚拟线程的价值在「阻塞时卸载载体线程」，CPU 密集任务没有阻塞点，用它只会徒增调度开销。

ThreadLocal 要谨慎的原因：

• 每个虚拟线程仍是独立的 Thread 对象，拥有自己的 ThreadLocalMap。平台线程几十上百个时 ThreadLocal 开销可忽略；虚拟线程数量可能到百万级，若每个都持有一份较重的 ThreadLocal 值（如缓存对象、连接、SimpleDateFormat），内存会爆炸。
• 传统的「一线程一份缓存（ThreadLocal 缓存）」思路在虚拟线程下收益低：虚拟线程生命周期短、创建销毁频繁，反复初始化/清理 ThreadLocal 反而浪费。
• 替代方案：Scoped Values（JEP 429 → JDK 21 预览、JDK 25 正式）——不可变、按作用域绑定的隐式参数，专为大量虚拟线程设计，读取零拷贝、自动清理，比 ThreadLocal 更轻。
• 若确需 ThreadLocal，务必在 finally 中 remove()，避免虚拟线程复用时残留（虚拟线程通常不复用，但仍有泄漏风险）。

虚拟线程不适合 CPU 密集的原因：

• 虚拟线程的模型是「少量载体线程 + 大量可挂起的虚拟线程」。CPU 密集任务几乎不阻塞，无法触发卸载/挂起，绝大多数时间都在占用载体线程执行计算。
• 此时调度器要不停地在虚拟线程间做挂载/卸载/上下文切换，而计算本身没有并行度提升（并行度上限仍是 CPU 核数），反而增加了调度开销。
• 正确选择：CPU 密集用平台线程线程池（并行度 ≈ CPU 核数）或 ForkJoinPool；虚拟线程用于高并发、高阻塞的 IO 场景（如海量 HTTP 请求、JDBC 阻塞调用）。

延伸： 虚拟线程不由 ThreadPoolExecutor 池化（不建议用线程池包虚拟线程），因为创建成本极低，池化反而限制并发；但下游资源（数据库连接、文件句柄）仍是有限的，需要用 Semaphore 做准入控制。

结论：先用 top -Hp 找高 CPU 线程、用 jstack <pid> 抓线程快照，jstack 会自动报告监视器死锁；对非死锁的阻塞（BLOCKED/WAITING）看堆栈中的 waiting to lock / parked；复现靠缩小资源规模、拉长临界区、高并发压测。

jstack 定位步骤：

1. jps -l 或 ps -ef | grep java 拿到 pid。
2. jstack <pid> > stack.txt（或 jcmd <pid> Thread.print）抓快照。
3. 死锁：jstack 末尾会直接输出 Found one Java-level deadlock:，列出互相持有的锁地址与线程，以及 Found 1 deadlock.。
4. BLOCKED（等 monitor 锁）：线程堆栈会显示 - waiting to lock <0x...> (a java.lang.Object) 与 - locked <0x...>，把两个地址对上就能找到持有者。
5. WAITING/TIMED_WAITING：常见 parking to wait for <0x...>（AQS/LockSupport）、waiting on <0x...>（Object.wait）、sleeping；ReentrantLock 死锁不一定出现在 "Java-level deadlock" 段，但 jstack 会标 parking to wait for 的 ownable synchronizer 地址，可据此找持有者。
6. 高 CPU：top -Hp <pid> 找 %CPU 高的线程 tid → printf '%x\n' <tid> 转十六进制 → 在 jstack 里搜 nid=0x<hex> 对应线程。
7. 若一次看不出，间隔几秒连抓 3~5 次快照对比（jstack 多次采样），看线程是否卡在同一位置。

并发问题的复现与压测思路：

• 缩小规模放大问题：把线程池/连接池调小、把超时调短、把队列调小，让竞争与饱和更快出现。
• 拉长临界区：在可疑临界区插入 Thread.sleep（仅测试环境）或人为放慢，让竞态窗口变大。
• 提高并发：用 JMeter、Gatling、wrk、ab 压测，或自写多线程循环反复执行可疑逻辑（跑几十万次）。
• 可观测：用 Arthas watch/trace/stack 观察调用与耗时，用 async-profiler 抓火焰图定位锁热点，用 TLA/混沌注入（延迟、丢包）制造异常时序。
• 加固：复现后写出最小用例（unit test + CountDownLatch 控时序），才能稳定回归验证修复。

延伸： 真正的并发 bug 往往「偶现」，压测目标不是「必现」而是「提高概率」；能写出稳定的最小复现用例，才算真正定位到根因。

结论：线程池要盯 池大小 / 活跃数 / 队列长度 / 完成数 / 拒绝数 / 任务等待与执行耗时；ThreadPoolExecutor 支持运行时 setCorePoolSize 等动态调参，但核心线程数的修改有回收与创建时机上的限制，不是立即见效。

核心监控指标：

• getPoolSize() 当前线程数、getActiveCount() 活跃（正在执行任务）线程数、getLargestPoolSize() 历史峰值。
• getQueue().size() 队列积压长度——最关键的饱和信号。
• getCompletedTaskCount() 已完成任务数、getTaskCount() 累计提交数。
• 拒绝次数（RejectedExecutionHandler 里自增埋点）、任务从入队到开始执行的等待时间 QPS/RT、任务执行耗时。
• 采集方式：继承 ThreadPoolExecutor，重写 beforeExecute/afterExecute/terminated 打点；或定时从 getter 采样，暴露到 Micrometer / Prometheus，配合告警（队列长度与活跃数持续接近上限即饱和）。
• 附加：getTaskCount - getCompletedTaskCount 反映在途任务；队列使用率 = queue.size() / queue.capacity。

动态调参的时机限制（重点）：

• setCorePoolSize(n)：
  • 若 n > 当前 corePoolSize：会创建新的核心线程（但只有在有待执行任务时才会真正启动执行）。
  • 若 n < 当前 corePoolSize：多余的空闲核心线程会在下一次获取任务时被回收（通过 allowCoreThreadTimeOut / getTask 的循环判断），但不会中断正在执行的任务——所以生效有延迟，不是立刻缩容。
  • 约束：corePoolSize 不得大于 maximumPoolSize，否则抛 IllegalArgumentException。
• setMaximumPoolSize(n)：若 n < 当前池大小，多余的线程会在空闲时被回收；不能小于 corePoolSize。
• setKeepAliveTime：调整非核心（或开启 allowCoreThreadTimeOut 后的所有）线程空闲存活时间。
• 重要提醒：参数变化不会重排已入队的任务，也不会改变队列中任务的执行顺序；动态调参解决的是「容量」而不是「积压优先级」。

ThreadPoolExecutor pool = new ThreadPoolExecutor(8, 32, 60, TimeUnit.SECONDS,
        new ArrayBlockingQueue<>(1000), new NamedThreadFactory("order"));
// 运行时按队列水位动态调整
int queued = pool.getQueue().size();
if (queued > 800) pool.setCorePoolSize(16);      // 扩容，生效于新任务
else if (queued < 100) pool.setCorePoolSize(8);  // 缩容，空闲线程延后回收
System.out.println(pool.getPoolSize() + "/" + pool.getActiveCount() + "/" + queued);

为什么扩容不能救已积压的任务： 队列是 FIFO，参数调整只改变「未来新任务」由多少线程处理、空闲线程何时回收；已经排队的老任务仍按原顺序被现有线程消费，除非把队列换成有优先级的结构（如 PriorityBlockingQueue）或在业务层做优先级调度。

延伸： 生产上更稳的做法是「按队列水位驱动」而非拍脑袋定时调参；同时要给 maximumPoolSize 与队列容量设上限，避免无界队列掩盖问题（LinkedBlockingQueue 默认无界，是常见事故根源）。

结论：五大部分——堆、方法区（共享）；程序计数器、虚拟机栈、本地方法栈（线程私有）。此外还有堆外的直接内存。

┌──────────────── JVM 运行时数据区 ────────────────┐
│  线程私有                   线程共享              │
│  ┌──────────────┐          ┌────────────────┐   │
│  │ 程序计数器 PC │          │      堆 Heap     │   │
│  ├──────────────┤          │  (对象实例)      │   │
│  │ 虚拟机栈      │          ├────────────────┤   │
│  │ (Java 栈帧)   │          │  方法区 Method   │   │
│  ├──────────────┤          │  (类元信息/常量) │   │
│  │ 本地方法栈    │          └────────────────┘   │
│  └──────────────┘                               │
└─────────────────────────────────────────────────┘
        ↑ 堆外：直接内存 Direct Memory (NIO)

• 程序计数器：当前线程执行的字节码行号，唯一不会 OOM 的区域。
• 虚拟机栈：每个方法调用对应一个栈帧，存局部变量表、操作数栈等；栈深度超限抛 StackOverflowError。
• 本地方法栈：为 native 方法服务。
• 堆：对象实例的主要分配地，GC 的主战场，是最大的一块。
• 方法区：存类元信息、运行时常量池、静态变量等；JDK 8 起由元空间（本地内存）实现。
• 直接内存：NIO 的 DirectByteBuffer 使用，不归堆管但会受 -XX:MaxDirectMemorySize 限制。

延伸： 追问「为什么 PC 不会 OOM」：它只存一个行号偏移量，所需空间在编译期就确定，不随运行增长。

结论：堆分新生代（Eden + 两个 Survivor）与老年代，默认 Eden:S0:S1 = 8:1:1，对象优先在 Eden 分配，经多轮 Minor GC 存活后晋升老年代。

• 新生代：Eden 放新对象，两个 Survivor（From/To）用于复制存活对象；每次 Minor GC 把 Eden + From 的存活对象复制到 To，年龄加 1。
• 对象分配流程：优先在 TLAB/Eden 分配 → Minor GC 后存活进 Survivor → 年龄达到阈值（默认 15，由 -XX:MaxTenuringThreshold 控制）或动态年龄判定达标 → 晋升老年代。
• 大对象直接进老年代（-XX:PretenureSizeThreshold），避免在新生代反复复制。
• Survivor 中「相同年龄对象总和超过一半」也会触发动态晋升，不必等满 15 岁。

延伸： 为什么用两个 Survivor？用复制算法需要一个空的空间接收存活对象，S0/S1 轮换保证总有一块是空的；8:1:1 是为了让 Eden 尽量大、减少浪费。

结论：每个方法调用生成一个栈帧，包含局部变量表、操作数栈、动态链接、方法返回地址（以及可能的附加信息），入栈出栈随方法调用/返回。

• 局部变量表：以「槽（Slot）」为单位存方法参数与局部变量，long/double 占两个 Slot；实例方法的第 0 个槽是 this。
• 操作数栈：字节码指令的运行时工作区，如 iadd 从栈顶弹出两个操作数、压回结果。
• 动态链接：指向运行时常量池中该方法的符号引用，用于把符号引用解析为直接引用（支持多态）。
• 方法返回地址：正常返回存调用处的 PC，异常返回由异常表决定。
• 虚拟机栈大小由 -Xss 指定；递归过深导致栈帧不断入栈，超过栈容量抛 StackOverflowError。

延伸： 追问「局部变量表为什么可以复用槽」：离开作用域后槽可被后续变量覆盖，这也是「栈帧的局部变量不一定是 null，可能持有已失效对象引用」的原因之一。

结论：创建过程是「类加载检查 → 分配内存 → 内存置零 → 设置对象头 → 执行构造方法」；内存布局是「对象头 + 实例数据 + 对齐填充」。

对象创建：

1. 类加载检查：检查常量池中该类是否已加载、解析、初始化，没有则先执行类加载。
2. 分配内存：用指针碰撞（内存规整时）或空闲列表（内存不规整时），并发下配合 TLAB 或 CAS。
3. 内存置零：把分配到的内存清零，保证实例字段有零值可用。
4. 设置对象头：写入 Mark Word（哈希、GC 年龄、锁标志等）与类型指针（指向类元数据）。
5. 执行 <init>：按代码执行构造方法（这时才真正赋上程序里的初始值）。

对象内存布局：

延伸： 「内存置零」这一步解释了为什么字段即使没在构造里赋值也有默认值，以及为什么分配阶段可以先于构造执行——这正是 DCL 需要 volatile 的根源。

结论：指针碰撞与空闲列表是两种内存分配方式，取决于堆是否规整；TLAB 是给每个线程在 Eden 里预分一小块私有空间，避免分配时的并发冲突。

• 指针碰撞：内存规整（有连续空闲区），用指针指向「下一个可用地址」，分配即把指针后移对象大小，快；Serial、ParNew 等有压缩的收集器用这种方式。
• 空闲列表：内存不规整（存在碎片），用一张表记录可用空闲块，分配时找一块合适的；CMS 用这种方式。
• TLAB（Thread Local Allocation Buffer）：Eden 中属于线程私有的小块，线程在自己的 TLAB 里分配无需同步；TLAB 用完才需要 CAS 申请新的 Eden 空间。
• 是否启用 TLAB 及大小由 -XX:+UseTLAB、-XX:TLABSize 等控制，默认开启。

延伸： 追问「分配为什么快」：有 TLAB 时是「指针加法」级别的操作，几乎零同步开销，这也是 Java 对象创建本身开销不高的原因。

结论：方法区是规范里的概念，永久代是 JDK 8 之前 HotSpot 对它的实现（在堆内、受 -XX:MaxPermSize 限制），JDK 8 起改为元空间（Metaspace，使用本地内存）。

• 为什么取消永久代：永久代大小在启动时基本固定，动态生成大量类（CGLIB、JSP、OSGi）时极易撑爆；GC 时又难以与老年代统一管理。
• 元空间用本地内存，随类加载动态增长，减少了「调永久代大小」的负担；同时把类的元数据存到堆外，堆内更专注放对象。

延伸： 追问「字符串常量池在哪」：JDK 7 起字符串常量池从永久代移到堆；JDK 8 的静态变量也随之存到堆，方法区里只留类元信息。

结论：主流 JVM 用「可达性分析」而非引用计数；从一组 GC Roots 出发遍历引用链，不可达的对象即被判定为可回收。

• 引用计数：给对象加计数器，引用 +1、失效 -1，为 0 即死。简单但无法解决对象间的循环引用，Java 不采用。
• 可达性分析：以 GC Roots 为起点向下遍历，形成引用链，链外的对象判定为不可达。
• 可达对象即使不可达也有「缓刑」：若重写了 finalize 且未被调用过，会被放入 F-Queue 再判定一次（现代实践中基本不再依赖 finalize）。

GC Roots 主要有：

• 虚拟机栈中栈帧的局部变量表所引用的对象（正在执行方法的参数、局部变量）。
• 方法区中类的静态属性引用的对象。
• 方法区中常量引用的对象（如字符串常量池里的引用）。
• 本地方法栈中 JNI（native 方法）引用的对象。
• 活跃线程、系统类加载器、同步锁 monitor 持有的对象、JVM 内部引用等。

延伸： 追问「为什么不用引用计数」：循环引用场景下计数器永不归零，需要额外的环检测，复杂度不划算。

结论：按强度从强到弱是强、软、弱、虚，强度决定对象在 GC 时的「存活优先级」，用于实现缓存、避免泄漏与资源清理。

• 软引用适合「有更好、没有也能重建」的缓存；一旦内存紧张先牺牲它。
• 弱引用的对象只要发生 GC 就会被清除，适合「对象还活着就复用、死了自动清理」的映射，如 WeakHashMap。
• 虚引用是唯一无法通过 get() 拿到对象的引用，必须配合 ReferenceQueue 使用，用于在对象被回收前后做资源释放。

延伸： 追问「ThreadLocal 为什么用弱引用」：让 ThreadLocal 对象本身可被回收，避免它长期存活；但 value 仍需手动 remove，否则照样泄漏。

结论：标记-清除、标记-复制、标记-整理，三者都在「标记存活对象」之后用不同方式处理，分别在碎片、空间利用率、移动成本上各有取舍。

• 没有一种算法通吃，所以 JVM 用「分代收集」组合使用：新生代对象大多朝生夕死，用复制算法最划算；老年代对象存活率高，用整理或清除更合适。

延伸： 追问「为什么新生代能浪费一半空间」：实际用 Eden + 两块 Survivor（8:1:1），真正浪费的是其中一个 Survivor 的 1/10，代价可接受。

结论：分代收集基于「弱分代假说」（绝大多数对象朝生夕死）把堆分区，对不同区用不同算法；Minor GC 由 Eden 满触发，Full GC 原因较多、开销最大。

• Minor GC / Young GC：Eden 空间不足时触发，回收新生代，通常很快。
• Major GC / Old GC：只回收老年代（现在多与 Full GC 混用）。
• Full GC：回收整个堆（及元空间），停顿最长，应尽量避免频繁发生。

Full GC 常见触发原因：

• 老年代空间不足（大对象、对象过早晋升、老年存活过多）。
• 元空间 / 方法区不足（动态生成类过多）。
• 显式调用 System.gc()（默认触发 Full GC，可用 -XX:+DisableExplicitGC 屏蔽）。
• CMS 的「并发模式失败 / 晋升失败」——并发回收还没结束，老年代已被填满，退化为串行 Full GC。
• 空间分配担保失败：Minor GC 前老年代剩余空间不足以担保新生代晋升。

延伸： 排查 Full GC 频繁，先看日志里是哪种原因，再对症：泄漏就 dump 分析、晋升过快就调 Survivor/年龄阈值、元空间问题就查动态类生成。

结论：从串行到并行、从「整体 STW」到「分区并发」，收集器演进的主线是不断降低停顿时间并提升吞吐，选择取决于「要低延迟还是高吞吐」。

• 吞吐量 = 用户代码运行时间 / 总时间；停顿时间 = 单次 GC 卡住的时长，二者通常互相制约。
• 现代默认是 G1；追求极低停顿（<10ms）的大堆服务选 ZGC。

延伸： 追问「CMS 为什么被废弃」：并发标记清除有浮动垃圾与碎片，且并发模式失败会退化成串行 Full GC，整体被 G1 取代。

结论：调优的第一手依据是 GC 日志；常用参数大致分「堆/栈大小」「GC 选择」「日志与 OOM dump」三类，JDK 9 起 GC 日志参数做了统一重构。

延伸： 生产建议常备 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/dump，OOM 现场比事后复现珍贵得多。

结论：OOM 不止「堆满」一种，还有元空间、直接内存、GC 开销超限、无法创建线程等；内存泄漏是「该回收的没回收」，内存溢出是「真的装不下」，泄漏长期累积会导致溢出。

常见 OOM 类型：

内存泄漏 vs 内存溢出：

• 内存泄漏：对象已不再使用，但因被引用而无法回收，占用只增不减；是「原因」。
• 内存溢出：申请内存时确实没有足够空间可用；是「结果」，泄漏是它最常见的诱因之一。

延伸： GC overhead limit 本质是「GC 在垂死挣扎」，可通过 -XX:-UseGCOverheadLimit 关闭这个提前抛出，但治本还是找出泄漏对象。

结论：类加载分「加载 → 验证 → 准备 → 解析 → 初始化」五步；初始化由「主动引用」触发，且严格遵循「父类先于子类」；被动引用不会触发初始化。

• 加载：通过类全限定名读入字节码，生成 Class 对象。
• 验证：校验字节码合法性（文件格式、元数据、字节码、符号引用等）。
• 准备：为静态变量分配内存并赋零值（static int a = 1 此时 a=0）。
• 解析：把常量池里的符号引用替换为直接引用（可延迟到首次使用时）。
• 初始化：执行 <clinit>，把静态变量赋上代码中的真实值，并执行静态代码块。

主动引用（会触发初始化）：

• new 对象、访问类的静态字段（非 final 常量）或静态方法。
• 反射调用（Class.forName）。
• 初始化子类时先初始化其父类。
• 虚拟机启动时先初始化包含 main 方法的主类。

被动引用（不触发）：

• 通过子类访问父类的静态字段，只初始化父类。
• 通过数组定义引用类（new A[10] 只加载 A，不初始化）。
• 引用编译期常量（static final 基本类型）会被内联到调用处，不初始化该类。

延伸： <clinit> 是线程安全的（JVM 保证只有一个线程执行），这也是「静态内部类单例」天生线程安全的原理。

结论：Java 源码编译成平台无关的字节码（.class），由 JVM 解释执行；对热点代码用 JIT 编译成本地机器码，实现「解释执行 + 编译执行」共存；JIT 会做逃逸分析等激进优化。

字节码结构（.class 文件）：

• 魔数 0xCAFEBABE、版本号、常量池、访问标志、字段表、方法表、属性表。
• 方法体是指令序列，如 aload_0、invokevirtual、ireturn。

JIT 与热点探测：

• 解释执行启动快、但慢；编译执行（C1/C2）慢启动、但跑得快，两者共存以兼顾。
• 热点探测用计数器：方法调用计数器 + 回边计数器，超过阈值触发编译；C1 编译快、优化浅（客户端），C2 优化深、编译慢（服务端）。

JIT 主要优化手段：

• 逃逸分析：判断对象是否逃出方法/线程作用域。
• 栈上分配 + 标量替换：对象未逃逸时，把字段拆成局部变量直接在栈上分配，减少堆压力与 GC。
• 锁消除：对不可能被其他线程访问到的同步代码去掉锁。
• 方法内联：把小方法直接展开到调用处，减少调用开销，为后续优化创造条件。

延伸： 追问「为什么有些代码越跑越快」：运行中被 JIT 编译优化；而 -Xint 关闭 JIT、-Xcomp 全编译，性能表现完全不同。

结论：类加载请求先交给父加载器，父加载器无法完成才自己加载；它保证核心类不被篡改、类不重复加载。破坏场景主要有 SPI、Tomcat 与热部署/OSGi。

• 层次：Bootstrap（C++ 实现，加载 rt.jar 等核心类）→ Extension/Platform → Application（加载 classpath）→ 自定义。
• 流程：App 收到加载请求先委派给父，逐级向上，都不行才由自己加载。
• 好处：① 安全——用户无法用自定义的 java.lang.String 覆盖核心类（父加载器先加载）；② 唯一——同一个类由同一个加载器加载才「相等」，避免重复。

三个破坏场景：

• SPI（如 JDBC）：核心接口在 Bootstrap 层（rt.jar），但驱动实现在 classpath，父加载器看不到子类的类。于是用「线程上下文类加载器（TCCL）」反向委派给子加载器加载。
• Tomcat：每个 Web 应用一个 WebAppClassLoader，要求「先加载自己目录下的类，再向上委派」，实现应用间的类隔离与同名类不同版本共存。
• 热部署 / OSGi：模块化环境下类需要动态替换，加载器被设计成网状而非严格父子，实现「同一类可被不同加载器加载成不同版本」。

延伸： 判断两个类是否「相同」要同时看「全限定名 + 加载它的类加载器」，这是很多「同名类却 ClassCastException」问题的根源。

结论：指针压缩把 64 位的对象引用压缩成 32 位表示，减少内存占用与缓存压力；HotSpot 默认开启，且在堆不超过约 32GB 时最有效。

• 64 位 JVM 中引用原本占 8 字节，压缩后占 4 字节，对象头、实例数据中的指针都能省一半空间。
• 原理：HotSpot 要求 8 字节对齐，于是「32 位值 = 真实地址 / 8 的偏移」，可表示 2^32 × 8 = 32GB 的寻址范围。
• 因此堆超过约 32GB 时压缩指针失效，需要退化为 64 位指针，反而可能比「堆稍小于 32G」更费内存——这是「堆不要盲目设到 32G 以上」说法的来源。
• 相关参数：-XX:+UseCompressedOops（普通对象指针）、-XX:+UseCompressedClassPointers（类型指针）；两者在较新 JDK 默认开启。

延伸： 追问「为什么堆设 40G 反而更差」：超出压缩寻址范围，指针膨胀回 8 字节，有效内存利用率大跌，可能不如把堆控制在 32G 以内。

结论：CMS（Concurrent Mark Sweep）以「最短停顿」为目标，分初始标记、并发标记、重新标记、并发清除四个阶段；三大问题是浮动垃圾、空间碎片、并发模式失败。

• 初始标记（STW）：只标记 GC Roots 直接关联的对象，很快。
• 并发标记：从这些对象出发做可达性分析，与用户线程并发执行，耗时最长但不 STW。
• 重新标记（STW）：修正并发标记期间因用户线程运行而变动的记录（用增量更新），停顿比初始标记长但远比并发标记短。
• 并发清除：并发回收垃圾对象，不移动，因此会产生碎片。

三大问题：

1. 浮动垃圾：并发清除时用户线程又产生了新垃圾，只能留到下次回收，所以不能等老年代满了才启动 CMS。
2. 空间碎片：标记-清除不整理，长期运行后有空闲空间却放不下大对象，触发 Full GC。
3. 并发模式失败 / 晋升失败：CMS 还没回收完，老年代就不够用了（或担保失败），只能退化为 Serial Old 做一次串行 Full GC，停顿很长。

延伸： 应对：用 -XX:CMSInitiatingOccupancyFraction 提前触发、-XX:+UseCMSCompactAtFullCollection 在 Full GC 时整理、-XX:CMSFullGCsBeforeCompaction 控制整理频率。

结论：G1 把堆划分为大量等大 Region，用「可预测停顿模型」优先回收回收价值高的区域（Garbage First），兼顾吞吐与可控停顿，JDK 9 起成为默认收集器。

• Region：堆被分成约 2048 个大小相等的 Region（1~32MB），逻辑上仍有 Eden/Survivor/Old 的划分；超过 Region 一半的大对象放 Humongous 区。
• 跨代引用：用 Remembered Set + Card Table 记录「谁引用了我」，避免全堆扫描。
• SATB（Snapshot-At-The-Beginning）：并发标记时以「开始那一刻的快照」为准，用写前屏障记录被删除的引用，保证不漏标（对应原始快照思想）。
• 回收模式分 Young GC、Mixed GC（同时回收新生代和部分老年代 Region）、Full GC（退化情况）。
• 停顿预测模型：用户设定目标停顿 -XX:MaxGCPauseMillis，G1 根据历史数据估算本次能回收多少个 Region，优先回收「垃圾占比高、回收收益大」的 Region。

延伸： G1 适合大堆、对停顿有要求的服务端；若追求更极致的低延迟（亚毫秒级）且堆更大，应选 ZGC。

结论：ZGC 靠「染色指针 + 读屏障」把标记、转移、重定位几乎全部并发化，停顿时间与堆大小基本无关，可控制在极低水平（较新版本已达亚毫秒级）。

• 染色指针（Colored Pointers）：把对象的标记状态（如 Marked0、Marked1、Remapped）直接存在 64 位指针的若干高位里，而不是放在对象头，这样看指针就能知道对象标记状态。
• 读屏障（Load Barrier）：在读取对象引用时插入一小段逻辑，若指针状态需要修正（对象已移动或标记位过期），就当场修正，从而让「移动对象」不再需要长时间的 STW。
• 并发处理：并发标记、并发转移、并发重映射，绝大多数工作与用户线程并发，不需要像 G1 那样在移动阶段长时间停顿。
• 代价：读屏障给每次引用读取都增加了一点开销，吞吐可能略低于 G1；但对延迟敏感的超大堆场景收益远大于代价。

延伸： 区分「低延迟」与「高吞吐」：ZGC 换的是停顿，适合在线服务；纯批处理更看重总吞吐，G1/Parallel 可能更划算。

结论：三色标记把对象分为白（未访问）、灰（已访问、引用未扫完）、黑（已访问且引用扫完）；并发标记期间用户线程改引用会导致漏标，用增量更新（CMS）或原始快照（G1）解决。

• 白色：尚未被 GC 访问到，最终仍是白色即被判为垃圾。
• 灰色：自己被访问了，但它引用的对象还没扫描完，是「待处理队列」里的对象。
• 黑色：自己及所有引用都已扫描完，安全存活。

漏标发生需要同时满足两个条件：① 黑色对象新增了一条指向白色对象的引用；② 原来指向该白色对象的灰色对象（直接或间接）断开了引用。此时白色对象既不在灰队列里、黑色对象也不会再被扫描，于是被误判为垃圾回收掉——即「对象消失」问题，后果严重。

两种解法：

• 增量更新（Incremental Update）：记录「黑色对象新增的引用」，重新标记阶段以这些黑色对象为根重新扫描（CMS 用它）。
• 原始快照（SATB）：记录「被删除的引用」，认为快照开始时的对象图不变，新对象一律当作存活（G1 用它，配合写前屏障）。

延伸： 记忆口诀：增量更新盯「新增」（黑→白），原始快照盯「删除」（灰→白）；前者可能多扫，后者可能多留浮动垃圾。

结论：自定义类加载器主要解决「非标准来源加载类、类的隔离、以及加密/热部署」三类需求，核心是继承 ClassLoader 并重写 findClass（或 loadClass）。

常见用途：

• 从非 classpath 来源加载：网络、数据库、加密文件中的字节码，加载前先解密。
• 类隔离：中间件/容器让同名但不同版本的类各自加载、互不冲突（Tomcat、Dubbo 均如此）。
• 热部署/热替换：丢弃旧类加载器、用新加载器重新加载类，实现不重启更新代码。
• 字节码增强：结合 ASM/Javassist 在加载时改字节码，实现埋点、监控、AOP 等能力。

延伸： 重写时注意：想保持双亲委派就重写 findClass；想打破父优先委派（如 Tomcat 先加载自身类）则重写 loadClass，这也是「破坏双亲委派」的落地方式。

结论：OOM 排查主线是「先留现场（dump）、再看趋势（jstat/jcmd）、最后用 MAT/Arthas 定位大对象与引用链」。

排查流程：

1. 快速止血：先摘流量/重启/扩容，别让线上继续恶化，同时保留一份现场。
2. 拿快照：jmap -dump:format=b,file=heap.hprof <pid>（或提前配好 -XX:+HeapDumpOnOutOfMemoryError 自动导出）。
3. 看 GC 趋势：jstat -gcutil <pid> 1000，观察 O/YGC/FGC 次数、老年代占用是否持续升高不降。
4. 定位对象：用 MAT 打开 hprof，看 Dominator Tree 找占用最大的对象，用「Path to GC Roots」排除弱引用后确认是谁在持有。
5. 对照代码：根据大对象类型/数量反查业务逻辑，常见是集合无限增长、缓存未设上限、监听器未注销、ThreadLocal 未 remove。
6. 验证：修复后压测复现，确认老年代可回收、Full GC 不再频繁。

常用工具对比：

延伸： 线上生产 dump 会 STW 且文件很大，优先用 jcmd/jmap 的 live 选项并避开高峰；能提前自动 dump 就别等事发后手动补。

结论：标准套路是「top 找进程 → top -Hp 找线程 → 线程号转 16 进制 → jstack 里搜这个 nid 找到对应代码」。

top -Hp <pid>                 # 1. 找到占用 CPU 最高的线程，记下 TID
printf '%x\n' <TID>           # 2. 把十进制线程号转成 16 进制（jstack 里叫 nid）
jstack <pid> | grep -A 30 'nid=0x<hex>'   # 3. 定位该线程的调用栈

常见根因与处置：

• 死循环/无界自旋：代码里的 while 无出口或 CAS 长时间自旋，看栈顶是不是业务方法。
• 频繁 Full GC：用 jstat -gcutil <pid> 1000 看 GC 次数，若 FGC 猛增且老年代降不下来，转 OOM 排查，dump 分析。
• 锁竞争/大量线程阻塞：jstack 里找 BLOCKED 与锁持有者，或 Arthas thread -b 直接找阻塞源头。
• 正则回溯/大计算：栈里能看到具体的算法方法，属于代码优化问题。

延伸： 线上优先用 Arthas 的 thread -n 3（列出最忙的 3 个线程栈）和 profiler（火焰图），省去手工换算 nid 的步骤。

结论：调优目标是「在满足延迟要求的前提下，尽量少 Full GC、少停顿」；思路是「先看日志定问题，再改少量参数，再压测验证」，切忌无脑堆参数。

调优思路：

1. 明确目标：是降停顿、提吞吐，还是解决 OOM/频繁 Full GC，目标不同参数取向不同。
2. 建立基线：先开着 GC 日志收集现状（GC 频率、单次停顿、晋升速率、内存曲线）。
3. 小步调整：一次只改少数参数，改完压测对比，避免多个变量同时动。
4. 常见手段：堆大小固定（Xms=Xmx）、控制新生代比例、换收集器（G1/ZGC）、调停顿目标、重视对象生命周期（少造大对象/长命对象）。

4C8G 服务端一套参考参数（G1）：

java -jar app.jar \
  -Xms4g -Xmx4g \                       # 堆固定，避免动态伸缩抖动
  -XX:MetaspaceSize=256m \
  -XX:MaxMetaspaceSize=512m \           # 限制元空间，防动态类过多
  -XX:+UseG1GC \                        # 低停顿通用收集器
  -XX:MaxGCPauseMillis=200 \            # 期望最大停顿，G1 自动调 Region 回收量
  -XX:InitiatingHeapOccupancyPercent=45 \   # 老年代占用达 45% 触发并发标记
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/data/dump \         # OOM 自动留现场
  -Xlog:gc*:file=/data/log/gc.log:time:filecount=5,filesize=50M  # GC 日志轮转

说明：堆 4g（物理 8g 留一半给系统/直接内存）；G1 适合这种规模并兼顾延迟；MaxGCPauseMillis 是抓手而非硬保证；吞吐优先可换 Parallel 系列并配合 -XX:GCTimeRatio。

延伸： 参数不是越多越好，很多「调优」其实是在掩盖代码问题（大对象、缓存无上限、ThreadLocal 泄漏）；先修代码，再谈参数。

结论：JDK 9 起统一为 -Xlog，替代旧的 -XX:+PrintGC*；生产推荐 -Xlog:gc*:file=gc.log:time,uptime,level,tags:filecount=5,filesize=50M。

• 四段式语法：-Xlog:<tag>:<output>:<decorator>:<rotation>。
• 常用 tag：gc、gc+heap、gc+age、gc+phases、gc+ergo、safepoint。
• output：stdout / stderr / file=路径；decorator：time,uptime,level,tags,pid,tid。
• rotation：filecount、filesize、fileages，防止日志写满磁盘。
• 旧参数 -XX:+PrintGCDetails -Xloggc: 已废弃，混用会收到 "Option ... was deprecated" 告警。

延伸：为什么合并成统一日志？旧体系 tag 分散、格式不统一、无法按级别过滤；-Xlog 可按 tag 组合与级别精确输出，还支持运行时用 jcmd 调整。

结论：以 G1 的一次 Young GC 为例逐段拆解——时间、级别、标签、GC 编号、原因、回收前后堆、停顿时间。

[2024-05-01T10:00:00.123+0800][info][gc,phases] GC(12) Pause Young (Normal) (G1 Evacuation Pause) 1234M->345M(4096M) 25.678ms

• [time][level][tag]：时间戳、日志级别、gc,phases 子标签（说明这行属于 GC 阶段耗时）。
• GC(12)：本次 GC 全局编号；同一次 GC 的多行日志编号相同，可把 Pause Young、Pause Remark、Pause Cleanup 串成一个完整周期。
• Pause Young (Normal) (G1 Evacuation Pause)：Pause Young 表示年轻代停顿，Normal 表示普通 Young GC，括号里是触发原因（Evacuation Pause = 复制存活对象）。
• 1234M->345M(4096M)：回收前堆占用 → 回收后堆占用（总堆容量）。
• 25.678ms：本次停顿时长（应用线程被暂停的时间）。
• 老年代变化要另看 gc+heap 标签行：Eden: 1024M(1024M)->0B(1024M) Survivor: ... Old: 400M(2048M)->300M(2048M)。

延伸：Pause Full (G1 Compaction Pause) 才是 Full GC；看到它就说明 G1 退化，要查并发标记是否跟不上分配。

结论：看老年代「回收后残留水位」是否持续抬升——抬升=泄漏；老年代稳定但 Young GC 频繁且单次耗短=年轻代偏小。

• 内存泄漏：每次 Full GC 后老年代占用一次比一次高（Old: 行回收后仍接近满），最终 GC overhead limit exceeded 或 Full GC 越来越频繁；堆转储里可见某类对象只增不减。
• 年轻代偏小：日志里 Young GC 很频繁（每秒数次）、单次回收效果好（回收后占用大幅下降）、老年代基本不动、单次停顿很短。只需调大新生代（G1 可调 -XX:G1NewSizePercent / -XX:G1MaxNewSizePercent）。
• 分配速率过高：即使不泄漏，allocation rate 太大也会让年轻代撑不住；先看业务是否有大对象、临时大集合。

延伸：别只看停顿时间，要看「回收后占用」这条曲线，它才是泄漏的硬证据。

结论：jcmd 是 JDK 自带的「多功能诊断瑞士军刀」，jcmd <pid> help 列出所有可用命令，无需额外工具。

• Thread.print：等价 jstack，打印线程栈，定位死锁/阻塞。
• GC.heap_dump /path/x.hprof：导出堆转储（会 STW）。
• GC.heap_info、GC.class_histogram：堆使用与对象直方图。
• VM.flags / VM.system_properties：查看启动生效参数与系统属性，排查「参数没生效」。
• VM.native_memory summary：堆外内存（需开 -XX:NativeMemoryTracking）。
• VM.metaspace：类元数据占用。
• JFR.start duration=60s filename=a.jfr：运行时开启飞行记录。
• VM.log：调整 GC 日志输出。

延伸：容器内 pid 为 1 或命名空间隔离时，jcmd 需在容器内执行，或用 jcmd -l 确认目标进程；相比分散的 jmap/jstack，jcmd 是统一入口。

结论：Region 大小由 -XX:G1HeapRegionSize 指定，默认取「堆的 1/2048」并向上对齐到 2 的幂、范围 1~32MB；大于等于一个 Region 一半的对象称为 Humongous，单独占用连续的 Region。

• 巨型对象阈值 ≈ Region 大小的 50%。例如 Region=4M，则 ≥2M 的对象即为 Humongous。
• 危害：Humongous Region 一次可能占多个连续 Region，直接进老年代，推高老年代占用、提前触发并发标记，并易产生碎片，回收代价高。
• 常见来源：大数组、大字符串、序列化 buffer、byte[] 缓存。
• 优化：避免过大单对象；必要时调大 Region（如 -XX:G1HeapRegionSize=16m）把大对象降级为普通对象；但 Region 越大、单次回收粒度越粗。
• 对象分配路径：优先 TLAB/Eden → 存活进 Survivor → 达年龄阈值或动态年龄判定晋升老年代，Humongous 则绕过新生代直接进老年代。

延伸：日志里出现 Humongous 或 gc+heap 中的大块回收，就该排查大对象来源；它不等于内存泄漏，但会拖累 GC 表现。

结论：默认 200ms，是 G1 的期望停顿目标而非硬保证；它决定 G1 每次挑多少 Region 回收。

• 值越小：每次回收的 Region 更少 → 单次停顿短；但回收追不上分配，GC 更频繁、吞吐下降，严重时「回收速率 < 分配速率」而退化 Full GC。
• 值越大：单次回收更多 Region，吞吐好，但停顿变长。
• 现实取值：在线服务常用 100~200ms，先测量再调，配合观察 Young/Mixed GC 频率与停顿分布。
• 坑：显式设 -Xmn 或 -XX:NewRatio 会锁死新生代大小，让 G1 无法按停顿目标自适应，二者别同时设。
• -XX:G1NewSizePercent / -XX:G1MaxNewSizePercent 限制新生代比例范围，范围太小会让 G1 无法把暂停压进目标。

延伸：面试常问「为什么调小停顿反而更慢」——G1 靠「每次少回一点、多做几次」换低停顿，分配速率不变时总工作量上升。

结论：先由「整堆占用达到 -XX:InitiatingHeapOccupancyPercent（默认 45%）」触发并发标记，标记完成后若存在可回收的老年代 Region，才进行 Mixed GC，同时回收年轻代 + 部分老年代。

• 参与混合回收的老年代 Region 需满足：存活率低于 -XX:G1MixedGCLiveThresholdPercent（默认 85%）、整堆垃圾占比达 -XX:G1HeapWastePercent，并受 -XX:G1MixedGCCountTarget 控制分几轮做完。
• 若并发标记期间分配太快、老年代被填满，会触发 concurrent mode failure / to-space exhausted，退化为 Full GC。

延伸：IHOP 调低会让并发标记更早启动、降低退化风险，但更费 CPU；老年代增长快的服务可适当调低。

结论：G1 参数围绕「停顿目标、并发标记时机、Region 粒度、新生代范围」四类；退化成 Full GC 的本质是「回收速度赶不上分配速度」。

退化为 Full GC 的典型场景：

• 并发标记还没完成，老年代就被填满（分配太快或 IHOP 太高）。
• 晋升失败（promotion failed）、to-space exhausted（survivor / 老年代无空间）。
• Humongous 对象过多导致连续性 Region 不够。
• 大对象直接分配失败。

延伸：G1 的 Full GC 是「兜底」的整堆回收，停顿可达秒级；出现即应结合日志调 IHOP、增大 Region 或扩容，而不是视而不见。

结论：它们把「标记、转移、重定位」全部做成与应用线程并发执行，靠「指针自描述 + 读屏障」在访问时修正引用，只留下极短的初始/最终标记停顿。

• ZGC 染色指针：64 位引用中借用若干高位存「颜色」（Marked0/Marked1/Remapped 等视图）。GC 通过切换内存视图，让「同一地址在不同阶段有不同的标记含义」，从而并发标记与并发重定位。
• 读屏障（Load Barrier）：应用线程每次读引用都检查指针颜色，发现是旧颜色就「自愈」——要么标记为存活，要么转发到对象新地址。动作很短，不 STW。
• Shenandoah：用 Brooks Pointer（对象头前的转发指针）实现并发压缩，转移时先写转发指针，读到时跳转。
• 共同代价：读屏障 / CAS 有额外开销，吞吐略低于 G1，且需要更多虚拟地址空间。

延伸：为什么停顿与堆大小无关？因为并发阶段不再「一次性扫描 + 压缩」，只留固定规模的初始/最终标记（通常 <1ms）。

结论：ZGC 用「并发 + 染色指针」换来亚毫秒停顿，代价是额外内存与吞吐；分代 ZGC 通过引入年轻代/老年代进一步降低每次并发标记的开销、提升吞吐。

• 内存开销：染色指针的多视图映射需要额外虚拟地址空间（较新版本约为堆的 2~3 倍虚拟内存，物理内存占用更小），多视图页表也有开销；堆越小收益越不明显，通常建议较大堆（≥ 数十 GB）才划算。
• 吞吐：读屏障使吞吐略低于 G1；若追求极限吞吐而非低延迟，G1 反而更合适。
• 适用：对 P99/P999 停顿极敏感的在线服务、大堆场景；不适合小堆或纯批处理。
• 分代 ZGC：早期 ZGC 每次并发标记都是整堆扫描，堆大时 CPU 消耗高；引入分代后大部分回收只针对年轻代，显著降低标记成本、提升吞吐，较新版本的 -XX:+ZGenerational（或默认行为）已启用。
• 启用：-XX:+UseZGC，较新 JDK 已转正，不再需要单独的解锁实验开关。

延伸：选型口诀——要吞吐选 G1/Parallel，要低延迟大堆选 ZGC，要低延迟且堆不特别大也可看 Shenandoah。

结论：-XX:+UseContainerSupport 让 JVM 读取 cgroup 的内存/CPU 限制来设定默认堆与线程数；-XX:MaxRAMPercentage 则按容器内存上限的百分比推导堆上限，二者常配合用。

• 历史坑：JDK 8u191 之前 JVM 读不到 cgroup 限制，容器 limit=2G 时仍按宿主机内存算 MaxHeapSize，实际 RSS 超过 limit 后被内核 OOM Killer 杀掉。
• 现在：主流 JDK 默认开启容器感知（UseContainerSupport），按 cgroup 上限设堆。
• MaxRAMPercentage：默认约 25%，即堆上限 = 容器内存 × 25%。生产常调到 60~75，把余量留给上面那些堆外部分。
• 结论：容器里优先用 -XX:MaxRAMPercentage=70 这类相对参数，而非写死 -Xmx，让同一镜像适配不同规格。

延伸：若容器 limit ≠ request，CPU 被限流会导致 GC / 编译线程表现抖动，最好让 request=limit，或显式 -XX:ActiveProcessorCount。

结论：容器里的「OOM」有两种——JVM 自己抛 OutOfMemoryError（堆内）和被内核 OOM Killer 杀进程（多为堆外超限）；CPU 核数则决定 JVM 默认的 GC/JIT 线程数。

• 两种 OOM 区分：
  • JVM OOM：进程有 Java 异常栈，退出码一般非 137。
  • 被 cgroup kill：容器 exit code 137（128+9），常见于堆外（Metaspace、直接内存、线程栈、本地库）或 JVM 认知的 limit 不对。
• CPU 核数：JVM 通过 cgroup / sched_getaffinity 探测可用 CPU，据此决定 ParallelGCThreads、ConcGCThreads（G1/ZGC 并发线程）、ForkJoinPool 并行度、JIT 编译线程数。
• 陷阱：宿主核数很多、容器 limit 很小 → 线程数过多 → 上下文切换与内存开销变大；或被 CPU 限流后 GC 并发线程跑不满。
• 对策：-XX:ActiveProcessorCount=N 显式指定核数；容器设 limits.cpu。

延伸：排查时先看容器 exit code 与 kubectl describe pod 的 Last State: OOMKilled，再看 JVM 日志，别一上来就加堆。

结论：先确认是堆外问题（RSS 涨、堆使用稳定），再用 NMT 分区域记账、pmap 看内存段，定位到具体子系统。

• 开启 NMT：-XX:NativeMemoryTracking=summary（排查期可用 detail，有 5%~10% 性能开销，别长期开）。
• 对比基线：jcmd <pid> VM.native_memory summary.diff，看哪一类（Thread / Class / Code / GC / Internal / Other / Mapped）在涨。
• 系统视角：pmap -x <pid>、cat /proc/<pid>/smaps 看匿名内存与映射；top -Hp <pid> 看线程数与各线程栈。
• 常见根因：
  • DirectByteBuffer / MappedByteBuffer 未释放，或 NIO/Netty 池化 buffer 只借不还。
  • 线程泄漏（线程栈累积，Thread 类记账上涨）。
  • JNI / 本地库自管内存。
  • Metaspace 持续增长（类加载器泄漏）。
• 直接内存 OOM：java.lang.OutOfMemoryError: Direct buffer memory，受 -XX:MaxDirectMemorySize 限制，默认约等于最大堆。

延伸：NMT 是「分类记账」，pmap 是「物理视角」，两者互补；先看 diff 定位类别，再用 pmap 验证。

结论：Metaspace 存类元数据，泄漏的本质是「类加载器无法被回收」，其加载的类就一直占着 Metaspace。

• 动态代理：CGLIB / JDK Proxy / MyBatis Mapper 若在运行期反复生成新代理类，并绑定不同类加载器，就会不断产生新类。
• 反射与字节码生成：defineClass、字节码库（ASM/ByteBuddy）反复生成同名新类。
• 脚本引擎：Groovy / Nashorn 等每次编译脚本都可能生成新的类加载器。
• 热部署 / OSGi / 插件框架：卸载时类加载器被强引用（静态字段、ThreadLocal、缓存）导致无法释放。
• 框架缓存：某些反射工具、序列化/Bean 映射框架会缓存类对象，配合自定义类加载器时容易泄漏。
• 排查：jcmd <pid> VM.metaspace 看 usage 与 class loader 数；用 JFR 的 Class Loading 事件；heap dump 里看 ClassLoader 的引用链（排除弱引用）。

延伸：Metaspace 不像堆有固有限制（可用 -XX:MaxMetaspaceSize 兜底），不设上限时可能一路涨到撑爆容器内存。

结论：Arthas 的价值是「不重启、不重新打包，线上直接看」。不同命令解决不同问题。

• dashboard：总览面板，看线程、内存、GC、最忙线程，排查第一步。
• thread -n 3：找出最耗 CPU 的 3 个线程及其栈；thread -b 直接找死锁。
• trace ClassA methodB：追踪方法内部调用链与各环节耗时，定位「慢在哪一段」。
• watch ClassA methodB '{params, returnObj, throwExp}' -x 3：观测真实入参与返回，验证「参数到底对不对」。
• jad ClassA：反编译线上类，确认「跑的是不是我以为的那份代码」。
• ognl：执行 OGNL 表达式查看静态字段 / 调用方法；vmtool：查内存里的对象实例、触发 GC。
• 典型选择：CPU 高 → thread -n；接口慢 → trace；数据不对 → watch / jad。

延伸：Arthas 也会增强字节码、有开销，线上用完记得 stop / shutdown 退出。

结论：JFR（JDK Flight Recorder）是内建的低开销（约 1%）事件记录器，JDK 11 起开源免费，可在生产长期开启。

• 开启：-XX:StartFlightRecording=filename=app.jfr,duration=60s,settings=profile；运行时 jcmd <pid> JFR.start duration=60s filename=a.jfr，JFR.dump 导出。
• 关键事件：GC（含各阶段耗时）、Safepoint（区分到安全点耗时与停顿内耗时）、ThreadPark / JavaMonitorBlocked（锁竞争）、ObjectAllocationSample（分配热点）、ClassLoad、SocketRead/Write。
• 分析：JMC 图形化看自动分析页与统计图；命令行 jfr print --events jdk.GCPhasePause app.jfr。
• 价值：一次录制同时回答「GC 停顿多少、锁竞争在哪、内存分配热点是谁」。

延伸：相比 jstack / 采样 profiler，JFR 是「全维度、低开销」，线上疑难问题优先录一段 JFR。

结论：JVM 崩溃会生成 hs_err_pid<pid>.log，按「信号 → 出错帧 → 线程栈 → 环境」顺序读，重点看头部几行与 Problematic frame。

• 头部：# A fatal error has been detected by the Java Runtime Environment: + SIGSEGV / SIGBUS（段错误 / 总线错误），以及是否生成了 core dump。
• Problematic frame：出错的当前帧。C [libxxx.so+0x...] 指向本地库（JNI 问题），J ... 指向 JIT 编译方法，V [jvm... ] 则怀疑 JVM 自身。
• Current thread 与其 Java 栈：确认是哪个业务线程、调用到哪。
• Native frames / siginfo / Registers：C++ 栈与寄存器信息，配合 native 符号排查 JNI。
• 尾部 VM Arguments、Dynamic libraries、Memory:：确认启动参数、加载的本地库版本、内存映射。
• 常见成因：JNI 越界访问、本地库版本不匹配、栈溢出、JVM/GC bug（拿 SIGSEGV 的位置去查 JDK bug 库）。

延伸：若 Problematic frame 指向自己的 native 库，先查该库；若指向 V 开头且反复出现，升级/切换 JDK 小版本常能解决。

结论：前者是「代码还没编译成机器码」，后者是「编译结果没地方放」，都会让服务退化到解释执行，但成因与解法不同。

• JIT 未预热：服务刚启动时方法大量以解释模式或 C1 编译运行，吞吐低、延迟高；随热点方法被 C2 编译（分层编译）性能才爬升到稳定值。表现为「发布后前几分钟接口 P99 明显偏高」。
  • 缓解：预热流量 / 回放、合理设置 -XX:CompileThreshold、用 CDS/AppCDS 与 AOT 加速启动与预编译。
• CodeCache 满：JIT 编译结果存在 CodeCache，默认上限（分层编译下 -XX:ReservedCodeCacheSize 约 240MB）。写满后 JIT 停止编译甚至退回解释执行，日志出现 CodeCache is full. Compiler has been disabled。
  • 排查：-XX:+PrintCodeCache、jcmd <pid> Compiler.codecache、JFR Compilation 事件。
  • 缓解：适度调大 CodeCache，-XX:+UseCodeCacheFlushing（较新版本默认开）清理不用方法；根治是减少「生成大量一次性代码」的来源（如疯狂 CGLIB 代理）。
• 区分：预热问题是「临时性、随运行变好」；CodeCache 满是「运行一段时间后突然变差、且不恢复」。

延伸：两者常同源——动态生成大量类既撑 Metaspace，也撑 CodeCache。

结论：许多 STW 操作都要求「所有线程到达安全点」，如果某些线程迟迟到不了，或发生偏向锁批量撤销，就会产生与业务量不成比例的停顿。

• Safepoint 机制：GC、jstack、JFR 采样、线程 dump、偏向撤销等都需要 STW。JVM 让线程在「安全点」（循环回边、方法返回等）主动检查并挂起。
• Time-To-Safepoint（TTSP）：从发起 STW 到所有线程停下的耗时。若某线程卡在长循环 / 长 native 调用里，TTSP 就很长，表现为「暂停几百 ms 但 GC 本身没干多久」。
• 可数循环（counted loop）：为优化，JVM 历史上对可数循环不插安全点轮询，超长循环会让线程长时间无法响应 STW；较新 JDK 通过 -XX:+UseCountedLoopSafepoints（默认开）缓解。
• 偏向锁：JDK 15 起默认关闭（-XX:-UseBiasedLocking），后续版本相关参数被废弃。原因是批量撤销需要 STW，与低延迟目标冲突，而多数现代负载收益有限。
• 排查：-Xlog:safepoint 看每次 STW 的 TTSP 与内部耗时；jcmd <pid> VM.info；JFR 的 Safepoint 事件把「到安全点耗时」和「安全点内耗时」分开。

延伸：能说出「停顿 = TTSP + 安全点内耗时」并会用 JFR 区分，就已经高于背诵阶段。

结论：MAT 把 heap dump 转成引用图，靠「支配树 + retained size」快速找出「谁占了大头、谁该背锅」。

• Dominator Tree：若到达对象 B 的所有路径都必经过 A，则 A 支配 B；回收 A 才能回收 B 的整棵子树，其 retained size 就是「拿掉 A 能释放多少内存」。
• 用法：按 retained size 从大到小排，顶层往往就是问题根源（一个巨大的缓存 Map、一个大数组、一个 ThreadLocal 容器）。
• Leak Suspects：MAT 自动生成的「泄漏嫌疑报告」，列出占比最高的几个对象及其引用链，作为切入点。
• Path to GC Roots：右键对象 → 查看到 GC Roots 的引用链，且排除弱引用 / 软引用，剩下的强引用才是「谁 hold 住了它」。
• 注意：dump 可能数 GB，jmap -dump / jcmd GC.heap_dump 会 STW，应在低峰执行，并配 -XX:+HeapDumpOnOutOfMemoryError 在 OOM 时自动落盘。

延伸：读 MAT 的顺序是「自动报告找方向 → 支配树排大小 → 引用链定根因」，不要一上来就翻几十万个对象。

结论：Native Image 在构建期做 AOT 编译，把应用与依赖静态编译成一个本地可执行文件，运行时不再需要 JVM/JIT——启动极快、内存更小，但牺牲动态能力与峰值吞吐。

• 原理：构建期做「封闭世界假设」（closed-world），静态分析出所有可达的类与方法，直接生成机器码；运行时没有类加载、没有 JIT 预热。
• 收益：启动几十毫秒级、常驻内存显著降低、镜像体积小，适合 Serverless / 函数计算、CLI、短生命周期容器、边缘网关。
• 代价：
  • 反射、动态代理、JNI、资源加载必须在构建期显式配置（reflect-config.json / proxy-config.json / resource-config.json），或用 tracing agent 采集后固化，否则运行时报错。
  • 不支持运行期字节码增强 / 动态生成类的一部分用法（依赖 CGLIB 动态代理、热部署会受限）。
  • 峰值吞吐通常低于「JIT 充分预热」的 JVM。
• 适用 / 不适用：
  • 适用：Spring Boot 3 + AOT、无状态短任务、对冷启动敏感的服务。
  • 不适用：重度依赖运行时代理 / 动态特性、纯吞吐导向的长跑服务。

延伸：答「启动快、内存小」只是及格，能说出「封闭世界假设 + 反射需配置 + 吞吐取舍」才到位。

结论：按「确认是堆外 → 分类记账 → 系统视角验证 → 定位子系统」四步走，不要盲目加堆。