Java面试真题集锦：从HashMap到JVM与并发编程的体系化备战指南

每年到了二三月份和九十月牛客网上就像赶大集一样热闹各种Java面经满天飞有人刷题刷到凌晨三点有人拿着 offer 在帖子里报喜。我从几年前开始招人这几年陆陆续续面过了两三百个候选人也帮朋友改过不少简历、模拟过面试。我越来越觉得Java 面试这个东西表面上考的是“八股文”实际上考的是一个候选人能不能把知识串成体系。背答案只能帮你撑过一面撑不过深入追问。这份“牛客网精选 Java 面试真题集锦”不是把网上那些问题原样抄一遍而是从我实际面试候选人的记录里把出现频率最高、区分度最强、最能暴露水平的题目挑出来给出参考答案并且告诉你面试官为什么爱问这道题背后想考察什么。你可以直接拿它来背但我更建议你把它当成查漏补缺的清单把它读厚再把它读薄。1. Java 基础与集合框架最容易被“问穿”的底盘很多人觉得 Java 基础简单不需要复习结果一开口就露馅。基础题恰恰是面试官判断你“科班功底”的最快方式也是牛客网面经里出现频率最高的一类题。这一部分我不讲太泛的概念只挑那些一问一个准、追问两三下就有人翻车的题目。1.1 、equals 和 hashCode 的关系到底怎么答才算答全这题基本上属于“必考题中的必考题”但大多数人答不完整。很多人张口就背“比较的是地址equals比较的是内容”这个说法不是全错但很业余。完整的回答应该分三层。第一层在基本数据类型上比较的是数值在引用类型上比较的是引用地址这是 JVM 层面就规定好的行为。第二层Object 默认的 equals 方法就是用 实现的所以如果你没有重写 equals那它和 没有任何区别。第三层重写 equals 时必须重写 hashCode这是为了遵守“相等对象必须有相等哈希值”这个约定否则你辛辛苦苦重写 equals结果把对象往 HashMap 里一放因为 hashCode 不一样equals 根本没机会被调用。面试官接下来大概率会追问“为什么 HashMap 里 hashCode 不同的对象一定不会相等”这就涉及到 HashMap 的哈希过程了。在 JDK 8 里key 的 hashCode 会通过(h key.hashCode()) ^ (h 16)做一次扰动然后(n - 1) hash决定落在哪个桶。如果两个对象 equals 相等但 hashCode 不等它们就会分配到不同的桶HashMap 会认为它们是两个不同的 key导致你 get 的时候取不到值甚至出现数据“重复存储”的诡异现象。我给你一个面试中能加分的回答方式先讲清楚三者的语法层面再主动提一嘴“在实际开发中用 Lombok 的 Data 会自动帮我重写 equals 和 hashCode所以我很少手写但我清楚它重写的逻辑是基于所有非 transient 字段。”面试官一听就知道你不是死背答案而是真的写过代码。1.2 HashMap 的底层原理、扩容机制与线程安全问题HashMap 是集合框架里的“题眼”没有之一。我从候选人嘴里听过无数个版本的“数组加链表”但能解释清楚以下四个细节的人不超过两成。第一为什么 JDK 8 要把链表转红黑树的阈值设为 8很多人直接背“链表长度超过8转红黑树”这是对的但你要说出背后的泊松分布。在负载因子 0.75、随机哈希的理想情况下链表长度达到 8 的概率是亿分之六几乎不可能发生。所以阈值设成 8是概率统计的结果而不是随便拍脑袋定的。第二扩容过程JDK 7 和 JDK 8 有什么区别JDK 7 是先判断是否要扩容、再插入新元素头插法并发环境下可能形成环形链表导致死循环。JDK 8 改为尾插法先插入再扩容。这里建议主动补充一句“JDK 8 的尾插法虽然解决了一部分死循环问题但 HashMap 本身就不是线程安全的并发场景一定要用 ConcurrentHashMap。”第三扩容时节点会不会重新 hash很多人会答错。实际上JDK 8 的扩容利用了元素在新数组中的索引要么在原来位置、要么在“原索引 旧容量”的位置这个规律通过e.hash oldCap来判断避免了重新计算每个元素的 hash 值这是性能优化的一个关键点。这就是网上经常讲的“数据迁移”时用高低位拆分。第四为什么容量总是 2 的 n 次幂因为(n - 1) hash在 n 是 2 的幂次方时等价于hash % n但位运算比取模快得多。这个细节我建议你在回答里主动说出来因为它能串起 hash 算法、寻址方式、扩容机制一整条线。我招人的时候如果候选人能把 HashMap 讲到这个深度我基本会认为他的集合基础是过关的。这道题就是典型的“一分钟答完和十分钟答完区别不在于背得多熟而在于理解得多深”。1.3 ArrayList、LinkedList、Vector 的对比与真实使用场景这道题也是牛客网的高频题但它的难点不在于“背区别”而在于“说出场景”。我每次问完区别都会追加一句“你项目里用的哪个为什么”标准答案大家都熟ArrayList 底层是 Object 数组随机访问快插入删除慢除非在尾部LinkedList 底层是双向链表插入删除快随机访问慢Vector 是线程安全的但方法级 synchronized 导致性能差已经被官方标注为不建议使用了。但真实场景是什么我的观点很直接绝大多数业务开发场景直接用 ArrayList 就够了。LinkedList 的“插入删除快”是有前提的它说的是在已知节点位置的情况下插入删除而如果你要遍历链表找到那个位置时间复杂度就是 O(n)整体算下来未必比 ArrayList 快。再加上 LinkedList 的每个节点需要额外存储前后指针内存占用更大CPU 缓存不友好实际性能常常不如预期。所以如果有人跟我说他的项目里用了 LinkedList我大概率会追问他是怎么判断“这里需要频繁插入”的。如果他说“因为我要在列表中间插入数据”我会继续问“你的插入操作用的什么接口、怎么定位到插入位置的”。面试官要的从来不是只有一个结论而是完整的推理过程。提示遇到集合相关的题记住一个回答框架——“数据结构 底层实现 时间/空间复杂度 线程安全性 适用场景 项目类比”把六个维度讲全这题基本就是满分回答。2. JVM 内存模型与垃圾回收考察“内功”的试金石JVM 是 Java 面试里最难“临时抱佛脚”的部分也是区分初级和中高级程序员的分水岭。如果候选人能把 JVM 讲得条理清晰我基本能断定他看过源码或者至少认真读过《深入理解 Java 虚拟机》。这一节我挑三道最经典、最能拉开差距的题。2.1 运行时数据区域哪些是线程私有哪些是线程共享这道题在牛客网上被问到的频率极高而且经常被放在 JVM 系列的第一问。标准答案不难难的是完整。线程私有区域有三个程序计数器、虚拟机栈、本地方法栈。程序计数器是当前线程执行字节码的行号指示器如果执行的是 native 方法它的值是 undefined。虚拟机栈就是通常说的“Java 栈”每调用一个方法就会创建一个栈帧栈帧里包含局部变量表、操作数栈、动态链接、方法出口。局部变量表里存的是八种基本数据类型和引用类型容量单位是槽Slotlong 和 double 占两个槽这个细节也常被追问。线程共享区域有两个堆和方法区。堆是对象实例分配内存的主要区域也是垃圾回收的主战场。方法区在 JDK 8 里被实现了“元空间Metaspace”取代了之前的永久代。这里我最常追问的是“为什么要用元空间替代永久代”答案是永久代的容量上限很难设置而且调优困难元空间直接使用本地内存默认情况下只受物理内存限制可以避免频繁的 OOM。还有两块经常被忽略的直接内存和运行时常量池。直接内存不在 JVM 运行时数据区里但它由 NIO 使用如果忽略了它在排查 OOM 时会漏掉一个方向。运行时常量池在 JDK 7 之后从永久代挪到了堆里String.intern() 的行为也受这个变化影响。如果候选人能主动提到这两个点我会觉得他的知识结构非常完整。2.2 垃圾回收算法与常见收集器组合这道题我喜欢从“如何判断对象已死”开始问。答案有两个引用计数法和可达性分析。引用计数法有个著名的循环引用问题所以主流 JVM 用的是可达性分析。从 GC Roots 出发沿着引用链走走不到的就可以回收。GC Roots 包括虚拟机栈中引用的对象、静态属性引用的对象、常量引用的对象、本地方法栈中 JNI 引用的对象。接下来是三种经典算法标记-清除、标记-复制、标记-整理。标记-清除有碎片问题标记-复制牺牲部分内存空间适用于新生代因为对象存活率低标记-整理适用于老年代因为对象存活率高移动对象成本高但能避免碎片。说到这里几乎必然要落到分代收集和具体收集器。我的回答建议是先画出一条时间线JDK 8 默认的收集器组合是 Parallel Scavenge新生代 Parallel Old老年代JDK 9 之后 G1 成为默认。G1 的设计理念是“面向局部收集”把堆划分成多个大小相等的 Region维护一个优先列表优先回收价值最大的 Region。面试官如果再往下问大概率会提到 CMS。你要知道 CMS 的全称是 Concurrent Mark Sweep它的主要问题是并发阶段占用 CPU 资源、浮动垃圾、内存碎片以及最后的“Concurrent Mode Failure”需要退化为 Serial Old 进行 Full GC。G1 在 JDK 9 之后取代 CMS正是因为它能在可控的停顿时间下完成垃圾回收并且能处理大对象Humongous Object大于 Region 一半的对象会直接分配在连续 Region 中。提示面试中谈 JVM 时先答“是什么”再答“为什么”最后一定落到“实际中怎么用”。比如你可以补充一句“我在项目里排查过 CPU 飙升问题最后通过 jstat 看到 FGC 频繁dump 堆后定位到某个静态集合没有清理导致对象无法回收。”这类真实场景是最能加分的。2.3 类加载机制双亲委派模型与打破它的场景类加载机制也是高频考点但很多人只记得“双亲委派”四个字一问“为什么要这样做”就卡住。完整回答应该这样组织类加载分为加载、验证、准备、解析、初始化五个阶段。加载阶段通过类的全限定名获取二进制字节流验证阶段确保字节流符合 JVM 规范准备阶段为静态变量分配内存并设置零值解析阶段把符号引用替换为直接引用初始化阶段执行类构造器clinit方法。双亲委派模型是指当一个类加载器收到加载请求时它不会自己先尝试加载而是先把请求委派给父类加载器层层向上直到启动类加载器。只有当父类加载器无法完成加载时子类加载器才会自己去加载。这样做的核心目的是防止核心 API 被篡改。你想想如果你自己写一个 java.lang.String 类没有双亲委派的话它就可能被加载进来那整个 JVM 的字符串逻辑就全乱了。面试官一旦追问“你遇到过需要打破双亲委派的情况吗”这道题的难度就飙升了。常见的打破场景有三个JDBC 使用 SPI 机制由启动类加载器加载 DriverManager但真正加载数据库驱动时却需要线程上下文类加载器Tomcat 为了实现 Web 应用之间的类隔离创建了 WebAppClassLoader优先加载自己应用下的类OSGi 和 Java 9 的模块系统逻辑更复杂。我的建议是你不需要把三个场景全部讲得很深挑一个讲透就行。绝大多数候选人连“SPI 为什么要打破双亲委派”都说不清楚你能讲明白 JDBC 这一个场景就已经超过 90% 的竞争者了。3. 并发编程互联网大厂面试的“分水岭”并发编程是 Java 后端面试里最硬核的部分没有之一。你背熟 synchronized 和 volatile 的区别只是入门真正的分水岭在于能不能讲清楚它们的底层原理、内存屏障、以及如何用 JUC 工具解决实际问题。这一节的题目每一道我都亲眼见过候选人从自信满满到沉默不语。3.1 synchronized 和 volatile 的底层原理别再说“一个锁对象一个锁变量”很多人在回答这道题时会说“synchronized 是悲观锁volatile 是轻量级锁一个可以保证原子性一个不能保证。”这是结论没错但没有触及原理面试官一定会继续追问。volatile 的本质是内存屏障。它有两个语义一个是可见性写 volatile 变量时会强制把工作内存中的值刷新到主内存另一个是禁止指令重排序。但要记住它不能保证原子性经典案例就是多线程对 volatile 的 int 变量做count结果一定小于预期值因为这个操作不是原子的。synchronized 在 JDK 6 之后经历了锁升级过程无锁 - 偏向锁 - 轻量级锁 - 重量级锁。偏向锁是同一个线程多次获取锁时只需要做一个 CAS 操作记录线程 ID轻量级锁是多个线程交替获取锁时通过 CAS 和自旋来避免阻塞只有竞争激烈时才会升级为重量级锁即操作系统的互斥量。我还建议你主动补充锁升级是不可逆的不能从重量级锁降回偏向锁。面试官特别喜欢追问一句“synchronized 在字节码层面是什么意思”你要记住它对应的是 monitorenter 和 monitorexit 两条指令monitorexit 会有多条为了保证异常时也能释放锁。再往上追问就是监视器锁Monitor这个概念每个对象头里都有一个 Monitor 关联这里可以提一下对象头里 Mark Word 存储了锁的状态信息。提示回答并发题目时强烈建议用“现象 - 原理 - 底层指令 - 实际使用”的四层结构。比如你在项目里用的 ReentrantLock可以从 AQS 的 state 变量和 CLH 队列出发解释为什么它能实现公平锁和非公平锁。能讲到这个层级面试官基本不会再用八股题难为你。3.2 线程池的核心参数与拒绝策略从源码层面讲透线程池这块牛客网上常问的题目是“线程池有哪些参数”但真正拉开差距的是“一个任务提交后线程池内部的执行顺序到底是什么”。我把这个顺序说一遍你跟着走一遍就理解了。任务提交到 ThreadPoolExecutor 后第一步判断核心线程池是否已满没满就创建核心线程执行任务满了之后第二步判断阻塞队列是否已满没满就把任务放入队列队列也满了第三步判断线程池是否已达到最大线程数没达到就创建非核心线程执行任务如果连最大线程数都达到了就走拒绝策略。这个流程很多人背得下来但会忽略一个关键细节队列是满的然后先创建非核心线程还是先拒绝答案是先创建非核心线程。这个顺序会影响你对业务系统的设计判断因为核心线程数、队列大小、最大线程数三个参数其实是在“响应速度”和“资源消耗”之间做权衡。然后是四种拒绝策略AbortPolicy 直接抛异常CallerRunsPolicy 让调用者线程执行该任务DiscardPolicy 直接丢弃DiscardOldestPolicy 丢弃队列里最旧的任务并重新提交当前任务。我面试时还会追问“实际项目中你会用哪一种”我的答案是用自定义的拒绝策略捕获任务信息并写入 MQ 或日志文件等待补偿机制重试而不是直接丢给默认策略。另外我提醒一个很多人会踩的坑不要用 Executors 提供的固定线程池因为 newFixedThreadPool 的阻塞队列是 LinkedBlockingQueue默认容量是 Integer.MAX_VALUE相当于无界队列。如果任务堆积过多可能导致 OOM。用 ThreadPoolExecutor 手动参数去创建你才能真正掌控行为。3.3 从源码角度看 ConcurrentHashMap 的并发控制演进这道题之所以高频是因为它串联了集合、并发、JMM 三个知识域而且它分版本JDK 7 和 JDK 8 差别巨大。JDK 7 的 ConcurrentHashMap 用的是分段锁Segment机制默认 16 个 Segment每个 Segment 内部是一个小 HashMap锁的粒度是 Segment 级别。理论上最多支持 16 个线程同时并发写入但锁竞争分散了不会所有线程都堵在一个锁上。JDK 8 就完全重写了去掉了分段锁改用 CAS synchronized 锁住桶的头节点。写入流程是如果桶为空用 CAS 将这个 Node 插入桶中这是无锁操作如果桶不为空就用 synchronized 锁住桶的首节点然后执行插入。这样锁的粒度从 Segment 精细到了单个桶并发度更高。同时你最好能提到 size() 方法的实现变化JDK 8 的 size() 在竞争不激烈时直接累加 baseCount竞争激烈时会用 CounterCell 数组分段计数把计数压力分散到多个单元格上最后把 baseCount 和各单元格的值相加。能讲出这一步想不被记住都难。4. Spring 与常用框架项目经验考察的主阵地从这一节开始题目不再只是“知识记忆”而是考察你是不是真的用过这些框架是不是只停留在调用层面。Spring 几乎是每一份 Java 后端简历的标配所以面试官在这块的追问往往会非常狠。4.1 Spring Bean 的生命周期以及三级缓存如何解决循环依赖先问基础Spring Bean 的生命周期分几步大致可以概括为实例化、属性填充、初始化、使用、销毁。但如果只答到这个程度面试官不会满意。你要能说清楚在初始化阶段里还有 BeanNameAware、BeanFactoryAware、ApplicationContextAware 的回调以及 BeanPostProcessor 的 postProcessBeforeInitialization 和 postProcessAfterInitialization 方法还有 InitializingBean 的 afterPropertiesSet 方法和自定义的 init-method 方法之间的执行顺序。接下来必然追问循环依赖。所谓循环依赖就是 A 依赖 BB 依赖 A如果直接创建 AA 需要注入 BB 需要注入 A互相等待形成死锁。Spring 用三级缓存解决这个问题一级缓存singletonObjects存放完整的单例 Bean二级缓存earlySingletonObjects存放早期的、尚未完成属性填充的 Bean三级缓存singletonFactories存放单例工厂。当 A 创建时发现需要注入 B会提前把 A 的 ObjectFactory 放入三级缓存然后去创建 B。B 创建时发现需要注入 A会从三级缓存拿到 A 的工厂生成一个早期引用注入到 B 中。B 完成创建后A 再继续完成自己的注入。我要提醒一个高频追问点为什么需要三级缓存两级不行吗 答案在于如果一个 Bean 被 AOP 代理三级缓存里的工厂需要判断是否生成代理对象。二级缓存存的是“早期引用”如果在 B 注入 A 的时候A 已经被代理了那就需要让 B 拿到的是代理后的 A。三级缓存把生成代理的时机延后到了“真正需要引用”的时候确保能拿到正确的对象。这是很多人忽略的关键。4.2 Spring 事务传播机制与事务失效的经典场景事务传播机制是必考题七种传播行为不必全背但至少要把最常用的几种说清楚。REQUIRED 是默认的如果当前没有事务就新建事务有事务就加入当前事务REQUIRES_NEW 是挂起当前事务新建一个独立事务NESTED 是嵌套事务利用数据库的 Savepoint 实现部分回滚SUPPORTS 是有事务就加入没有就以非事务方式运行。比传播机制更重要的是“事务为什么失效”。我把实际开发中最常见的失效原因整理成了一张清单你可以对着自查失效场景原因方法被 private 修饰Spring 事务基于动态代理private 方法无法被代理方法在同一个类内部调用走的是 this 引用没有经过代理对象异常被 catch 后没有重新抛出事务感知不到异常自然不会回滚抛出的异常类型是 checked exceptionSpring 默认只回滚 RuntimeException 和 Error数据库引擎不支持事务例如 MySQL 的 MyISAM 引擎就不支持事务类没有被 Spring 管理没有加 Service / Component 注解也就没有代理对象多线程调用新开的线程拿不到当前线程的事务上下文其中我最想强调“同类内部调用”这个场景。很多人写了service.doSomething()然后在 doSomething 里调用了同类另一个带 Transactional 的方法以为这个事务会生效实际上完全不会。解决方案是注入自身代理、拆到另一个类或者使用 AopContext.currentProxy() 手工获取代理。这种问题在代码评审里我每次都能抓到。提示面试中说到框架题不要光背书一定要带出你自己的排查经历。比如“我上次在项目里遇到事务没回滚先看异常是不是被吞了再看方法是不是 private最后发现是同类调用的问题”。面试官要的就是这种真实的问题解决链路。4.3 MyBatis 一级缓存与二级缓存以及 N1 查询问题MyBatis 也是 Java 后端的常客。这道题的核心是缓存的作用域。一级缓存是 SqlSession 级别的默认开启同一个 SqlSession 内执行相同 SQL 会直接命中缓存但一旦执行了增删改操作缓存就会被清空。二级缓存是 namespace 级别的也就是 Mapper 级别需要手动开启。N1 查询问题发生在使用一对多映射时。如果你先查了 N 条主记录然后遍历每条主记录去查关联的子记录就会产生 1 N 条 SQL。这个问题我可以直接给你解决方案优先使用关联查询 collection 标签并通过fetchTypelazy按需加载复杂查询用分页插件 PageHelper 时要注意它对关联查询的支持方式。这里有一个我在实际项目里踩过的坑MyBatis 的二级缓存默认是内置的 PerpetualCache生产环境不建议使用因为如果两个 Mapper 操作了同一张表而它们的 namespace 不同会出现脏读问题。我建议直接用 Redis 做自定义缓存或者干脆关闭二级缓存。面试时说这一点说明你有过真实的生产环境判断。5. 分布式与微服务中高级面试必考的应用题Java 后端的进阶基本都集中在分布式这层。Redis、消息队列、分布式事务、接口幂等这些词在牛客网的面经里出现的频率极高。面试官考察的已经不只是“你会不会用”而是“你在高并发场景下怎么设计系统”。这一节我只挑三道几乎逢面必问的题。5.1 Redis 缓存穿透、缓存击穿、缓存雪崩与持久化机制这三个“缓存经典三兄弟”是分布式面试的门面题区分度很高。很多人能说出定义但说不出解决方案在生产环境的取舍。缓存穿透是指查询一个根本不存在的数据请求直接打到数据库导致数据库压力过大。解决方案有缓存空值设置较短的过期时间和布隆过滤器两种。布隆过滤器的原理是用多个哈希函数把 key 映射到位图数组的多个位置上判断某个 key 是否存在时只要有一个位是 0就确定不存在但所有位都是 1也只是“可能存在”存在误判率。所以布隆过滤器比较适合“判断不存在”的场景比如防止非法的用户 ID 穿透到数据库。缓存击穿是指某个热点 key 在过期的瞬间大量请求同时涌向数据库。解决方案是互斥锁只允许一个请求去查数据库并重建缓存和逻辑过期不给 key 设置物理过期时间而是在 value 里存一个逻辑过期时间后台异步刷新。我通常首推互斥锁因为它实现简单而且可以配合 try-finally 保证释放锁。逻辑过期方案虽然性能好但会存在短暂的数据不一致。缓存雪崩是大量 key 同时失效或者 Redis 节点直接宕机导致请求全部打到数据库。解决方案有三个方向设置随机的过期时间避免同一时刻大面积失效部署 Redis 集群提高可用性服务层面做多级缓存本地缓存 Redis。我还建议补充一句热点 key 的过期时间不建议太长否则更新不及时业务上会出问题。接着面试官通常会追问 Redis 持久化。RDB 是定时快照恢复速度快但可能丢失最后一次快照之后的数据AOF 是追加日志默认 everysec 策略最多丢失 1 秒的数据。现在生产环境很多是两者同时开启或者只用 AOF。能从这些方案里讲出“为什么我的系统关注数据一致性所以选择 everysec 的 AOF”说明你真的设计过系统。5.2 分布式事务与接口幂等性解决方案的取舍逻辑分布式事务是高级岗位的常客但基础岗位也偶尔会被问到。面试官不是真的让你在白板上把 Seata 源码默写出来而是想你讲清楚几个核心方案和它们的适用场景。第一个方案是二阶段提交2PC强一致性是它的优点但它有同步阻塞问题如果协调者挂了参与者会一直卡住。第二个方案是 TCCTry、Confirm、Cancel 三段式需要业务侵入适合每个分支都能明确预留资源的场景。第三个方案是本地消息表把业务操作和消息记录放在同一个本地事务里通过定时任务扫描消息表把消息发送给下游。第四个方案是 MQ 事务消息RocketMQ 支持半消息机制先发一条半消息再执行本地事务本地事务成功后再确认发送完整消息。接口幂等性这个问题我几乎每次面试都会问因为我见过大量因为幂等没做好导致重复扣款的线上事故。幂等的核心是“同一个请求执行多次和执行一次的结果相同”。常见的实现方式有数据库唯一索引用订单号或业务流水号作为唯一键重复插入会直接报错被捕获Token 机制服务端生成 token 返回给前端请求时携带 token服务端消费后删除重复提交时 token 已不存在直接拒绝分布式锁利用 Redis 的 SETNX 保证同一时刻只有一个请求在处理。权衡观点是不要一上来就用分布式事务。分布式事务的成本很高如果业务可以接受短时间的最终一致优先用本地消息表或 MQ 事务消息只有资金类、强一致的业务才考虑 TCC 或 2PC。5.3 消息队列怎么保证消息不丢失与不重复消费消息队列在 Java 后端面试里出现频率也很高。核心题目是三大问题“怎么保证消息不丢失”“怎么保证消息不重复消费”“怎么保证消息的顺序性”。我一个个说。消息不丢失要分三段分析。生产端发送消息时需要确认 Broker 真的接收到了比如 Kafka 设置 acksallRocketMQ 的同步发送会等待 Broker 返回确认信息。Broker 端要通过副本机制保证数据不丢Kafka 的副本数建议至少 3并且 min.insync.replicas 要大于 1。消费端真正处理完业务逻辑后才提交 offset 或 ack而不是收到消息就提交这是很多人容易犯的错。消息不重复消费本质上和幂等是同一个问题。因为即使你做好了消息不丢失也无法完全避免下游重复消费比如消费者处理完业务后还没来得及提交 offset进程就挂了重启后会从旧 offset 重放消息。所以消费者的业务逻辑必须天然幂等这又回到了上一题讲到的幂等设计。顺序性问题的标准答案是生产者侧保证同一个业务 key 的消息路由到同一个队列或分区消费者侧只使用一个线程消费该队列中的消息。但实际中单线程消费会导致吞吐量受限所以更精细的做法是利用内存中的队列做“分段有序”也就是按 key 分桶每个桶一个线程桶内串行处理。能主动给出这种方案说明你真的思考过性能和顺序之间的权衡。6. 数据结构与算法聊完项目之后的技术功底检验很多候选人抱怨“我简历上写的是后端开发为什么还要考算法”我的看法是算法题不是考你能背多少题而是看你有没有基本的逻辑拆分能力、边界意识、以及代码表达能力。牛客网上的 Java 算法题集中在排序、链表、二叉树、动态规划这几块能把这些啃下来应付大多数公司的笔试就够了。6.1 冒泡排序到快速排序你真的能把比较排序讲清楚吗排序是算法题里最基础也最容易被小看的一块。我先说一个很多人的误区背会快速排序的写法不等于你会排序算法。面试官如果追问“为什么快速排序在平均情况下是 O(n log n)”“什么情况下退化成 O(n²)”“为什么不用快速排序配合小规模数组的插入排序”很多人就露馅了。我把四个最常被问到的排序算法的要点整理成一张表面试前可以快速过一遍算法平均/最差时间复杂度空间复杂度稳定性核心思想冒泡排序O(n²) / O(n²)O(1)稳定相邻元素两两比较交换插入排序O(n²) / O(n²)O(1)稳定将未排序元素插入已排序序列归并排序O(n log n) / O(n log n)O(n)稳定分治后合并两个有序数组快速排序O(n log n) / O(n²)O(log n)不稳定选基准划分左右这里我特别想提醒两个点。第一快速排序的最差情况发生在每次选择的基准都是当前序列的最大值或最小值时比如对基本有序的数组使用固定基准退化成 O(n²)。规避方法是三数取中。第二归并排序是稳定的但需要额外空间快速排序不稳定但空间占用少。实际工程中很多语言的排序库会对小规模子数组改用插入排序JDK 的 Arrays.sort 在规模小时用的也是插入排序这就是典型的工程优化思维。6.2 手写单例模式和生产者消费者模型考的是基本功单例模式是面试里出现频率极高的手写题而且考察方式往往不是让你默写代码而是让你对比几种写法的优劣。我直接给出我的推荐写法静态内部类方式或枚举方式。静态内部类的核心是利用类加载机制的初始化阶段天然线程安全。枚举方式则是《Effective Java》作者极力推荐的方式它能天然防止反射和序列化破坏单例。下面是一个示例public enum Singleton { INSTANCE; public void doSomething() { // 业务逻辑 } }双检锁方式需要写 volatile 防止指令重排序而且代码冗长虽然经典但在面试中我会建议你展示它再主动分析它的缺陷最后给出现代推荐写法。这样你的回答就显得既有深度又能体现对工程实践的思考。生产者消费者模型则是并发编程的经典实操题。不要只会用 synchronized wait/notify那是最底层的方式。更推荐用 BlockingQueue代码简洁且线程安全。生产者在 put 数据时若无空间会阻塞消费者在 take 数据时若是空队列会阻塞天然实现了“满了等、空了等”的逻辑。面试官如果能再追问“你想要实现一个有界队列而不是无界队列为什么不建议用无界队列”那就涉及到内存溢出的风险了。能把这一层讲出来这道题就过了。7. 从真题到 offer如何高效刷题与备战规划到了这一步你已经把核心真题过了一遍。但我想认真地说面试从来不是“背完题就能过”的游戏你需要一套自己的复习节奏和答题节奏。这一节我把自己这些年看过的、以及自己备考时验证过的方法整理出来供你参考。第一步是分模块建立知识树。不要一上来就刷题先花两天时间把 Java 基础、集合、并发、JVM、Spring、Redis、MQ、算法八个模块的思维导图过一遍搞清楚每个模块下有哪些核心知识点。然后针对自己薄弱的部分先看书或者看视频补基础再去做题。第二步是用“面试官视角”复盘每一道题。每做完一道题不要只满足于“我对了”要问自己三个问题这道题考察的是什么知识点我要从几个维度来回答面试官还可能就哪个追问点继续深挖比如你做完了 HashMap 的题就要主动想到它可能会引向 ConcurrentHashMap、引向线程安全、引向扩容期间的数据可见性。第三步是模拟面试实战。我强烈建议找朋友互相模拟或者对着录音机自己讲一遍。你会发现很多知识点你脑子里明白但说出来的逻辑是乱的。面试官没有耐心听你绕圈子你需要在 1 到 2 分钟内把一个知识点讲清楚然后把关键细节一层层展开。最后简历上的项目经历一定要能和这些知识点串起来。我面试过太多候选人简历上写了“使用 Redis 做缓存”但我一问“缓存穿透怎么解决”他支支吾吾答不上来这就非常减分。项目里用了什么技术你就要把那个技术的难点、选型理由、踩坑经历全部理清。面试官问技术的终点永远是你的项目里能不能落地。我在实际招人时最看重的是候选人有没有“把知识打通”的能力。一道看似八股的 HashMap 题可以问到 JVM 内存、数据结构、并发安全、甚至 CPU 缓存和哈希扰动函数的数学原理。你能答到第几层基本就代表了你的水平在第几层。这份真题集锦是很好的镜子照着它自测一遍你会很清楚自己该往哪个方向努力。刷题不是目的借着刷题重建自己的知识体系才是你真正能带进下一份工作的东西。