主题 02Java 基础

2.1为什么第二站是 Java 基础

集合排第一是因为它和算法重合最多；Java 基础排第二，是因为它是所有追问的公共底盘。 面试官不会直接问「说说 Java 基础」，但下面这些话都是它的变体：

所以这一章的写法是：每个点先给一段能跑出反例的代码，再给结论。 下面所有输出都不是我编的，是把示例程序在 JDK 17 上跑出来的原样结果——你也可以照着敲一遍验证。

2.2值传递：为什么 swap 改不动实参

Java 只有一种传参方式：值传递。基本类型传的是数值的副本，对象传的是引用的副本—— 注意是「引用这个地址值的拷贝」，不是「引用本身」。这两句话差一个字，面试就差一整档。

static void changeInt(int x)      { x = 100; }              // 改副本，实参不变
static void changeFirst(int[] a)  { a[0] = 100; }           // 通过副本找到同一个数组，改里面的元素
static void reassign(int[] a)     { a = new int[]{9, 9}; }   // 让副本指向新数组，实参不受影响
static void swap(int x, int y)    { int t = x; x = y; y = t; }

把它跑起来，四行输出就足以区分三种情况：

[1] 传 int       : 1
[1] 改数组元素   : 100
[1] 重新赋值形参 : 1
[1] swap 之后    : a=1, b=2

逐行对照：

• 传 int 还是 1：changeInt 改的是副本 x，方法结束副本就扔了。
• 数组元素变成 100：形参 a 是引用的副本，但它和实参指向同一个数组对象， 所以改元素双方都看得见。这是「看起来像引用传递」的全部原因。
• 重新赋值形参没影响外面：a = new int[]{9,9} 只让副本改指新对象， 实参还指着老数组。如果真是引用传递，这里外面就该变成 9。
• swap 无效：两个 int 副本互换，方法返回就丢了。Java 没法写出真正交换基本类型的 swap 方法。

三个必被追问的点

2.3String：不可变、常量池与 intern

String 是八股里出场率最高的类，因为它同时踩中三件事：不可变、常量池、+ 的编译期优化。 这三件事互相解释，抓住「不可变」这一个根，其余都是推论。

先看一组 == 的结果

String a = "abc";                 // 字面量 -> 常量池
String b = "abc";                 // 复用同一个对象
String c = new String("abc");     // 堆上新对象
String d = "ab" + "c";            // 编译期折叠成 "abc"
String e = new StringBuilder("ab").append("c").toString();

System.out.println("a == b        : " + (a == b));
System.out.println("a == c        : " + (a == c));
System.out.println("a == d        : " + (a == d));
System.out.println("a == e        : " + (a == e));
System.out.println("c.intern()==a : " + (c.intern() == a));

a == b        : true
a == c        : false
a == d        : true
a == e        : false
c.intern()==a : true

把这五行的原因按顺序记住，String 的题就通关了一半：

为什么换个写法就变了

关键在「参与拼接的是不是常量」。"ab" + "c" 两个操作数都是字面量，javac 直接算出结果写进 class 文件； 但只要有一个是变量，就必须等到运行时：

String s = "ab";
String f = s + "c";
System.out.println("a == (s+\"c\")  : " + (a == f));      // false
System.out.println("a.equals(f)   : " + a.equals(f));   // true

编译器会把 s + "c" 改写成 new StringBuilder().append(s).append("c").toString() （JDK 9 之后是 invokedynamic + StringConcatFactory，语义一样）。 所以「循环里用 + 拼字符串慢」的真正原因不是「+ 慢」，而是每次循环都在造新的 StringBuilder、新的 String。

不可变带来的三个实际收益

1. 常量池才成立。如果 String 可以被改，a 和 b 共享同一块内存时，改 a 就等于偷偷改了 b—— 共享的前提就是谁都改不了。
2. hashCode 可以缓存。内容不变，hash 就不会变，所以 String 把第一次算出的 hash 存进字段 hash， 之后直接返回。这就是「String 做 key 特别快」的真实原因。
3. 可以放心跨线程传。不可变对象天生线程安全，不需要任何同步。

2.4equals 与 hashCode 的契约

这一节是全章最「工程」的一节：写错了不会报错，只会静默失效—— 放进 HashMap 取不出来、放进 Set 出现重复元素，跑一天都发现不了。

先看反例

static class PointBad {              // 什么都没重写
    int x, y;
    PointBad(int x, int y) { this.x = x; this.y = y; }
}

static class Point {                 // 两个都重写
    final int x, y;
    Point(int x, int y) { this.x = x; this.y = y; }
    @Override public boolean equals(Object o) {
        if (this == o) return true;                     // 同一个对象，短路
        if (!(o instanceof Point p)) return false;      // 类型不对，直接 false（含 null）
        return x == p.x && y == p.y;
    }
    @Override public int hashCode() { return 31 * x + y; }
}

未重写 equals   : false
重写后 equals   : true
重写后 hashCode : true
HashMap 取得到吗 : 命中

第一行 false 说明：不重写 equals 时，Object 的实现是比地址， 两个内容相同的对象永远不相等。最后一行 命中 才是重点——只有两个方法都重写，HashMap 才认得它是同一个 key。

契约四条，只记两条就够用

为什么系数是 31

三个原因叠在一起：31 是奇质数（乘出来不容易撞）、 31 * i 能被编译器优化成 (i << 5) - i（移位比乘法快，早期 JVM 很在意这个）、 以及 String.hashCode 用的也是 31，属于 JDK 里的经验值。你写别的质数（比如 17）也不算错， 但面试问「为什么是 31」时要能说出前两条。

2.5泛型与类型擦除

泛型是「编译期的语法糖」——这句话要能顺手给出证据。最硬的证据是三行代码：

List<String> ls = new ArrayList<>();
List<Integer> li = new ArrayList<>();
System.out.println(ls.getClass() == li.getClass());   // true
System.out.println(ls.getClass().getName());          // java.util.ArrayList

两个泛型类的 Class 相同: true
运行时类名: java.util.ArrayList
字段的泛型描述: java.util.List<T>

运行时它们是同一个类，尖括号里的东西已经被擦掉了。擦除规则很简单： <T> 擦成 Object，有上界（<T extends Number>）就擦成上界。

擦除带来的四个限制

那为什么还要这么设计？为了向后兼容。泛型是 JDK 5 才加的， 擦除保证老版本编译出来的 class 文件、老的第三方库不需要改一行就能在新 JVM 上跑。

怎么绕过「不能 new T[]」

@SuppressWarnings("unchecked")
static <T> T[] newArray(int n) {
    return (T[]) new Object[n];      // 先造 Object[]，再强转，责任自负
}

这是 JDK 自己也在用的写法（ArrayList 的 elementData 就是这么干的）。 代价是：运行时它其实是 Object[]，往里面塞错类型不会当场报错，而是等到取出来赋值时才抛 ClassCastException—— 这就是「泛型不安全」这个说法的来源。

通配符：PECS 一句话

Producer Extends, Consumer Super：只读用它产出的数据，用 ? extends T； 只往里写数据，用 ? super T。记不住规则就记这个场景： List<? extends Number> 你能 get 出 Number，但 add 不进去（因为不知道具体是哪个子类）； List<? super Integer> 你能 add Integer，但 get 出来只能是 Object。

2.6自动装箱与 Integer 缓存

这一段只有一个小知识点，却是线上 bug 的常客：两个 Integer 用 == 比，有时 true 有时 false。

Integer i1 = 127, i2 = 127;
Integer i3 = 128, i4 = 128;
System.out.println("127 == 127 : " + (i1 == i2));    // true
System.out.println("128 == 128 : " + (i3 == i4));    // false
System.out.println("128 equals : " + i3.equals(i4)); // true

原因在 Integer.valueOf(int)：它会先看值在不在 -128 ~ 127 这个缓存区间里， 在就直接返回缓存数组里的同一个对象，不在才 new。127 两次拿到同一个对象，所以 == 为 true； 128 两次各自 new，地址不同。

结论只有一句：包装类比较值，一律用 equals；需要算术运算前先确认非空。 至于性能，别在百万次循环里对基本类型反复装箱——List<Integer> 装 100 万个 int， 内存开销大约是 int[] 的 4 倍以上（对象头 + 引用）。

2.7初始化顺序：谁先谁后

这是唯一一节「不用理解、只要背对顺序」的内容，但答错的人出乎意料地多。看输出比看文字快：

static class Parent {
    static { System.out.println("1 父类静态块"); }
    { System.out.println("3 父类实例块"); }
    Parent() { System.out.println("4 父类构造器"); }
}

static class Child extends Parent {
    static { System.out.println("2 子类静态块"); }
    { System.out.println("5 子类实例块"); }
    Child() { System.out.println("6 子类构造器"); }
}

new Child();

1 父类静态块
2 子类静态块
3 父类实例块
4 父类构造器
5 子类实例块
6 子类构造器

把它拆成两段记，就不会混：

• 第一段是「类初始化」（1、2）：父类先、子类后，而且整个程序生命周期只跑一次—— 再次 new Child() 时这两行不会再打印。
• 第二段是「对象初始化」（3–6）：父类实例块 → 父类构造器 → 子类实例块 → 子类构造器， 每次 new 都完整跑一遍。父类先于子类，是因为子类构造器第一句隐式调了 super()。

final 的三种用法，别混在一起

顺带记住 final 在并发里的作用：被 final 修饰的字段，在构造器里写完就有安全发布的保证， 别的线程看到这个对象时一定看得到它的 final 字段值——这也是后面并发章要展开的 volatile / 内存屏障的起点。

2.8本章速记卡与自测

这一章的五个点都属于「一句话能说完、但必须说准」的类型。下面这张表就是面试前一晚要过的东西。