Java面试中那些值得提前梳理的技术要点

关掉浏览器里那篇“Java面试宝典”先问自己一个问题假如此刻面试官让你画一下从.java文件到CPU执行指令的完整路径你能做到哪一步面试官真正想看到的不是你会背多少API而是你有没有在故障现场被虐过。大部分技术要点之所以“值得提前梳理”恰恰是因为它们不是孤立的考点而是你在生产环境里踩坑后沉淀下来的认知。与其临考突击不如把这些要点当作一条脉络重新走一遍Java这门语言赖以生存的核心机制。我们从头说起。人们常把“集合框架”当成背诵题就好像HashMap的默认容量是16、加载因子是0.75记住这些就能过关。可一旦被追问“为什么扩容时阈值是0.75”大多数人会卡住。这个数字是时间与空间的折中太高哈希冲突概率陡增太低空间浪费明显。更进一步HashMap的源码只是一个切口核心是理解哈希。当你意识到扰动函数是为了让高位信息参与低位运算、链表转红黑树是抵抗恶意哈希碰撞的防御手段、扩容时为什么有节点原地不动而有节点变成“原位置原数组长度”时你才算真正敢说你“会用HashMap”。同样ConcurrentHashMap在JDK8抛弃分段锁模型的行为背后是CAS自旋加synchronized锁住链表头节点的权衡。锁粒度的变化、扩容协助机制、ForwardingNode的出现都在告诉你并发容器的迭代演进永远在寻找更好的性价比。顺着并发往上走就绕不开Java内存模型。很多人能背出volatile保证可见性、防止指令重排序却无法解释“为什么DCL单例要加volatile”。答案藏在对象创建的三步指令里分配内存、初始化实例、设置引用指向内存。如果没有内存屏障另一个线程可能拿到一个半初始化的对象。所以并发问题的本质是共享可变状态而不是锁。你真正需要理清的是synchronized在无竞争时通过偏向锁减少CAS开销在激烈竞争时升级为重量级锁的背后是JVM对你的代码行为的自适应补偿。轻量级锁用自旋消耗CPU时间换取阻塞唤醒的系统调用重量级锁则把等待者挂进操作系统的等待队列。明白这套升级路径你才能在“多线程读多写少”和“写多读少”的场景里做出合理的锁选择。除此之外线程池的参数决不是拍脑袋定的核心线程数、最大线程数、队列容量三者之间的配合本质上是线程池的队列长度决定系统的背压能力。如果你只用无界队列那最大线程数就形同虚设。当面试话题转向JVM内存区域许多人习惯把堆、栈、方法区背得滚瓜烂熟却忽略了“对象从生到死”的完整过程。值得提前梳理的不是那些分区名字而是对象头的布局Mark Word里记录了哈希码、GC分代年龄、锁状态标志。为什么64位JVM下对象头是12字节为什么数组对象有额外的4字节长度字段这些细节直接关联到synchronized锁升级的判断逻辑也关联到你在设计超低延迟系统时如何估算内存占用。另一个重点是指针压缩。堆内存小于32GB时JVM会开启压缩oops用32位指针表示原本64位的对象引用代价是对象对齐。看懂GC日志比背诵收集器参数强十倍。当你面对一个Full GC频繁的老年代增长曲线真正的问题往往不是收集器选错了而是你代码里驻扎了不该驻扎的大对象或者ThreadLocal没有在线程归还池之前调用remove()导致内存泄漏被“绑定”在线程上。把内存泄漏的典型模式列出来比记一堆JVM参数更有实战价值。顺着JVM再往深处走你可能觉得类加载机制有点“虚”。但面试官往往会拿“为什么ClassNotFoundException会被NoClassDefFoundError替代”这样的问题来区分背题人和实践者。前者通常出现在classpath缺失或动态加载时而后者是编译期存在但运行期初始化失败比如静态初始化块抛了异常。双亲委派模型不是一种必须死守的教条而是一种安全分工。打破它的是SPI场景比如JDBC驱动当核心类库需要调用外部实现时不得不让线程上下文类加载器去加载。如果你能顺手说出Tomcat的Web应用类加载器为什么要“先加载自己再委派父类”你就已经超越了大多数人。Tomcat需要隔离不同应用的jar包版本同时保证jsp文件修改后能自动卸载重载所以它的加载顺序是倒过来的。理解这层设计哲学比单纯记住“父委托”的三个字更有意义。离开JVMSpring几乎是所有Java项目的基底可面试里最常见的现象是大家把IoC和AOP挂在嘴边却对Spring如何创建Bean的过程语焉不详。你需要自己啃一遍BeanPostProcessor在生命周期里的关键节点而不是靠背题。为什么要理解它因为事务注解失效、AOP代理失效、循环依赖报错这些坑统统指向同一个根因代理的本质是把非业务逻辑从业务代码中抽离而Spring为你创建代理对象的过程是一整套精密的工厂流水线。当你在同一个类里调用this.doTransactional()时调用的不是代理对象而是原始对象事务自然不生效。为什么构造器注入无法解决循环依赖而Setter注入可以因为字段赋值被拆成两步先实例化再注入引用。Spring的三级缓存第三级存放的是“早期暴露的对象工厂”其目标正是为了在并发条件下安全地存放一个尚未完成注入的半成品。你若能把这个流程讲清面试官对你“框架深度”的评价会直接上一个台阶。框架说完了数据库永远是Java后端躲不过的关卡。别只会背“聚簇索引和二级索引”要能画出一个B树的实际结构并解释为什么非主键索引的叶子节点存储的是主键值而不是行记录指针。这样做的第一层好处是减少页分裂时移动数据的代价第二层是让二级索引尽量复用主键索引的物理顺序。索引之所以失效往往是因为你破坏了B树的有序性。对索引列使用函数、隐式类型转换、左模糊匹配本质上都是在让优化器无法进行范围裁剪。还有一个高频深水区是事务隔离级别与MVCC。可重复读为什么不能彻底解决幻读是因为它通过ReadView在普通读上做到了快照隔离但当前读如SELECT ... FOR UPDATE却需要依靠间隙锁来阻止其他事务插入。间隙锁的加锁范围不只针对记录还针对索引间隙——所以MVCC让你在一致性上睁一只眼闭一只眼而间隙锁又强行把眼睛撑开。把握住这两个机制的边界你就不会被“到底有没有解决幻读”这种问题问倒。然后你自然会遇到Redis。缓存是互联网架构的标配但真正值得梳理的是缓存与数据库的一致性方案。为什么“先删缓存再更新数据库”或“先更新数据库再删缓存”都有各自的问题前者在更新数据库之前删掉缓存如果数据库更新失败下一次请求会穿透到数据库并回填旧值后者在更新完数据库后删除缓存如果删除动作失败了缓存里会一直留着旧数据。面试里更愿意听你说出Cache Aside模式的核心前提以数据库为准缓存允许偶尔的不一致但要通过删除缓存来最终收敛。这里还要提一嘴分布式锁。基于Redis的SET NX EX锁在生产中面临的最大麻烦是锁过期时间不好定执行时间超过锁超时时间任务还没写完锁就释放了。于是有了Redisson的看门狗自动续期但Redis分布式锁的坑更像一个概率事件主节点在加锁后、同步到从节点前宕机哨兵把从节点提为主节点原来的锁就丢了。如果你需要极致的正确性不能只靠Redis而要像Redlock那样做到“加锁在多数节点成功”或者在业务层做幂等和版本校验。最后请允许我把话题拉回面试本身。任何技术要点面试官最后都可能包装成一个开放性问题比如“如何设计一个秒杀系统”。这时候前面积累的碎片知识必须被拼装成一个系统图景首先用CDN和浏览器缓存拦截静态请求接着用Nginx做本地限流再用Redis做预扣库存最后用MQ削峰并异步下单数据库里只处理真正落在事务里的订单。但你要知道每一步引入组件都会带来新的可用性问题所以方案里的每个选项都要有失败预案。Redis扣库存成功了但MQ挂了怎么办订单表唯一索引怎么防重复Redis宕机了是否允许降级到本地限流这些问题的背后是你对Java并发、JVM、框架、存储的整合能力。没有一条金句能替代真实推演的深度——把上面这些技术要点梳理成你的认知图谱面试官会看到你带进聊天室的不是题库而是一整套经过调试的思考方式。