做Java开发这些年，我既面试过别人，也被别人面试过。聊到Java基础的时候，我见过太多候选人一听到“八股文”三个字就头疼，然后开始死记硬背，结果面试官多追问一句“为什么”，立刻就卡壳。其实换个角度想，面试官问基础问题，不是为了刁难你，而是想通过这些问题判断你对这门语言的理解深度、代码品味和思维方式。
这篇文章就按面试官视角，把Java基础篇的高频考点一条条拆开。内容覆盖面向对象、数据类型、String、集合框架、异常、泛型反射和Java 8新特性，每个考点我会告诉你面试官到底想听什么、怎么答才能拿高分、哪些坑是你必须避开的。适合正在准备校招或社招的朋友，也适合学完Java基础想系统自查的同学。文章不追求面面俱到，但凡是写进去的，都是真正高频、真正能拉开差距的内容。
1. 先搞清楚：Java基础面试到底在考什么
1.1 面试官为什么要问“八股”
很多人把“八股”理解成背诵，这是最大的误区。我当面试官的时候，问“HashMap原理”这种题，不是真想让你把源码背一遍，而是想通过这道题看三件事：第一，你有没有主动看过源码；第二，你能不能把复杂机制讲清楚；第三，你知不知道这个设计的取舍在哪里。
所以同样一道题，有人答“底层是数组加链表，链表超过8转红黑树”，只能算及格；有人能接着说“为什么转红黑树而不是平衡树，因为红黑树插入删除效率更稳定，为什么是8，因为遵循泊松分布，在负载因子0.75下链表长度达到8的概率极低”，这才是能拿高分的答案。面试官追问题的时候，基本能判断你是背的，还是真的理解。
1.2 基础篇考点的优先级地图
Java基础范围很广，但面试考来考去就是那么几块。我把高频考点按题目类型和优先级整理了一下，方便你有针对性地复习。
| 考点领域 | 核心知识点 | 面试常见问法 | 重要程度 |
|---|---|---|---|
| 面向对象 | 封装、继承、多态、抽象类与接口 | 接口和抽象类的区别是什么 | 极高 |
| String与数据类型 | 字符串常量池、Integer缓存、==与equals | new String("abc")创建几个对象 | 极高 |
| 集合框架 | ArrayList扩容、HashMap原理 | HashMap为什么线程不安全 | 极高 |
| 异常体系 | 受检异常与非受检异常 | Error和Exception有什么区别 | 高 |
| 泛型 | 类型擦除、通配符 | List 能转成List | 中高 |
| 反射 | Class对象、动态代理 | 反射为什么慢 | 中 |
| Java 8新特性 | Lambda、Stream、Optional | 函数式接口是什么 | 中 |
从这张表能看出，面试官更偏爱“概念能理解、源码能展开、实践能举例”的考点。你复习的时候，不要对着知识点清单一条条背，而是自己问自己：如果我是面试官，我会怎么追问？追问之后我能接住吗？
2. 面向对象：“三大特性”怎么答才能拿高分
2.1 封装：从“隐藏数据”说到“契约设计”
封装是面向对象里最基础的概念，但很多人的理解停留在“把属性设成private，提供getter/setter”这个层面。这个回答没错，但太浅了。面试官想听到的是：封装不是为了“隐藏”，而是为了“约束”。
举个例子，你设计一个银行账户类，里面有余额字段。如果你直接暴露public字段，调用方就可以随便把余额改成负数，业务逻辑就废了。但如果你提供deposit和withdraw方法，就可以在方法里做校验，比如余额不能为负、取款金额不能超过余额。这就是封装的本质：把外部对内部状态的直接操作，变成经过你允许的受控操作，保证对象状态永远合法。
我面试的时候特别喜欢追问一句：“你写代码的时候，getter/setter是直接生成的，还是会思考哪些字段需要暴露？”这个问题能筛掉很多只会用IDE的人。真正理解封装的人，会说到不变性、防御性拷贝、尽量暴露行为而不是数据。比如一个订单类，不要暴露status字段的setter，而是提供cancel()、confirm()这样的行为方法，让状态流转被业务规则约束住。
2.2 继承与多态：从方法表到动态分派
继承回答的是“是什么”的关系，多态回答的是“怎么用”的关系。面试中关于多态最常见的一个入门问题是：
class Animal { public void speak() { System.out.println("Animal speak"); } } class Dog extends Animal { @Override public void speak() { System.out.println("Dog bark"); } } Animal a = new Dog(); a.speak(); // 输出 Dog bark答案大家都知道，因为子类重写了父类方法，所以调用的是子类的实现。但如果你能再往下说一层，讲出JVM的动态分派机制，这道题就从“入门”升级成“加分”了。
JVM在类加载的时候，会为每个类生成一个方法表，里面存放了方法签名到实际代码地址的映射。调用虚方法的时候，JVM不是编译期就确定调用哪个方法，而是在运行期根据对象的实际类型去方法表里查找。这就叫动态分派。重载和重写不一样，重载是静态分派，编译期根据参数的静态类型就确定调用哪个方法；重写是动态分派，运行期才确定。很多人把这两个搞混，面试官一问就露馅。
继承这块还有一个高频追问：“继承有什么缺点？”如果你只想到复用，那说明思考还不完整。继承的缺点是破坏了封装，子类依赖父类实现细节，父类一变，子类全崩。所以现在很多规范都强调“组合优于继承”，不是不能用继承，而是能用组合解决的问题，尽量别为了省代码去继承。
2.3 抽象类和接口的选择题
抽象类和接口的区别，是Java面试出镜率最高的问题之一。传统的答案是这样：抽象类可以有构造方法、可以有成员变量、可以有具体方法；接口在Java 8之前只能有抽象方法，Java 8之后可以有default和static方法，Java 9之后还可以有private方法。
但光背区别还不够。面试官更想听的是“你怎么选”。我一般会用一个类比：抽象类像一本半成品图鉴，已经画好了大部分轮廓，留了几页给你补细节；接口像一份契约，规定了你要提供哪些能力，但不关心你怎么实现。
选择上有一条经验：当多个类本质上是同一种东西、只是细节不同时，用抽象类；当多个类本质无关、只是都需要某种能力时，用接口。比如狗和猫都是动物，用抽象类Animal合理；但飞机和鸟都会飞，你不能让它们都继承一个Flyable抽象类，因为两者没有血缘关系，应该定义Flyable接口。
还有一个坑必须提：Java 8之后接口里有了default方法，很多人开始纠结“那我以后用接口还是抽象类”。记住一个原则——接口强调的是能力契约，抽象类强调的是模板复用。另外，为什么Java只支持单继承？这个问题也从侧面理解接口存在的意义：单继承保证类层次足够简单，避免菱形继承的复杂度，而接口可以多实现，既弥补了单继承的不足，又不带来多继承的状态混乱。
3. 数据类型与String，连环追问的“重灾区”
3.1 基本类型和包装类型之间，藏着读源码的起点
Java有8种基本类型：byte、short、int、long、float、double、char、boolean。面试一般不会让你背占用字节数，但你要清楚int是4字节、long是8字节、boolean在JVM规范里没有明确的字节数定义。这些概念虽然基础，却经常被包装进一些奇怪的题目里。
真正高频的是自动装箱拆箱和包装类型的缓存机制。看这段代码：
Integer a = 127; Integer b = 127; Integer c = 128; Integer d = 128; System.out.println(a == b); // true System.out.println(c == d); // false很多初学者第一次看到这个结果会懵。原因是Integer内部有一个缓存数组，默认缓存了-128到127的Integer对象。当你用自动装箱的方式创建Integer时，如果值落在缓存范围内，直接返回缓存里的同一个对象，所以a和b指向同一块地址，==返回true；c和d超过了127，每次装箱都会new一个新对象，==比较的是地址，返回false。
面试官很容易追问：“这个缓存范围能改吗？”答案是可以，通过JVM参数-XX:AutoBoxCacheMax指定，但一般不推荐动。你最好还能说一句“缓存范围为什么是-128到127”，因为这是使用最频繁的数字区间，缓存能有效减少对象创建，提升性能和内存使用效率。能答到这一层，说明你真的研究过，而不是背的结论。
3.2 == 和 equals 的底层逻辑
这个问题基本属于“逢面必考”。==在比较基本类型时比较的是值，在比较引用类型时比较的是引用地址。equals默认来自Object类，内部用的就是==，但很多类会重写它，比如String、Integer。
String的equals重写逻辑值得背一下：先比较引用是否相同，再判断是不是String类型，然后用char[]逐位比较内容。这在源码里就是instanceof判断加循环比较，面试能说出来就已经超过很多人了。
面试官非常喜欢接着问你：“重写equals的时候，为什么必须重写hashCode？”这是有标准答案的：因为对象的hashCode用来定位它在哈希集合中的存储位置。如果两个对象equals相等，hashCode必须相等，否则HashMap中会出现同一个key存在两个不同位置的情况，导致get找不到值。反过来，hashCode相等不代表equals相等，因为存在哈希冲突。这个知识点在集合部分会反复用到，你先把它刻进脑子里。
3.3 String那一串经典题：不可变、常量池、创建几个对象
String不可变性是Java基础里最值得展开的问题。String类用final修饰，底层char[]也用final修饰，一旦赋值就不可改变。这个设计不是拍脑袋，背后有好几层原因。
第一，字符串常量池的复用需要不可变性。只有值不变，多个引用才能安全地共享同一个字符串对象。第二，hashCode可以缓存。String的hashCode经常被用到，如果内容可变，每次计算都要重新算，不可变就可以把哈希值缓存起来提升效率。第三，安全性。String在类加载、网络参数、文件路径等场景中大量使用，如果可变，攻击者就可以通过修改引用内容来绕过校验。第四，线程安全。不可变对象天然是线程安全的，不需要加锁。
new String("abc")创建了几个对象，这也是一个经典问题。这里要区分两种情况：如果常量池中还没有"abc"，那么会创建两个对象，一个是常量池中的字符串对象，一个是堆里的String对象；如果常量池中已经有"abc"了，那就只创建一个堆对象。注意，String s = "abc"这种写法只会在常量池里找或创建字符串对象，不会在堆里新建。
还有一个加分点可以说说字符串拼接的优化。很多人知道“循环里用+拼接字符串性能差，要改用StringBuilder”，但更深一层的是，Java编译器在编译"a" + "b"这种常量拼接时，会直接优化成"ab"；而在变量拼接时，编译器可能会自动帮你new一个StringBuilder来append。所以“+=”在小规模拼接时不一定会出大问题，但循环里反复拼接，每次都生成新的StringBuilder对象和String对象，GC压力就上来了。
3.4 StringBuilder还是StringBuffer？从“线程安全”说起
这两个类常常被拿来对比。StringBuffer是线程安全的，因为它的关键方法都加了synchronized；StringBuilder是线程不安全的，但性能更高。面试官问“你会选哪个”，如果你直接说“并发场景选StringBuffer，单线程选StringBuilder”，那只是及格。
更好的回答是说出一个反常识的实践：绝大多数实际开发场景，包括我见过的大部分项目中，默认都用StringBuilder，哪怕有些方法看起来像“可能被多线程访问”。原因是StringBuffer的线程安全只保证单个方法内部安全，但它保护不了多个方法组合起来的复合操作。举个例子，一个线程先append再toString，另一个线程也在append，两个操作之间是割裂的，StringBuffer并不会保证你拿到的字符串是“某一时刻的完整快照”。所以真正需要线程安全的时候，靠的不是StringBuffer，而是加锁、去局部变量替代、或者用其他并发结构。也就是说，StringBuffer的“安全”是很局限的，代价却是每次都加锁，性能损失实打实。
这个视角一出来，面试官就会觉得你对API的理解是建立在实际场景上的，而不是停留在教科书。
4. 集合框架：HashMap是绕不过去的硬核考点
4.1 聊聊List：ArrayList扩容不是翻倍而是1.5倍
List的面试题集中在ArrayList和LinkedList的区别上，我直接给结论。
ArrayList底层是Object[]，随机访问快，按下标取值是O(1)，但中间插入和删除需要移动元素，是O(n)。LinkedList底层是双向链表，插入删除如果已经定位到节点就是O(1)，但按下标访问是O(n)，因为要向后遍历。实际开发中，绝大多数场景用ArrayList就够了，LinkedList的优势场景非常少。
然后是扩容机制。ArrayList默认初始容量是10，当数组满了，会扩容成原来的1.5倍。这里有个细节：它不是直接乘以1.5，而是通过位运算oldCapacity + (oldCapacity >> 1)实现的，右移一位就是除以2，加起来就是1.5倍。很多人不知道扩容倍数，还有人说是翻倍，这就是扣分点。
为什么是1.5倍而不是2倍？这其实是一个时间和空间的平衡。扩容意味着要创建新数组并把老元素拷贝过去。如果倍数太大，浪费空间；如果倍数太小，比如1.1倍，会导致频繁扩容拷贝，插入性能下降。1.5倍是JDK不断调优出来的折中值。你可以顺着说一句“ArrayList构造时可以指定初始容量，如果能预判数据规模，应该指定一个合理初始容量，避免多次扩容”，这样既有源码细节又有工程经验。
4.2 HashMap核心原理：从数组+链表到红黑树
HashMap是Java面试的“必考之王”，展开讲能讲半小时。我先给一个完整的答题脉络，你照着练就不会乱。
第一步，讲结构。HashMap底层是Node[]数组，每个Node可能是一个链表节点，也可能是一个红黑树节点。所以整体结构是“数组+链表+红黑树”。
第二步，讲put流程。计算key的hash值，这里有一个扰动处理：h = key.hashCode() ^ (h >>> 16)，把高位信息混入低位，降低哈希冲突概率。然后用(n - 1) & hash计算数组下标，因为HashMap容量必须是2的幂，用位运算可以替代取模，效率更高。如果该位置没有元素，直接放入；如果有元素，遍历链表或红黑树，比较key是否相同，相同则覆盖value，不同则尾插到链表末尾或树节点中。链表长度超过8且数组长度达到64时，链表转红黑树。
第三步，讲扩容。当size超过容量 x 负载因子时触发扩容，默认容量16，负载因子0.75，所以到12个元素时扩容。扩容后容量翻倍，元素需要重新散列。这里有个经典问题：为什么Java 8要把头插法改成尾插法？因为在多线程并发put时，头插法会让链表成环，导致get死循环。尾插法能避免这个问题，但多线程下HashMap仍然不是安全的，因为size++的竞态条件照样存在，所以并发场景要用ConcurrentHashMap。
面试官很喜欢问为什么负载因子的默认值是0.75。你可以这样答：负载因子太大，比如1.0，数组利用率高但冲突增多，链表变长，查询效率下降；负载因子太小，比如0.5，冲突少但空间浪费严重。0.75是时间成本和空间成本的折中。还有一道衍生题：为什么链表转红黑树的阈值是8？因为遵循泊松分布，在负载因子0.75的情况下，链表长度达到8的概率只有约千万分之六，这种情况下还出现长链表，说明哈希函数有问题或者key分布极度不均匀，用红黑树来兜底。
4.3 线程安全的集合怎么答
很多人的回答是“用Hashtable或者Collections.synchronizedMap”。这个答案没错，但已经过时了。现在推荐的是ConcurrentHashMap，你应该把这个变化讲清楚。
Hashtable的做法是在put和get等整个方法上加上synchronized，相当于给整张表加了一把大锁，并发度极低。Collections.synchronizedMap也是一样，只不过换了个壳，本质还是全表锁。ConcurrentHashMap在Java 7里用分段锁，把表分成一段一段的，不同的段可以并发操作；Java 8放弃了分段锁，改用CAS + synchronized，锁的粒度细化到单个桶位。这个演进过程就是Java并发性能优化的缩影，你能把1.7和1.8的差异讲出来，面试官会非常满意。
还有一个加分项：CopyOnWriteArrayList。它适用于“读多写少”的场景，读的时候不加锁，写的时候复制一份新数组再修改，然后让引用指向新数组。听起来很粗暴，但确实有效，代价是写操作有复制成本，不适合频繁写的场景。你能讲出“什么场景下选什么集合”，说明你是有工程判断力的。
5. 异常、泛型与反射：这些基础考点最容易“翻车”
5.1 异常体系：受检异常和非受检异常怎么区分
异常的继承结构不难记。Throwable是所有异常和错误的父类，下面有两个子类：Error和Exception。Error表示JVM层面的严重错误，比如OutOfMemoryError、StackOverflowError，程序一般无法也不应该处理。Exception下面又分两类：受检异常（Checked Exception）和非受检异常（RuntimeException及其子类）。受检异常在编译期强制要求处理，要么try-catch要么throws，比如IOException、SQLException；非受检异常不强制处理，比如NullPointerException、ArrayIndexOutOfBoundsException、ClassCastException。
面试官喜欢问“你平时怎么处理异常”，这个问题其实没有标准答案，但有高下之分。低分回答是“都用try-catch包起来”。高分回答是结合自己的项目说明：对需要调用方感知并处理的业务异常，用受检异常或自定义异常；对程序bug导致的运行时异常，不该去catch，应该让它暴露出来，配合日志定位问题。另外，尽量不要catch了Exception后什么都不做，这会掩盖问题。
try-with-resources也是高频考点。它是在Java 7引入的，实现了AutoCloseable的资源类可以在try块结束后自动关闭。这个机制比手动在finally里close要安全得多，因为finally里的close如果有异常，可能把之前的业务异常覆盖掉，而try-with-resources可以保留主异常，关闭异常作为被抑制的异常附加。你多讲这一层，面试官就知道你是有实战经验的。
5.2 泛型：擦除之后还能做什么
泛型是Java基础里比较烧脑的部分。一句话概括：Java的泛型是编译期概念，运行时会进行类型擦除。List<String>和List<Integer>在运行时的Class对象都是ArrayList.class，元素类型信息在字节码里被擦除成Object或边界类型。
为什么Java采用类型擦除而不是像C++那样生成不同的类型？因为要向后兼容。Java 5引入泛型时，已经存在大量未使用泛型的旧代码和类库，为了保证旧代码能继续运行，只能在编译期做类型检查，运行期擦除类型信息。这个设计的代价是泛型在运行时无法获取具体的类型，所以你不能new T()，也不能T.class。
面试真题：List<String>能赋值给List<Object>吗？不能，因为List 不是List
关于通配符，记住PECS原则就够了：? extends T用于读操作，称为Producer，因为只能往外取T；? super T用于写操作，称为Consumer，因为可以往里放T。举个实际例子，List<? extends Number>可以读，但不能add任何元素（除了null），因为你不知道实际列表里存的具体是Integer还是Double；List<? super Integer>可以add Integer，但读出来只能当Object处理。能把这个原则讲清楚，面试官一般不会继续为难你。
5.3 反射：用在哪里，以及性能为什么慢
反射是Java动态性的基础，面试中通常结合框架来考。获取Class对象有三种方式：类名.class、对象.getClass()、Class.forName("全限定类名")。
反射的典型应用场景我列几个：Spring的IoC容器运行时通过反射创建Bean实例，Spring MVC通过反射把请求参数绑定到方法参数上，MyBatis通过反射把数据库结果集映射成实体对象，还有JUnit动态调用测试方法。框架之所以要用反射，是因为框架在写代码时根本不知道你会定义什么类，只能在运行期根据配置或注解动态加载和调用。
面试官考“反射为什么慢”，你不要只说一句“因为动态解析”。可以拆成几点：第一，反射调用方法时，JVM无法在编译期做方法内联等优化；第二，每次调用都要进行安全检查，比如访问权限校验；第三，反射API通过方法名查找Method对象，涉及字符串匹配和方法表查，比直接调用慢得多。这也是为什么Spring在大量使用反射的场景里会做缓存和优化，比如缓存Method对象，或者用CGLIB生成代理类来替代反射调用。
一个很重要的加分细节：method.setAccessible(true)可以跳过访问权限检查，确实能显著提升反射速度。但要注意，在JDK 17之后，强封装模式下，非法反射访问会抛InaccessibleObjectException，你需要在启动参数里加--add-opens才能访问jdk内部API。这样既能体现你对反射原理的理解，也能体现你对JDK版本演进的关注。
6. Java 8新特性：基础面试的“加分板块”
6.1 Lambda表达式：从匿名类到函数式接口
Java 8引入了Lambda表达式，本质上是匿名类的简化写法，但它不是单纯的语法糖。它的底层是通过invokedynamic指令实现的，这个细节如果你能说出来，面试官会眼前一亮。
Lambda表达式的类型是函数式接口，就是只有一个抽象方法的接口，用@FunctionalInterface注解标注。比如Runnable、Comparator、Callable。下面是个最简单的例子：
// 匿名类写法 Runnable r1 = new Runnable() { @Override public void run() { System.out.println("hello"); } }; // Lambda写法 Runnable r2 = () -> System.out.println("hello");Lambda还有一个隐藏考点：捕获和非捕获。非捕获Lambda指的是Lambda体里没有引用外部变量，JVM可以创建同一个实例并复用，相当于单例；捕获Lambda指的是Lambda体里引用了外部局部变量，这个变量必须是final或事实上final，每次调用时可能创建新实例。你可以顺手解释“为什么Lambda引用的局部变量必须是final的”——因为Java的Lambda捕获的其实是变量的值副本，而不是变量本身，如果这个变量还能被修改，副本和原值就会不一致，容易产生歧义。
6.2 Stream API：优雅但别过度封装
Stream是Java 8带来的集合处理利器。它的核心特点是流水线和惰性求值。Stream操作分中间操作和终端操作，中间操作比如filter、map、sorted，它们不会立即执行，只是把操作记录下来；终端操作比如collect、forEach、reduce一调用，整条流水线才开始执行。你可以类比成做菜的菜谱：先列出步骤，真正开火才一步步执行。
面试题喜欢考“Stream和for循环哪个性能好”。诚实地说，简单场景下for循环通常比Stream快一点点，因为Stream有额外的抽象开销；但整体差距在现代JIT优化下已经很小。真正的优势在于：Stream表达的是“做什么”而不是“怎么做”，代码可读性更高、更不易出错。对绝大多数业务场景来说，可维护性的收益远大于那微小的性能损失。
并行流也是考点。parallelStream()用的是ForkJoinPool公共线程池，并行处理时如果任务里有共享可变状态或者涉及阻塞IO，很容易出问题。同时并行流适合“元素之间无依赖、计算密集”的场景，不适合有状态操作或者线程不安全的集合。我见过有人用parallelStream处理数据库查询，结果把连接池打崩了，所以别盲目用并行。
6.3 Optional：用对了是糖，用错了是毒药
Optional是Java 8用来解决空指针问题的类。它的设计初衷是让你在返回值上明确表达“这个值可能为空”，倒逼调用方去处理空的情况。
但实际开发中对Optional的误用非常严重。常见错误是把Optional当成一个随时可以包裹的箱子，每个字段都包一层；或者把Optional作为方法参数传进来。这两者都是反模式。Optional本身是一个持有对象的容器，并不是为了替代所有判空场景而生的。
我总结一下正确的使用姿势：第一，作为返回值类型使用，比如Optional<User> findById(Long id)，比返回null更安全，调用方必须显式处理“没找到”的情况。第二，配合orElse、orElseGet、orElseThrow使用，比如user.orElseThrow(() -> new UserNotFoundException(id))。第三，字段里不要用Optional，因为Optional没有实现Serializable，在实体类里用它反而浪费。能用null表示“不存在”的普通字段，就不要硬套Optional。
此外，orElse和orElseGet有个经典坑：orElse(T other)无论Optional是否为空，都会计算other这个对象；orElseGet(Supplier)只在值为空时才执行Supplier。如果orElse里的对象创建代价很大，比如查数据库或构建默认对象，这里就浪费了。你以为你写了优雅的判空，其实可能每调用一次都白做一次无用功。
7. 实战经验：答题框架、常见坑与备考建议
7.1 答题思路：是什么-为什么-怎么做-有什么坑
面试答题确实有套路，但不是死板的模板，而是一种表达结构。我推荐“是什么-为什么-怎么做-有什么坑”四层递进，正好对应面试官的四个期望层次。
拿一个高频题举例：“说一下HashMap”。低分回答是上来就讲源码，讲完就结束。高分回答是：先一句话说清“HashMap是基于哈希表的Map实现，用于存储键值对”，然后讲为什么用哈希（为了实现O(1)的查找），再讲怎么做（数组+链表+红黑树，put流程，扩容机制），最后讲坑（线程不安全，并发下用ConcurrentHashMap）。你会发现，这个结构天然地把你的知识串联了起来，而且形成了一种“我能清楚地表达自己的思考过程”的观感。
这个方法也适用于其他问题，比如“说一说你对Spring IoC的理解”：是什么（IoC是控制反转，把对象创建和管理交给容器）——为什么（解耦，对象不再自己new依赖，而是声明依赖由容器注入）——怎么做（容器扫描配置或注解，通过反射创建Bean，管理生命周期）——有什么坑（循环依赖、作用域选错、Bean初始化顺序问题）。
7.2 这些“八股”表面的坑，你踩过几个
我在面试中经常遇到一些看似很小但很致命的回答错误，统一列出来，你自查一下。
第一个坑，把ArrayList扩容说成“翻倍”。正确答案是1.5倍，进位运算是oldCapacity + (oldCapacity >> 1)。
第二个坑，说HashMap初始容量是16、负载因子是0.75就没下文了。你要补上：初始容量可以指定，而且扩容阈值是capacity * loadFactor，不光是16和0.75两个数。
第三个坑，把StringBuffer说得比StringBuilder更好。如果你只说“StringBuffer线程安全所以更好”，面试官基本就断定你缺乏工程实践。更好的说法是StringBuffer的安全性很局限，实际开发中StringBuilder才是默认选择。
第四个坑，分不清编译期和运行期。比如“泛型在运行期会检查类型”是错的，这是编译期；“反射在编译期就能确定调用方法”是错的，这是运行期。所有涉及“时期”的表述都要格外小心。
第五个坑，回答概念时只背结论不给例子。你说“接口是对行为的抽象”，面试官听了毫无感觉；如果你补一句“比如Sortable接口声明排序能力，具体是升序还是降序由实现类决定”，就立体多了。好的答案是概念+例子+场景，三合一。
7.3 备考建议：写Demo、讲给别人听、整理自己的八股本
最后分享几个我亲测有效的备考方法。
第一，把每个考点写成一个可运行的Demo。比如Integer缓存，就写一段代码打出来验证；HashMap的put流程，就写个继承重写hashCode的类，故意制造哈希冲突，看看链表怎么生成的。动手验证过的知识，记得比看十遍资料都牢。
第二，用“讲给别人听”的方式复习。我备考的时候，会把每个知识点讲给同事听，或者对着录音机自己讲一遍。讲着讲着就发现哪里卡壳了，卡壳的地方就是你的薄弱点。能用自己的话讲明白，才是真的明白了。
第三，维护一份自己的“八股本”。不要抄别人的面试题合集，而是基于你的复习过程，把每道题按“我的答案”和“可能的追问”两个维度整理出来。这份东西在面试前快速翻阅，效果远好于临时抱佛脚。
最后再说一个小技巧。面试官问完你一个问题，如果还有余力，可以主动说“这个点其实和XX是相关的，需要我展开吗”。这一句话既展示了知识网络，又把对话引导到你熟悉的方向，很多候选人就是靠这个动作拿到加分的。
Java基础的内容说多不多，说少不少。我见过太多人在“八股”面前栽跟头，本质上不是他们不努力，而是努力的方向错了——光背结论不追原理，光看文章不动手验证。如果你能把这篇文章里提到的每个考点都用“是什么-为什么-怎么做-有什么坑”这条线串起来，再配合Demo验证，面试官问到你的时候，你会发现自己比大多数候选人答得深一截。
)
