1. 从一道最基础的题说起int和Integer为什么年年必考我做了很多年的技术面试面过的人数自己都记不清了。如果让我选一道最常问的开场题一定不是某个复杂的算法而是这么一句看起来谁都会的题目int和Integer有什么区别。为什么拿这道题开场因为这道题太能拉开差距了。初级候选人能答出一个是基本类型一个是包装类型中级的能补一句Java 1.5 之后有自动装箱拆箱但真正理解深入的人会把缓存机制、比较的陷阱、重载时装箱拆箱的坑全部讲透。一道题三句话基本能判断出他平时写代码有没有真的琢磨过底层。先说最基本的定义。int是 Java 八大基本类型之一直接存数值没有对象头不涉及堆内存分配。Integer是int的包装类型本质是一个普通类内部维护了一个int value字段还有一堆工具方法比如parseInt、toString、compare之类。为什么需要Integer因为泛型不支持基本类型集合类存的对象要求非基本类型null 语义也需要一个没有值的状态这时int就无能为力了。1.1 自动装箱拆箱到底做了什么自动装箱拆箱是 Java 1.5 引入的语法糖。所谓语法糖就是编译器在背后帮你转换你写的Integer a 10编译之后实际执行的是Integer.valueOf(10)你写的int b a编译之后执行的是a.intValue()。很多人在这里会犯一个理解上的误区以为自动装箱是编译器顺手帮你调用了构造器。其实不是它调用的固定是valueOf静态工厂方法不是new Integer(10)。这两者有着本质区别——前者会走缓存后者每次都新建对象。这也是下一道连环题的伏笔。顺带说一句new Integer(10)这个写法在现代 Java 中已经被标注过时了静态工厂方法和缓存机制才是正统。我面过一些候选人知道有缓存机制但说不清楚是哪个方法在起作用这就是典型的只知道结论不知道结论是怎么来的。1.2 Integer缓存机制一道追问就出真章面试官问到这里通常会抛出第二连击Integer a 127; Integer b 127; a b的结果是什么Integer c 128; Integer d 128; c d的结果又是什么答案分别是true和false。原因就在Integer.valueOf的源码里public static Integer valueOf(int i) { if (i IntegerCache.low i IntegerCache.high) return IntegerCache.cache[i (-IntegerCache.low)]; return new Integer(i); }默认情况下low是 -128high是 127。在这个区间内的值直接从缓存数组里取所以同一个数值拿到的都是同一个对象比较自然为true。出了这个区间每次都会new一个新对象比较的是引用地址结果为false。这里的进阶考点是high值其实可以通过 JVM 启动参数-XX:AutoBoxCacheMaxsize来调整。情绪缓存机制也不是 Java 独有的Byte、Short、Long都有类似的缓存只不过只有Integer的上限可以动态配置。这些细节不常见但一旦聊到面试官对你的印象就会立刻不一样。1.3 再往深走一层为什么要设计缓存假如我是面试官听到候选人能主动说出缓存节省了对象创建的开销这句话基本就满意了。但如果候选人还能补一句更重要的是小整数在业务代码里出现频率极高频繁装箱产生大量短生命周期对象会加重GC压力缓存机制让大多数装箱操作直接复用对象降低了堆分配频率那这就是加分的点了。顺着这个思路还有一个特别容易踩的坑Integer a 1; Integer b new Integer(1); a b是false。因为一个是缓存里的对象一个是new出来的新对象地址不同。但把换成equals结果又是true因为Integer重写了equals比较的是内部数值。所以我在实际编码中给团队的约定是包装类型之间一律用equals比较基本类型才允许用。这不是严谨不严谨的问题这是代码可读性和可维护性的底线。1.4 String那道题常量池是同一个套路聊完Integer顺势就聊到了String因为它俩在底层机制上高度同源——都是常量池的思路。经典题是这么问的String s1 hello; String s2 hello; String s3 new String(hello); s1 s2 // true都是常量池里的同一个对象 s1 s3 // falses3是new出来的堆对象 s1.equals(s3) // trueequals比较的是字符序列String的常量池是 JVM 方法区现代版本里挪到了堆的字符串常量池中的一块区域编译器会把用双引号写死的字符串放进去下次遇到相同的字面量直接复用。而new String(hello)是运行时在堆上新建对象哪怕内容和常量池一样地址也不同。但是这个版本之后更值得关注的是 JDK 的字符串处理演进字符串是不可变的每次拼接都要创建新对象所以编译器会把s1 s2优化为用StringBuilder来完成。到了 Java 9 之后底层存储又从char[]换成了byte[]目的是为了节省拉丁字符的存储空间。面试题的价值就在这儿——表面是一道题背后牵出来的是 Java 的一整套设计哲学。把Integer缓存和String常量池放一起讲底层逻辑完全一致能复用就复用不能复用才新建。2. 面向对象四题面试官真正想考察的是建模能力面向对象这块的面试题表面上是考语法实际上考的是候选人能不能用对象思维去解构复杂业务。讲真我在面试中其实不太看候选人背了多少设计模式我更在意他能不能把重载重写、多态、抽象类接口这些最基础的概念讲出层次感。2.1 重载和重写一句话讲清楚但讲深了看水平重载和重写有什么区别这道题几乎100%会出现在任何一场 Java 面试里。标准答案是重载是编译期的多态同一个类里方法名相同、参数列表不同重写是运行期的多态子类重新实现父类的方法遵守两同两小一大原则。但真正能拉开差距的是几个刁钻的追问追问一返回值不同能构成重载吗不能。因为重载只要求方法名参数列表不同返回值不参与方法签名。如果你想验证可以尝试void f(int a)和int f(int a)同时存在——编译器直接报错因为调用时无法根据返回类型区分调的是哪个。追问二参数列表是宽类型和窄类型同时存在时调用哪个这是我最喜欢问的一个坑。假设public void method(String s) { ... } public void method(Object o) { ... } method(null);结果调的是String版本。原因是编译器会选择最具体的版本String比Object更具体。但假如再混入Integer重载编译器就会直接报错——null不能区分要转成String还是Integer存在歧义。追问三Override注解有什么用很多初级面试者只会说标注重写。更准确的回答是它是一个编译期检查注解如果你想要重写但方法签名写错了编译器会立刻报错而不是静默地让你写成一个新方法。这是最廉价的重写错误防线。2.2 抽象类和接口别再背单继承多实现了另一道经典面试题是抽象类和接口有什么区别。大多数候选人都会机械地背抽象类是单继承的接口是多实现的抽象类可以有构造器接口不行抽象类的方法可以有方法体接口在 Java 8 之前只能有抽象方法。这些都没错但如果你面试官是我我更想听的是设计层面的思考。抽象类描述的是是什么is-a强调代码复用把共性的字段和方法沉淀在父类接口描述的是能做什么can-do强调行为契约被完全不同的类实现时保证调用方可以统一操作。一个实操中的判断准则如果你要抽出的东西包含状态字段、构造逻辑、公共方法的统一实现用抽象类如果你只需要定义一组行为的规范让不同的类自己去实现用接口。Java 8 之后接口可以写default方法功能性上接口的适用范围扩大了很多甚至可以当抽象类的替代品来用。但默认方法只是便于在不破坏既有实现的前提下扩展接口不是鼓励你把业务逻辑全塞进去。2.3 多态的本质动态分派的底层逻辑多态这东西几乎每个候选人都说懂但解释为什么能多态时能讲到 JVM 指令层面的极少。我通常会把问题落到Father f new Son(); f.method();为什么执行的是Son里的方法实现答案是 JVM 的方法分派机制。Java 的方法调用默认是虚方法调用JVM 在字节码层面用invokevirtual指令触发动态分派运行时根据实际对象类型去查找方法表找到对应的方法入口再执行。而invokestatic静态方法、invokespecial构造方法和私有方法不走动态分派所以静态方法和私有方法是不能重写的。这也是重写父类私有方法这道题的标准解释。这个底层的知识平时写代码没人会在意但一旦你定位线上问题遇到动态代理、字节码增强这类场景不理解动态分派就寸步难行。2.4 构造器这道题为什么子类构造器默认调用super()最后还有一道看似简单实际很能考基础的题子类的构造器发生了什么new Son()时调用的是Son的构造器但构造器第一行如果没有显式写super(...)编译器会自动插入一条super()调用逐级向上初始化父类字段。否则一个对象用到了父类的字段尚未初始化程序根本无法运转。顺着往下还有一个常踩的坑如果父类只有带参构造器没有无参构造器子类编译就会直接失败。候选人在编译器报错之后才去补一行super(参数)说明他之前对这条链路根本没有概念。这题不算难但它考查的是候选人是否理解对象创建时字段装载的先后顺序。再延伸一下——如果类里有实例代码块、静态代码块、构造器顺序是什么答案是静态代码块只在类加载时执行一次实例代码块在构造器之前执行构造器最后执行。我把这个顺序编成了记忆口诀给团队里的新人类加载先静态对象创建先代码块再构造器。真题考过、线上排查用得上值得刻进脑子里。3. 集合框架核心题能从源码讲清楚才是真高手集合框架是 Java 体系里最实用、面试也最卷的一块知识。ArrayList扩容、HashMap的哈希碰撞、红黑树、并发修改异常随便抽一个出来都能问十分钟。这里我会挑几个高频考点把它背后的源码逻辑和业务场景串起来讲。3.1 ArrayList扩容机制16个字说清但分值还在扩容细节ArrayList的底层是Object[]数组扩容机制是面试高频。默认无参构造器创建出来的对象底层数组其实是空数组这个细节极少有人注意第一次add时才会初始化为容量10。之后每加满就扩容为原来的1.5倍也就是oldCapacity (oldCapacity 1)然后把原数组内容Arrays.copyOf到新数组。为什么每次扩容都是1.5倍而不是2倍这里面有取舍。扩容倍数大了扩容次数少但空间浪费多扩容倍数小了空间利用更紧凑但会频繁复制数组。1.5倍是实践中相对均衡的选择。面试官还会追问扩展容量时的拷备对象Arrays.copyOf底层调用的是System.arraycopy这是一个 native 方法会尽可能调用操作系统的内存复制能力深拷贝一层全新的数组然后让ArrayList内部的引用指过去。老数组没了引用交给GC。这个新增容量逻辑里有一个需要注意的边界如果一次性addAll大批量数据按1.5倍规则不够装时会直接扩到需要的最小容量也就是新容量 实际需要的长度。这行逻辑不看源码很容易误判我见过不少候选人以为扩容只会按固定倍数走其实源码里有异常分支处理。3.2 HashMap的put流程一道题串起哈希、碰撞、扩容HashMap是集合框架面试中当之无愧的题型之王。经典问法讲讲HashMap的 put 过程。这个问题如果你能流畅讲清下面的链路基本就过关了先对key调用hashCode()再把高位参与运算得到最终哈希值。为什么要高位异或低位因为桶的索引是(n - 1) hash当数组长度比较小时能参与计算的有效位很少如果直接拿原始哈希值哈希分布会很不均匀。把高位信息播散到低位能减少碰撞。拿到索引后分三种情况桶为空直接放入桶非空且第一个节点就是目标key用equals比较直接覆盖值桶非空且不是目标key则走链表或红黑树的插入逻辑。链表长度达到8且散列表容量达到64时链表转红黑树。如果只是长度到8但容量不到64先触发扩容而不是转树。这些临界条件非常容易被忽略但源码里写得明明白白。再问深一层为什么链表长度是8因为哈希碰撞服从泊松分布在负载因子0.75、随机哈希函数的条件下链表长度到8的概率已经约等于千万分之六非常低了。长度到8意味着哈希函数质量堪忧这时才值得用红黑树来兜底用树化的额外开销换取极端情况下的查询性能。HashMap的容量为什么必须是2的幂次方因为(n - 1) hash的前提是 n 是2的幂这样n - 1的二进制低位全为1散列结果才能完全由 hash 的低位决定且下标一定落在数组范围内。如果你在构造器里传了非2幂次的初始容量JDK 会调用tableSizeFor帮你向上取到最近的幂次方——这个函数用位运算而不是循环几行代码把大于入参的最小2的幂算出来非常精妙。3.3 ConcurrentHashMap演进面试加分项关于并发版本的 Map面试题里常会出现ConcurrentHashMap对比1.7和1.8的区别。1.7用分段锁Segment 继承自 ReentrantLock把数据分段每段一把锁锁的粒度是段级别1.8彻底抛弃了分段锁改用数组桶头节点synchronizedCAS锁粒度细到了桶竞争更小。顺带一个实际开发建议真的追求并发写性能时不要让多线程并发写同一个ConcurrentHashMap的同一个 key那样注定会退化为串行合理设计 key 的分布让写入均匀撒到不同桶上才是利用性能的关键。我在某个项目里见过把用户ID直接做 key 的写法并发高时热点账号所在的桶锁竞争严重后来加了一层业务分桶才缓解。3.4 fail-fast与fail-safe迭代器里的一致性之争ArrayList的迭代器是 fail-fast 的遍历过程中如果结构被修改增删元素会抛出ConcurrentModificationException。底层的实现是迭代器保存了一个expectedModCount每次取下一个元素都会校验modCount有没有被改。这里的陷阱是单线程里边遍历边 remove 也会触发这个异常除非你用的是迭代器自带的remove方法。CopyOnWriteArrayList是 fail-safe 的迭代器操作的是生成迭代器那一刻的快照数组所以遍历过程中其他线程随便改集合都不会抛异常但代价是读取到的数据可能是旧的。这个类的适用场景是读多写少的配置、白名单列表写操作代价高得离谱每次写都复制整个底层数组绝对不能拿它当万能并发容器用。我有一次线上排查服务启动后偶发ConcurrentModificationException日志堆栈指向的是一个定时任务里遍历缓存列表。找人一问发现定时任务一边遍历一边清空列表另一个线程又往里补数据。单线程内明明没有并发但modCount一直在变。最后改成用CopyOnWriteArrayList问题立刻消失。4. 异常机制与并发基础从会用到会答异常和多线程是 Java 基础的另外两大板块。异常题容易考得死但真正好的回答会引入资源管理视角并发题容易考得泛但好的回答会落到 JMM 和关键字背后的语义。这两块放在一起正好是语言特性到工程实践的桥梁。4.1 checked和unchecked为什么Spring的事务默认只回滚RuntimeException异常体系的第一道题通常问的是 checked 和 unchecked 的区别。checked 异常继承Exception但不继承RuntimeException编译器会强制你处理比如IOException、SQLExceptionunchecked 异常继承RuntimeException编译器不检查比如NullPointerException、ArrayIndexOutOfBoundsException。但面试官继续追问为什么很多框架默认只回滚RuntimeException这道题就上价值了。答案的核心是 checked 异常往往代表的是外部环境不确定导致的、业务上可以恢复的问题而RuntimeException代表的是程序逻辑本身出了错误此时让当前事务中止并回滚避免提交半成品数据是最安全的选择。Spring 的事务注解默认只对RuntimeException和Error回滚其实就是遵循这个设计原则。开发实践中我的习惯是业务校验类错误参数不合法、状态冲突用运行时异常抛出因为这类错误本质是代码没做防御要求调用方以后补好文件不存在、网络超时这类不可控的外部问题用 checked 异常强迫调用方显式处理。这样异常的使用边界从设计上就清晰了。4.2 try-finally和try-with-resources资源泄漏的世纪之坑final、finally、finalize三者的区别是 Java 基础面试必考题。final是修饰符修饰类不可继承、修饰方法不可重写、修饰变量不可重新赋值finally是异常处理的兜底块无论是否抛异常都执行finalize是Object里的一个方法GC 在回收对象前会尝试调用它但现代 JVM 里它的执行时机完全不确定已被标记为 deprecated永远不要依赖它来释放资源。try-with-resources才是资源管理的正解。从 Java 7 开始只要类实现了AutoCloseable接口就可以写在try后面的括号里编译器会在完毕或异常后自动调用close()。这比手动在finally里关资源好在哪假设你写了多个资源close自己也抛异常手动代码的异常信息会被吞掉还容易在关闭逻辑中引入新 bug。try-with-resources的编译产物会保留主体异常关闭阶段的异常作为 suppressed 异常附加不会覆盖原始异常信息。我处理过一起线上连接泄漏的问题排查到最后发现是一个老项目里手写了复杂的try-finally层层嵌套某个分支下资源没关。改成try-with-resources后代码量直接砍半连接池告警也消失了。这道面试题本质上是考你有没有被资源泄漏毒打过。4.3 volatile和synchronized并发编程的双生花多线程基础题里volatile和synchronized的区别是绕不开的。标准层面讲volatile保证可见性和有序性不保证原子性synchronized保证原子性、可见性和有序性但会引入线程阻塞和上下文切换成本。volatile的底层实现是插入内存屏障禁止指令重排。经典的保证有序性场景是单例双检锁Double-Checked Locking为什么instance字段必须是volatile因为new Singleton()不是原子操作分配内存、初始化对象、把引用地址赋给变量这三步可能被重排成先赋地址再初始化另一个线程提前拿到未初始化的对象。加上volatile后禁止对这行的重排问题消失。synchronized的底层演进同样是加分点JDK 1.6 之前是重量级锁直接依赖操作系统的互斥量性能很差1.6 之后引入偏向锁、轻量级锁、自旋锁、锁粗化、锁消除等优化。高并发场景下锁竞争激烈时偏向锁会撤销自旋会一直空转浪费 CPU这时该用ReentrantLock的高级特性可中断、可超时、公平锁也要果断切换。4.4 ThreadLocal的内存泄漏一道必问的进阶题ThreadLocal 也是面试高频。核心机制是每个线程持有自己的ThreadLocalMapkey 是 ThreadLocal 对象作为弱引用value 是线程持有的数据。为什么 key 要设计成弱引用因为 ThreadLocal 通常定义在静态字段生命周期很长而线程池里的线程也是长期存活如果 key 是强引用ThreadLocal 对象永远不会释放造成内存泄漏。但加了弱引用也有副作用ThreadLocal 对象被 GC 回收后map 里的 entry 出现 key 为 null 的脏条目value 还留着又构成一条 value 泄漏链。标准解法是用完调用remove()清理或者依赖 get/set 时对 key 为 null 的 entry 做启发式清理。但这都不如主动remove可靠。我在团队里的编码规范里明确了一条接口请求的上下文信息用 ThreadLocal 存但引用过滤器和拦截器里必须显式 remove防止线程池复用线程时上下文串味。这些题刷下来你有没有发现一个规律——真正能拿高分的答题方式从来不是背标准答案而是把每个知识点串成一条能讲出为什么的逻辑链。面试官问到缓存机制你会联想到 JVM 内存分配问到集合扩容你会联想到线上系统的性能调优问到资源关闭你会联想到事故排查的教训。知识之间相互印证你回答的深度和自信度都不一样。我做面试官这么久见过不少基础扎实的候选人他们身上有个共同点答案里永远带着实际踩过的坑和我会怎么调整。这正是我在《Java基础知识面试题大集合》这篇文章里最想传递的思路——不要满足于知道答案而是要成为那个能把答案讲出温度的人。从这道int和Integer开始把每一个知识点都挖掘到能说服自己的程度任何面试都会变成一次很愉快的交流。