这一期的题目是从最近几轮模拟面试里筛出来的。Java 基础面试里的八股文题向来是看着简单、追问就露怯的重灾区。问 String 为什么不可变多数人张口就是final 修饰、不能继承再追一句不可变到底带来了什么好处很多回答就开始东一句西一句了。八股文背到后面最怕的不是忘了答案而是只记住了答案没记住答案在解决什么问题。这一期继续走十问十答的路线选了十个覆盖面试高频区间的基础题String、重载重写、equals 和 hashCode、抽象类与接口、ArrayList 扩容、HashMap put 流程、volatile、异常体系、泛型擦除、反射机制。每一道题我都尽量把面试官可能会追问的方向写清楚。适合正在准备 Java 岗位面试的人参考也适合回头审视一下自己对这些基础概念的掌握是不是真的够扎实。1. 第十三期题目总览十个问题到底在考什么先说一句个人的判断基础题能不能拿高分看的不是会不会背而是能不能把答案讲出层次。同样一道题第一层是结论第二层是原理第三层是边界条件和典型反例。多数面试者停在了第一层少数人能讲到第二层能讲到第三层的基本就是候选人里比较稳的那批了。这一期选题目的时候我有意挑了那些网上能找到标准答案但标准答案往往没说透的题。序号问题核心考点容易丢分的地方第一问String 为什么设计成不可变类设计思想、常量池、线程安全只会背 final说不出价值第二问重载和重写的区别编译期分派、运行期多态、方法签名说不清异常和访问权限规则第三问equals 和 hashCode 约定集合框架的正确使用前提只知道规则不知道违反的后果第四问抽象类和接口怎么选面向对象设计意图、Java 8 接口变化还在背旧版区别第五问ArrayList 扩容过程动态数组扩容策略、均摊复杂度不知道第一次扩容是 10第六问HashMap put 流程哈希表定位、树化阈值、扩容规律记错阈值条件和原因第七问volatile 的作用边界可见性、有序性、原子性误以为 volatile 能保证原子性第八问异常体系与处理原则受检异常、运行时异常、资源关闭finally 里 return 或吞异常第九问泛型和类型擦除擦除机制、桥方法、通配符不知道为什么不能 new T[]第十问反射机制是什么运行时元信息、框架基础简单回答破坏封装应对这些题一个比较实用的思路是结论 原理 反例三步走。比如问 volatile先说结论是保证可见性和有序性、不保证原子性再讲它为什么能保证可见性、为什么扛不住 i最后举个读改写三步竞争的例子。这样一顿回答下来面试官基本不需要再追问第二遍。2. 字符串与面向对象三连问String、重载重写、equals 与 hashCode2.1 第一问String 不可变的两层回答怎么做到与为什么有价值这道题几乎每场 Java 面试都会出现但大部分回答只覆盖了怎么做到。先讲第一层怎么做到。String 类被 final 修饰因此不能被继承。类内部保存字符串内容的字段也是 final 的JDK 8 及以前是private final char[] valueJDK 9 之后改成了private final byte[] value同时用一个 coder 字段区分 LATIN1 和 UTF16 编码目的主要是节省内存。对外提供的所有看似能修改内容的方法比如 concat、replace、substring都不是在原数组上改而是生成一个新的 String 对象返回。这就是不可变的三层保证类不可继承、字段引用不可改、底层数组内容不可被外部篡改。再讲第二层为什么要有这样的设计这才是拉分的地方。第一个价值是字符串常量池复用。Java 里String s1 abc这样的字面量会放进常量池大量变量可以引用同一个对象。如果 String 可变一个引用把abc改成了abd其他持有同一引用的地方全都跟着错这种情况下常量池就完全没有意义了。第二个价值是线程安全。不可变对象天然线程安全不需要任何同步机制。字符串在系统里是最高频的共享数据类名、文件路径、配置项、SQL到处都在共享字符串如果它可变整个并发模型会复杂很多倍。第三个价值是支持哈希缓存。String 重写了 hashCode它内部有一个字段缓存哈希值第一次调用之后直接返回缓存结果。之所以能放心缓存正是因为内容不可变。这也是 String 适合做 HashMap key 的一个深层次原因。第四个价值是安全性。类加载、网络地址解析这些场景都依赖字符串的完整性可变字符串等于给了恶意代码篡改类名或地址的机会。面试官大概率会追问一个经典问题new String(abc)创建了几个对象。如果常量池里已经有abc字面量那只需要创建一个堆上的 String 对象如果常量池里没有abc则会同时创建常量池对象和堆对象一共两个。这里要特别注意JDK 7 之后字符串常量池挪到了堆里但常量池里的对象和new 出来的对象依然是两个不同的对象用比较结果是 false。至于 StringBuilder 和 StringBuffer 的区别单线程场景的拼接优先用 StringBuilder它不额外加锁性能更好StringBuffer 在每个公共方法上加了 synchronized线程安全但开销更大。还有一个容易被忽略的点编译器在单个表达式或方法内会把字符串拼接优化成 StringBuilder 的 append 链但在循环里每次迭代都会 new 一个新的 StringBuilder所以循环拼接大量字符串时最好自己在循环外显式创建 StringBuilder。2.2 第二问重载重写背后的方法分派逻辑重载和重写是 Java 多态的两种表现形式但它们的决定时机完全不同。重载发生在编译期。同一个类里方法名相同参数列表不同编译器根据调用点传入的参数类型、个数、顺序静态地决定调用哪个方法。这里有一个很多的误区返回值不同不构成重载。因为调用方法时可以不接收返回值foo()到底该匹配返回 int 还是返回 String 的版本编译器根本无从判断。重写发生在运行期。子类重新实现父类已有的方法JVM 在执行 invokevirtual 指令时根据对象的实际类型去虚方法表中查找最终的方法入口。同一个父类引用指向不同的子类对象调用同一个方法会走不同实现这就是运行期多态。重写必须满足的规则可以浓缩成几句话方法名相同、参数列表相同、返回类型相同或者协变子类返回类型可以是父类返回类型的子类型、访问权限不能比父类更严格、抛出受检异常的范围不能比父类更宽。维度规则方法签名方法名和参数列表完全一致返回类型相同或者是父类返回类型的子类型访问权限相同或更宽不能更严格受检异常相同或更窄不能抛出父类没有的更宽异常有几个易错点值得单独强调。静态方法不存在重写子类里写一个与父类静态方法签名相同的方法那叫隐藏。用父类引用去调用时输出的还是父类的方法实现因为静态方法在编译期就绑定了。private 方法对子类不可见子类定义一个同名同参的方法也不算重写。final 方法直接禁止重写这是 final 的语义之一。加分回答方向可以主动提一下协变返回类型。父类方法返回 Object子类重写后返回 String这是合法的。编译器在生成字节码时还会为协变返回类型生成一个桥方法来保证兼容性这一块和后面泛型擦除的桥方法逻辑是相通的。面试官如果继续追问重载方法能不能靠返回类型区分回答是不能但如果问编译后的字节码里方法签名包含返回类型吗答案是包含。JVM 的方法描述符由参数类型返回类型组成这不是语言层面的重载规则是字节码层面的差异能分清这两层基本就把这道题答透了。2.3 第三问equals 和 hashCode区别不在要不要都重写而在为什么要一起先理清 Object 默认行为。Object 的 hashCode 默认是地址相关的一个值equals 默认等同于比较的是内存地址。两个内容完全相同的对象不重写的话 equals 结果是 false。为什么重写 equals 必须重写 hashCode因为 Java 里基于哈希的集合全都依赖这两者的契约同一个对象多次调用 hashCode只要 equals 没变结果必须一致两个对象 equals 为 truehashCode 必须相等两个对象 hashCode 相等equals 不一定为 true这就是哈希碰撞。违反第二条会直接导致 HashMap、HashSet 行为异常。往 HashMap 里 put 了一个对象再用一个内容相同的对象去 get第一步按 hashCode 计算桶位如果两个 hashCode 不相等它们被放进了不同的桶永远没有机会用 equals 比较结果自然是 null。这种 bug 通常很难排查因为逻辑上它们明明相等。equals 方法的经典实现模板大致是这样Override public boolean equals(Object o) { if (this o) { return true; } if (o null || getClass() ! o.getClass()) { return false; } User user (User) o; return Objects.equals(id, user.id) Objects.equals(name, user.name); }这里有一个值得展开的设计选择用 getClass() 还是 instanceof。如果允许子类实例与父类实例比较相等可以用 instanceof但这样要小心对称性父类 equals 子类为 true子类 equals 父类可能也是 true看起来对称但继承体系一复杂就容易破坏约定。大多数业务场景建议用 getClass()严格限定同一类型才能相等。hashCode 通常用参与 equals 判断的字段来生成。经典的写法是Override public int hashCode() { return Objects.hash(id, name); }手写的时候一般会用 31 作为乘子这是有原因的。31 是素数素数做乘子能让哈希值分布更均匀减少碰撞而且 31 等于32 - 1JVM 可以把乘法优化成移位和减法的组合(hash 5) - hash计算效率很高。还有一个开发中容易遇到的坑一个对象被放进 HashSet 之后如果修改了参与 hashCode 计算的字段它的 hashCode 变了集合内部永远找不到原来的桶位这个对象就丢了。所以放进集合的对象尤其使用哈希集合时关键字段最好不要允许外部修改。这类问题在八股文里不会直接问但面试问到为什么说可变对象不适合做 HashMap key本质考的就是这一点。3. 抽象类接口与 ArrayList 扩容一个考设计意图一个考数据结构细节3.1 第四问抽象类和接口怎么选Java 8 之后话术要更新如果现在还按教科书上抽象类可以有实现方法接口只能有抽象方法来回答面试官会觉得知识体系停在了 Java 7 时代。Java 8 之后接口可以定义 default 方法和 static 方法Java 9 又加入了 private 方法语法层面的差异已经非常模糊了。这题的真正考点是你理解不理解两者在设计意图上的差异。抽象类描述的是是什么强调的是 is-a 关系适合把一批有公共状态、公共逻辑的类做共性抽取。典型场景是模板方法模式父类把算法骨架和执行流程写死需要子类差异化的步骤留成抽象方法。父类可以持有实例字段比如数据库连接的配置、日志对象、流程状态子类共享这些字段和通用逻辑。接口描述的是能做什么强调的是 can-do 关系适合定义能力协议和外部契约。接口不能有实例字段所有字段默认是 public static final接口本身不保存业务状态只是规定调用方可以怎么用。选型建议可以归纳成一句话核心是看多个类之间是共享代码和状态还是共享行为规范。如果几个类在概念上属于同一类事物并且需要公共字段和通用实现用抽象类如果完全不相关的类都需要具备某个能力比如随便什么对象都能被序列化、能被比较、能被遍历那必须用接口。Java 8 的 default 方法出现之后产生了一个新的追问点一个类同时实现两个接口两个接口有同名同参的 default 方法会发生什么答案是编译报错这个类必须重写该方法否则无法消解冲突。重写之后以类中实现为准。还有一个细节抽象类可以定义构造方法虽然不能直接 new但子类构造时会先调用父类构造器完成父类部分的初始化。接口不行。这个差异在面试里偶尔会被拿来考背后说明抽象类是有实例骨架的接口更像一张纯协议清单。3.2 第五问ArrayList 扩容到底扩到多少以及为什么是 1.5 倍ArrayList 底层是一个 Object 数组扩容问题的核心是数组容量不够了怎么办。先看无参构造。new ArrayList()创建出来的内部数组是DEFAULTCAPACITY_EMPTY_ELEMENTDATA是一个空数组长度 0。第一次 add 时ensureCapacityInternal 会计算需要的容量取默认容量 10 和实际元素数量加 1 的较大值所以第一次添加元素后内部数组直接扩容到 10。这是很多人会漏掉的点平时只知道扩容是 1.5 倍却不知道第一次其实是 0 到 10。后续的扩容逻辑在 grow 方法里int newCapacity oldCapacity (oldCapacity 1);oldCapacity 1相当于除以 2所以新容量是旧容量的 1.5 倍。用右移代替除法纯粹是性能考虑。如果算出来的 1.5 倍还是小于我们实际需要的 minCapacity那直接用 minCapacity。这一步在超大容量场景下很重要比如已经很大了但突然要一次性加入大量元素。再往上走还有一个边界处理。Java 数组有最大长度限制ArrayList 里定义了一个 MAX_ARRAY_SIZE值是Integer.MAX_VALUE - 8。为什么减 8因为某些 JVM 实现需要保留一部分数组头空间。如果 newCapacity 超过 MAX_ARRAY_SIZE就会调用 hugeCapacity最终可能直接扩容到 Integer.MAX_VALUE。这个值理论上已经接近 JVM 内存极限真走到这一步大概率是先 OOM 而不是优雅扩容。复制过程用的是 Arrays.copyOf底层是 System.arraycopy 这个 native 方法。批量搬迁意味着扩容本身是 O(n) 操作但因为扩容频率呈指数级下降均摊下来 ArrayList 的尾插仍然是 O(1)。这是回答ArrayList 尾部 add 复杂度时应该给出的完整答案。面试官随后往往会追问中间插入复杂度是多少add(index, element)需要先把 index 位置及之后的元素整体后移一位时间复杂度 O(n)。这和你用的是数组实现有关懂了这个自然就能对比出 LinkedList 在头尾操作的差异但这个差异在 CPU 缓存和内存连续性的影响下并不总是那么明显。实战建议就一条能预估数据量时尽量用new ArrayList(预估容量)或者循环添加前调用 ensureCapacity。我见过不少线上问题其实不是 ArrayList 的错而是创建时没给容量循环里 add 了几十万条触发了十几次扩容老数组反复复制内存和 GC 压力都上去了。4. HashMap 与 volatile两个看起来熟悉却经常讲不透的机制题4.1 第六问JDK8 HashMap 的 put 流程、树化阈值和扩容规律HashMap 这道题能讲明白的人基本可以把集合这块都串起来。JDK 8 的 HashMap 底层结构是数组加链表加红黑树。和 JDK 7 相比除了引入红黑树之外最大的变化是链表插入从头插法改成了尾插法原因之一是头插法在并发扩容时可能产生环形链表导致下次 get 时形成死循环。put 的完整流程可以梳理成这么几条对 key 的 hashCode 做扰动处理(h key.hashCode()) ^ (h 16)。目的是让高 16 位的信息也能参与低位运算因为桶下标只取 hash 的低位没扰动过的 hashCode 在低位相同、高位不同的情况下会大量碰撞。如果 table 还没初始化或者长度是 0先走 resize 方法。用tab[i (n - 1) hash]定位桶位置。之所以能用位运算替代取模前提是 table 容量必须是 2 的 n 次幂。如果桶位置是 null直接 new Node 放进去。否则说明产生了碰撞要么去链表里找要么去红黑树里找。找到相同 key 就覆盖 value没找到就尾插到链表末尾或者插入红黑树。链表插入后如果链表长度达到 TREEIFY_THRESHOLD 且数组长度达到 64就把这个桶的链表转成红黑树。每次 put 完成后 size 自增如果超过 threshold也就是容量 * 负载因子就扩容。树化条件有两个很多答案只说链表长度到 8漏掉了数组长度必须到 64。如果链表长度已经到 8但数组长度还不到 64HashMap 不会立即转树而是优先扩容。因为扩容之后链表会被打散长度通常会降下来。这么设计是为了避免在容量还很小的哈希表上动不动就因为碰撞转树毕竟树节点占据的空间和操作复杂度都比普通节点高。关于阈值为什么是 8官方的解释和泊松分布有关。负载因子 0.75 下桶内链表长度达到 8 的概率已经低到千万分之一左右。换句话说正常情况下链表不应该长到 8真出现这种情况基本说明哈希函数的质量出了问题或者 key 分布严重不均匀需要红黑树来兜底。扩容时容量变为原来的 2 倍元素位置有一个非常漂亮的规律由于新容量也是 2 的幂hash (newCap - 1)只看原来 32 位哈希里多出来的那一位。这一位是 0节点留在原索引这一位是 1节点移动到原索引 oldCap。这也是 JDK 8 扩容不用重新计算 hash 的原因性能上比 JDK 7 的 rehash 好很多。还有两个常被追问的小点。key 为 null 的情况HashMap 允许 null key它会被直接放到 table[0] 对应的桶里用常量 NULL_KEY 特殊处理。HashMap 本身不是线程安全的并发 put 会丢数据JDK 8 修掉了死循环但依然会有覆盖更新和 size 统计不准的问题需要并发场景时使用 ConcurrentHashMap。4.2 第七问volatile 三句话讲清楚再加一条边界volatile 是所有并发基础题里每次都会出现的角色它的作用可以浓缩成三句话。第一保证可见性。对一个 volatile 变量的写操作JVM 会插入内存屏障把当前线程工作内存里改动的值强制刷回主内存对这个变量的读操作不会再从线程的私有缓存里取值而是直接从主内存读。简单理解就是一个线程改了其他线程立刻能看到。第二禁止指令重排序。编译器和 CPU 为了优化可能改变指令执行顺序但 volatile 会限制这种重排。volatile 写之前的普通读写不能跑到写之后volatile 读之后的普通读写不能跑到读之前。这个特性最经典的应用就是单例模式的双重检查锁定instance 不声明为 volatile 时对象初始化的指令可能被重排成先赋值引用再调用构造方法另一个线程可能读到一个半初始化的对象。第三不保证原子性。这就是最容易被误解的边界。i 这类操作在字节码层面包括读 i、把 i 加 1、把结果写回三步volatile 只能保证每一步读到的都是最新值但多个线程可能同时读到旧值、同时加 1、同时写回导致更新丢失。拿一个经典例子来说定义一个 volatile int count100 个线程每个执行 10000 次 count最终结果大概率不是 1000000而是偏小。原因就是读改写三步的竞争。要让 count 正确只能用 synchronized、Lock或者用 AtomicInteger 一类的原子类。volatile 和 synchronized 的选择逻辑可以按这张表理清。对比维度volatilesynchronized保证可见性是是解锁时会刷新主内存保证原子性否是锁区域串行执行保证有序性部分禁止重排是锁的互斥天然有序阻塞线程不会会使用范围只能修饰字段方法、代码块、对象适合 volatile 的场景有作为线程运行状态标志位另一个线程去修改这个标志控制循环作为双重检查锁里的单例引用。不要用 volatile 去保护一个依赖旧值计算新值的复合操作那是原子类的活。顺带说一个冷门但可能被问到的点Java 语言规范规定volatile 的 long 和 double 读写必须是原子的。而对普通 long/double 变量规范允许读写分两次 32 位操作理论上不是原子不过在 x86 平台上实际很少观察到异常但规范层面确实留下了这个口子。5. 异常、泛型、反射三个容易被背对答案耽误的进阶基础题5.1 第八问异常体系梳理与 try-with-resources 的隐藏行为看一眼 Java 的异常体系顶层是 Throwable下面分两支Error 和 Exception。Error 代表 JVM 层面的严重问题程序没有办法也没有义务去恢复StackOverflowError、OutOfMemoryError 都属于这一类。面试官经常问Error 能被 catch 吗从语法上说是可以的catch 了也不会编译报错但捕获之后你能做什么呢OOM 之后去 catch 然后打印一行日志继续跑大概率是继续 OOM程序已经处于不可信状态。所以最佳实践是不要捕获 Error。Exception 下面又要分受检异常和非受检异常。受检异常是编译器强制处理的IOException、SQLException 就是典型方法里可能抛出这类异常时必须写 throws 或者 try-catch。非受检异常主要指 RuntimeException 以及它的子类NullPointerException、ArrayIndexOutOfBoundsException、IllegalArgumentException 都是它们的共同特点是往往由代码 bug 引起编译器不强制处理。套路化的异常处理有几种常见反面案例。第一种是 catch 之后空着异常被吞掉第二种是 catch 住之后只调用e.printStackTrace()日志打了逻辑却没处理上线排查时看到一堆堆栈也定位不到业务上下文第三种是 finally 块里写 return这会直接吞掉 try 或 catch 块里的返回值。资源关闭这块现代代码应该用 try-with-resourcestry (Connection conn getConnection(); PreparedStatement ps conn.prepareStatement(sql)) { ps.executeUpdate(); }它的要求是资源实现 AutoCloseable 接口try 结束后会自动按逆序调用 close。有一个隐藏行为值得知道如果在 try 块里抛了异常而 close 方法又抛了另一个异常默认抛出的主异常是 try 块里的那个close 抛出的异常会被附加为 suppressed 异常。手动在 finally 里关资源的写法不会帮你处理这种双异常场景这也是 try-with-resources 更值得推荐的原因之一。自定义异常继承 RuntimeException 还是 Exception答案要看业务。通常业务校验类、状态非法类的异常建议继承 RuntimeException调用方可以按需捕获不用每个接口都强制声明 throws如果是外部资源相关的失败比如网络不可达、文件读取失败用受检异常会更明确强制调用方考虑失败分支。5.2 第九问泛型擦除和桥方法Java 泛型的历史包袱泛型的表面作用是编译期类型安全和消除强制类型转换。ListString在编译阶段就能拦截往里面塞 Integer 的行为避免了运行时 ClassCastException。但 Java 泛型的实现方式是类型擦除。编译后的字节码里泛型类型参数会被替换为上界默认的上界是 Object。也就是说ArrayListString和ArrayListInteger在运行时是同一个 Class 对象JVM 层面根本没有这两者的区别。为什么 Java 要选这条路径因为 Java 5 才引入泛型而集合框架在 Java 1.2 就已经存在了。为了保持向后兼容让以前的代码编译出来的字节码还能在新 JDK 上运行设计者只能选择在编译期做完类型检查运行时把类型参数擦掉。这和某些现代语言在运行时保留泛型元数据的方案完全不是一回事。类型擦除带来了一系列连锁影响这些都是高频追问点。第一不能创建泛型数组new T[10]直接编译不过。因为运行时 T 已经被擦除为 Object就算允许等于创建了 Object 数组无法保证类型安全。第二泛型类型不能用于 instanceof 判断if (list instanceof ListString)是不合法的。第三泛型类型参数不能用在静态上下文中静态字段不能写static T field原因是静态成员属于类本身而不是某个实例而类的类型参数与实例绑定编译阶段就被擦除了。桥方法也是擦除带来的直接产物。看这个例子public class StringList implements ComparableString { Override public int compareTo(String o) { return 0; } }Comparable 接口在编译后compareTo 的参数类型是 Object而 StringList 只写了一个参数为 String 的方法。为了保证多态成立编译器会生成一个桥方法public int compareTo(Object o) { return compareTo((String) o); }这道桥方法在字节码里真实存在它的名字就叫 bridge。面试里能提到桥方法说明你不是只会背泛型擦除四个字。还有通配符的 PECS 原则。? extends T表示生产者可以用它来读取数据但不能再往里写因为具体类型是不确定的? super T表示消费者可以往里写但读出来的类型只能是 Object。回答类似List 的泛型通配符什么时候用 extends 什么时候用 super时直接套 PECS 就能答顺。5.3 第十问反射破坏封装吗更准确的说法是越过编译期检查反射是 Java 运行时元信息能力的核心入口。通过 Class 对象可以拿到类的字段、方法、构造器可以在运行时创建实例、调用方法、修改字段。一句话概括它让程序能够在运行的时候检查自己。几乎每一类框架都绕不开反射。依赖注入容器启动时会扫描类路径找到需要管理的类通过反射实例化对象并注入依赖对象关系映射框架会根据数据结构定义通过反射读写实体类字段序列化框架需要反射获取对象属性才能转为传输格式测试框架要调用被测类的方法哪怕方法是私有的。反射是否破坏封装是个很好的讨论题。从语言层面讲确实破坏了。调用了setAccessible(true)之后private 字段可以被修改private 方法可以被调用编译期的访问控制墙被绕过了。但更准确的说法是反射绕过的是编译期检查它把访问权限从编译期保障变成了运行时行为。使用反射的程序等于自己承担起了原本由编译器承担的保护责任。这不是一把专门用来攻击的武器而是框架在无法提前知道类结构时不得不依赖的能力。这里要补一个 Java 9 之后的变化模块系统强封装开启后不是所有类都能通过反射访问私有成员的。如果目标模块没有对你 open 或 export反射调用会抛 InaccessibleObjectException。所以反射永远能访问私有成员这个说法从 JDK 9 起就不再成立了。性能方面反射调用确实比直接调用慢主要慢在动态解析、访问检查和参数处理上。不过现代 JVM 会对热点代码做内联优化性能差距在多数业务场景里没那么恐怖。真正需要注意的实践是不要在循环里反复调用Class.forName和clazz.getMethod应该把 Method、Field 对象缓存起来复用。一次反射的元信息获取开销很小重复获取的次数放大到百万级就难看了。反射和泛型也经常被放在一起问。因为泛型信息在运行时被擦除框架如果想知道ListUser里的元素到底是 User 还是其他类型单靠 Class 对象拿不到。解决办法是利用 Type API 和 TypeToken 这类包装方式在运行时捕获完整的泛型类型。理解了擦除 Type 捕获这对矛盾反射和泛型这两块才算真正连起来了。整理完这一期我自己最大的感受是八股文本身不是问题问题在于别把答案背成终点。面试里拉开差距的往往是答案后面的那层所以呢。String 不可变所以能进常量池、能缓存哈希hashCode 和 equals 约定所以 HashMap 才能高效工作泛型擦除所以才有桥方法这些因果关系才是真正的考点。第十四期的题目我也在挑了大概会往并发容器和 JVM 内存方向走到时候继续按这种题目、答案、追问、边界的方式整理出来。