第 28 章 Java 语言与对象模型

语言层语法只是表象，本章把 Java 的对象模型、分派机制与语言陷阱落到 JVM 字节码与内存布局上。

学习目标

读完本章，你应当能够：

1. 用 JVMS 的方法调用指令集解释"重载编译期绑定、重写运行期绑定"的机制根因，并说出 vtable 在类加载期是如何构造的。
2. 计算一个 Java 对象与数组在开启指针压缩下的字节数，并推导 32 GB 堆边界是怎么算出来的。
3. 说明违反 equals/hashCode 契约后 HashMap 查找失败发生在哪一步，并写出正确重写模板。
4. 辨析 final、static、String 常量池、自动装箱缓存各自"在什么时机生效、为什么是这个时机"。
5. 从字节码层面解释 finally 里 return 吞异常、try-with-resources 的抑制异常、桥接方法的产生原因。
6. 判断 JDK 动态代理与 CGLIB 的适用边界，并为 Spring AOP 的代理选择给出判据。

前置知识检查

28.1 三大特性在 JVM 层的落点

28.1.1 封装：访问控制与逃逸分析是两件事

private 是编译期约束：javac 把跨类访问私有成员直接编译报错，字节码里用 ACC_PRIVATE 标记，运行期由 ClassLoader 之后的对象布局与反射访问检查兜底。它的真正价值不是"隐藏数据"，而是把不变量（invariant）的维护责任锁进一个类。

逃逸分析（escape analysis）与封装没有因果关系：它判断的是对象引用能否逃出方法或线程，用来做标量替换（scalar replacement）、栈上分配与锁消除（lock elision）；字段是否 private 与它无关，因为访问控制在 ClassLoader 阶段已校验完毕。

28.1.2 继承：vtable 的构造与字段隐藏

HotSpot 在类加载的链接阶段构造虚方法表（virtual method table, vtable）：先复制父类 vtable，再把本类中"签名相同且父类条目非 final/非 private“的方法替换到对应槽位，新方法追加到尾部。因此子类中重写的方法与父类方法占用同一个槽位下标。

1
2
3

class A { void f(); void g(); }            A.vtable: [0]=A.f  [1]=A.g
class B extends A { void f(); void h(); }  B.vtable: [0]=B.f  [1]=A.g  [2]=B.h
                                           ↑ 同槽位覆盖 → 调用点只需固定偏移

字段完全不同：字段访问在编译期按引用的声明类型生成 getfield/putfield，是"隐藏（hiding）“而非"重写（overriding）"。所以 A a = new B(); a.x 取的是 A.x，即使 B 也定义了 x——这是八股里最容易答错的一题。

28.1.3 多态：五条方法调用指令

有两条反直觉结论必须记住：final 实例方法仍编译为 invokevirtual（但 JIT 能证明无重写从而去虚化），而重载（overload）走的也是 invokevirtual——重载的选择发生在 javac 阶段，运行期那条指令照样是虚调用，只是它已经指向了唯一确定的描述符。

重载的编译期选择分三个阶段（JLS 15.12.2）：先按参数个数与子类型关系找适用方法，若多个适用则选最具体的；自动装箱、可变参数（varargs）在最后阶段才参与，所以 f(int) 与 f(Integer) 重载时传入字面量 1 永远选 f(int)。

28.2 对象的内存布局与大小计算

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

64 位 HotSpot + 指针压缩（默认）：
┌─ 对象头 12 B ─────────────────────────────────────────────────────────┐
│ Mark Word 8 B：hashCode:25 | age:4 | biased_lock:1 | lock:2           │
│   无锁/偏向态存位域；轻量级锁存栈上 Lock Record 指针；                    │
│   重量级锁存 ObjectMonitor 指针（位域与锁升级见第 30 章 30.3 节）         │
│ Klass Pointer 4 B：压缩后的类元数据指针                                 │
├─ 实例数据：按宽度重排 ─────────────────────────────────────────────────┤
│   long/double 8 B → int/float 4 B → short/char 2 B → byte/boolean 1 B  │
│   父类字段在前，同宽度字段尽量相邻以减少 padding                          │
├─ 对齐填充：补齐到 8 字节整数倍（对象起始地址 8 字节对齐）                  │
└───────────────────────────────────────────────────────────────────────┘
数组对象额外多 4 B length（压缩后），元素区按 8 B 对齐

一个可直接背下来的算例：class A { boolean b; long l; }，新对象头 12 B，字段重排后 l（8 B）在前、b（1 B）在后，实例数据 9 B，合计 21 B，填充到 24 B。重排的收益在字段更多时才显现：两个 boolean 与一个 long 混排时，重排能省下整个 8 B 的填充块。

指针压缩（compressed oops）的原理：JVM 把对象起始地址右移 3 位存入 32 位字段（8 字节对齐保证低 3 位为 0），因此 32 位可表示 2³² × 8 = 2³⁵ = 32 GB——这就是"32 GB 界线"的全部来源。超过后基址无法再用零基偏移表示，压缩指针失效，对象头从 12 B 涨到 16 B、引用从 4 B 涨到 8 B。

28.3 ==、equals 与契约

== 对基本类型比值，对引用类型比引用身份；equals 的 Object 默认实现就是 ==，语义完全取决于重写。契约来自 Object.equals 的 javadoc 与 JLS 对 hashCode 的要求：

“用可变字段做 hashCode“的失败链条值得完整走一遍：put 时按旧 hashCode 落在桶 3；改字段后 get，新 hashCode 落在桶 7，桶 7 里根本没有这个节点，返回 null；而 size 仍是 1——对象在表里，但永远取不出来。HashMap.getNode 的顺序是"桶下标相同 → hash 相等且 (k == key || key.equals(k))"，所以 equals 错导致同桶内找不到，hashCode 错导致连桶都进不去。

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

@Override
public boolean equals(Object o) {
    if (this == o) {                                  // 引用相同直接返回，天然满足反身性
        return true;
    }
    if (o == null || getClass() != o.getClass()) {    // 用 getClass 而非 instanceof：保证对称性
        return false;
    }
    User other = (User) o;
    return age == other.age                           // 基本类型用 ==，避免装箱
            && Objects.equals(name, other.name)       // 引用类型可能为 null，交给 Objects 兜底
            && Arrays.equals(tags, other.tags);       // 数组必须用 Arrays.equals，否则比引用
}

@Override
public int hashCode() {
    // 字段必须与 equals 完全一致；31 = 2^5 − 1 可编译成移位减，且碰撞率低
    return Objects.hash(name, age, Arrays.hashCode(tags));
}

28.4 String 不可变性与字符串常量池

不可变的四个理由各自对应一处具体收益：

1. 常量池共享安全：同一份字面量被多个类共享，若可变，一处修改会污染所有持有者。
2. hashCode 可缓存：String 用一个非 volatile 的 hash 字段懒计算并缓存，不可变才让这个缓存永远有效。
3. 线程安全与传参安全：不可变对象天然可安全发布；文件路径、类名、SQL、URL 这类"传递即信任"的场景不会被中途篡改。

要区分三个容易混淆的"池”：常量池在 .class 文件中，是字面量与符号引用的静态表；运行时常量池在方法区（JDK 8+ 属 Metaspace），是类加载后装入内存的版本，且可动态添加（String.intern 就是其一）；字符串池则是 JDK 7 起位于堆中的一个 StringTable 哈希表（默认桶数 60013），JDK 6 时它在永久代。

intern() 的差异是必考项：JDK 6 中池在永久代，intern 必要时复制一份到永久代并返回那一份；JDK 7+ 池在堆中，intern 直接把堆上该对象的引用存入 StringTable 并返回，不再复制。所以 JDK 7+ 下两个内容相同的 String 分别 intern() 后 == 成立，且 -XX:StringTableSize 直接决定 intern 的吞吐。

+ 拼接的编译期/运行期差异：

28.5 自动装箱与缓存

1
2
3
4
5
6
7

Integer.valueOf(int) 的实际逻辑（JDK 源码语义）：
    if (i >= IntegerCache.low && i <= IntegerCache.high)
        return IntegerCache.cache[i + (-low)];   // 直接返回缓存数组元素，零分配
    return new Integer(i);                       // 超出范围才新建

IntegerCache：low  = -128（固定）
              high = 127  （默认；-XX:AutoBoxCacheMax=<n> 可提高到该值）

于是高频陷阱题有了统一答案：Integer a = 100, b = 100; a == b 为 true（缓存命中）；Integer c = 1000, d = 1000; c == d 为 false（各自 new）；而 Integer a = 100; int b = 100; a == b 恒为 true，因为混用基本类型时先拆箱再比较。

循环里的装箱损耗要有数字感：把累加变量声明为 Long 而不是 long，每次迭代多一次 Long.valueOf 与一次 longValue；更要命的是对象无法被提升为寄存器，破坏 JIT 的循环优化，吞吐通常下降数倍到十倍量级，超出缓存范围的 new 还会持续产生 GC 压力。

28.6 final 与 static 的时机语义

final 字段的可见性保证要精确表述：构造器正常结束之后，其他线程通过正确发布得到的引用读取该 final 字段，一定能看到构造器中的写入值（含该字段所指向对象的字段），无需额外同步。但引用若通过数据竞争（data race）拿到，保证退化。两个前提容易被忽略：final 字段的写入必须发生在构造器返回之前（this 在构造期间逸出则保证失效）；该保证与 volatile 无关，是 JMM 单独定义的一条语义，也是不可变对象能免同步安全发布的根因（与第 30 章 30.5 节互为印证）。

static final 的内联陷阱：public static final int MAX = 100; 会被编译进调用方字节码，改动后只重编译常量所在类，调用方不重编译仍读到旧值。规避办法是改用 static final Integer（非常量表达式）或在构建流程里全量重编译。

28.7 异常体系、finally 与抑制异常

三分体系的关键差别不在"是什么”，而在谁承担处理责任：

受检异常的设计争议：它试图把错误处理编进类型系统，代价是签名污染与层层包裹，且在 Lambda/Stream 中几乎无法使用；主流 API（Spring 的 DataAccessException、多数 RPC 框架）把外部异常统一转成非受检异常，责任移交给全局异常处理器。它并非无用——资源型 API（Closeable）靠它强制释放资源。

28.7.1 finally 里的 return 为什么吞异常与返回值

1
2
3
4
5
6
7
8
9

public static int f() {   javac 的等价结构：
    int x = 1;            int x = 1;  Throwable saved = null;
    try {                 try {
        return x;   ────►     int tmp = x;      // 返回值先备份到临时槽位
    } finally {               goto FINALLY;
        x = 2;            } catch (Throwable e) { saved = e; goto FINALLY; }
        return x;         FINALLY: x = 2;  return x;
    }                     // ← 直接 return：覆盖返回值，且 saved 再无人 athrow ⇒ 异常被吞
}

结论分三条，必须分开说：

1. finally 中的 return 覆盖 try 的返回值：f() 返回 2，不是 1，因为返回值已在进入 finally 前被复制到临时槽位，而 finally 里的 return x 又读了一次被改过的 x。
2. finally 中的 return 吞掉 try 抛出的异常：字节码里保存异常引用的局部变量存在，但控制流走了 return 而不再 athrow，异常静默消失——这是最危险的一类 bug。
3. 若 finally 只改字段（this.x = 2）而不 return，try 的 return x 返回的是备份的旧值，字段却已是新值；引用类型返回的是备份的引用，对象内部状态变更照样可见。这就是"改返回值无效、改对象状态生效"的原因。

28.7.2 try-with-resources 与抑制异常

try (Resource r = open()) { ... } 的字节码形态：资源初始化在 try 之前，try 体与隐式的 close() 都在异常表的覆盖范围内。当 try 体抛 A、随后 close() 抛 B 时：若 A 存在则调用 A.addSuppressed(B) 并继续抛 A，否则抛 B。这就是抑制异常（suppressed exception）——B 不丢失但不替换主异常，要用 getSuppressed() 或主异常的 printStackTrace 才能看到。

因此 try-with-resources 里若两者都抛异常，日志必须看主异常的 printStackTrace（它才会打印 suppressed 列表），只打 close() 的异常会丢掉主异常。

OutOfMemoryError 与 StackOverflowError 都可以被 catch——它们是普通对象，只是捕获后能做的事极其有限（堆或栈仍处于耗尽状态，日志与序列化本身都可能再失败）。两条工程结论：不要写 catch (Throwable t) {} 把 Error 一并吞掉；在连接池、批量任务这类"元素级失败不应拖垮整体"的场景，捕获后快速释放资源并退出当前任务是可接受的兜底，但不能指望继续长期服务。

28.8 反射与动态代理

Class 对象的三种获取方式与副作用差异：X.class 不触发类初始化；obj.getClass() 需要已有实例；Class.forName("X") 默认触发类初始化（initialize=false 可关闭），而 ClassLoader.loadClass 只加载不初始化。这是"静态块什么时候跑"的经典考法。

反射的性能代价由四部分构成：方法查找（getDeclaredMethods 每次返回拷贝）、每次调用都做的访问检查（setAccessible(true) 可跳过）、参数装箱与 Object[] 分配、以及无法内联（目标方法对 JIT 不可见，失去常量传播与去虚化）。JDK 自带 inflation 机制：某调用点执行超过阈值（HotSpot 默认 15 次）后从 JNI 切换到生成字节码的 MethodAccessor，开销降一个数量级。框架坚持用反射，是因为它换来的在未知类型上延迟绑定的能力无可替代——注解扫描、依赖注入、序列化、AOP 都建立在"运行期才知道具体类型"之上；若反射成为热点，可用 MethodHandle 或运行期生成字节码（LambdaMetafactory）替代。

Spring AOP 的选择规则：目标类实现了接口且未强制 proxyTargetClass = true 时用 JDK 动态代理，否则用 CGLIB。因此 @Transactional 不生效的一种经典原因是类内 this 自调用——根本不经过代理对象，与代理类型无关，但排查时最容易被误判成"CGLIB 没生效"。

28.9 泛型擦除与桥接方法

擦除的证据是一行代码：new ArrayList<String>().getClass() == new ArrayList<Integer>().getClass() 为 true，且 getTypeParameters() 只有 E 这样的占位符。擦除的动机是二进制兼容：List 与 List<String> 的类文件格式不变，旧代码无需重编译；JVMS 只在 Signature 属性里额外记录泛型签名供反射读取。

擦除带来的限制可以一句话统一解释——凡是需要运行期知道实参类型的写法都不合法：

桥接方法（bridge method）的产生原因：class Box<T> { void set(T t) } 的子类 class StringBox extends Box<String> { void set(String s) }，擦除后父类签名是 set(Object)、子类签名是 set(String)——参数类型不同，不构成重写，多态失效。编译器于是在子类合成一个 set(Object)，内部 checkcast 后委派给 set(String)，标记为 ACC_BRIDGE | ACC_SYNTHETIC。它在反射中的两个可考点：getDeclaredMethods() 会返回它（需用 Method.isBridge() 过滤）；getMethod("set", Object.class) 能命中它而不是报 NoSuchMethodException。

PECS（Producer Extends, Consumer Super）的判据是类型参数的读写方向：List<? extends Number> 能 get 出 Number 但不能 add（编译器不知道真实元素类型）；List<? super Integer> 能 add(Integer) 但 get 只得到 Object。记忆锚点是"extends 只读、super 只写"，典型应用是 Collections.copy(List<? super T> dest, List<? extends T> src)。

28.10 序列化

Serializable 授权 JVM 用反射遍历对象图生成字节流，流格式的关键字段可以直接背：

1
2
3
4

序列化流头部（ObjectOutputStream）：
   AC ED 00 05                    ← magic 0xACED + 版本 5
   目标类描述符：类名、serialVersionUID(8B)、字段数量与类型、标志位
   随后是各字段值（按字段排序，transient 字段不写入）

serialVersionUID 的默认值是编译器按类名、修饰符、接口、字段与方法签名计算的哈希，任何一项变化都会让它改变；反序列化时流中的值与本地类不一致就抛 InvalidClassException: local class incompatible。所以需要持久化或跨服务传输的类必须显式声明，这样新增字段时旧数据仍能读出（新字段取默认值）。

反序列化安全问题的根因：readObject 是在构造器之外执行可控代码的入口，调用链可被设计成 gadget（工具链），因此它不是"数据可信度"问题，而是"把字节流当代码执行“的问题；处置方式是不要反序列化不受信任的输入、用 ObjectInputFilter（JDK 9+）做类白名单。现代系统倾向 JSON/Protobuf 的理由：跨语言、可读可调试、数据结构与代码解耦（字段缺失时取默认值而非报不兼容）、体积更小且无需反射遍历对象图，以及从根本上消除 gadget 链风险。

本章小结

自测题

Q1（计算）64 位 HotSpot、开启压缩指针、堆 16 GB。class Point { int x; int y; } 与 class Node { Point p; int id; } 各占多少字节？数组 new Point[10] 占多少？

Q2（判断 + 解释）下面代码打印什么？逐行给出理由。

1
2
3
4
5
6
7
8
9

Integer a = 127, b = 127;
Integer c = 128, d = 128;
Integer e = new Integer(127);
Long f = 127L, g = 127L;
System.out.println(a == b);
System.out.println(c == d);
System.out.println(a == e);
System.out.println(a == f);
System.out.println(a.equals(f));

Q3（推导）解释为什么下面程序输出 200 和 0，并说明这暴露的是 JVM 行为还是纯语法行为。

1
2
3
4
5
6
7
8
9

static int f() {
    int x = 1;
    try {
        return x;      // 返回值被复制到临时槽位
    } finally {
        x = 2;         // 只改局部变量 → 不影响已复制的返回值
        // 若这里写 return x; 则既覆盖返回值、又让暂存的异常再无人 athrow
    }
}

Q4（设计）你要为一个"用户对象做缓存的 HashMap 键"的类写 equals/hashCode。给出实现，并说明为什么用 getClass() 而不用 instanceof，以及为什么两个方法必须覆盖同一组字段。

Q5（辨析）"List<String> 与 List<Integer> 在运行期是同一个类型，所以泛型毫无价值。“请评价这句话，并说明桥接方法与 TypeReference 分别在什么意义上"突破了"擦除。

面试高频问题与陷阱

延伸阅读

• Oracle《Java 语言规范》第 15.12 节（方法调用与重载解析）、第 17.5 节（final 字段语义）、第 5.1.7 节（装箱转换）。
• Oracle《Java 虚拟机规范》第 2.11 节（类型擦除与桥接方法）、第 6.5 节（invokevirtual/invokeinterface/invokedynamic 的解析过程）。
• Oracle Java SE 文档：Object.equals/hashCode 契约、Serializable 与 ObjectInputFilter、Proxy 与 InvocationHandler；OpenJDK HotSpot 源码说明中的 oops/oop.hpp（对象头布局）、compressedOops 基址与移位策略、IntegerCache/StringTable。
• 与本书的衔接：HashMap 的哈希扰动与树化见第 29 章 29.2 节；final 域与安全发布见第 30 章 30.5 节；对象分配、TLAB 与 Metaspace 见第 32 章 32.1 / 32.2 节。