尧图网站建设 
350道Java面试题整理下来我最想说的不是哪道题该背而是这份题目背后藏着大厂筛选人的真实逻辑。我花了将近两个月的时间把分布式、微服务、高并发三个方向的最新面试题连同岗位JD、面经、源码分析帖一起过了一遍最后沉淀出这350道。整个过程下来最大的感受是面试官根本不指望你把所有细节背得滚瓜烂熟他们想确认的是你在真实系统中遇到问题时能不能做出靠谱的判断。这篇整理适合三类人准备跳槽的Java后端、正在带团队做架构升级的技术负责人、以及想把分布式和高并发这块知识体系补完整的在校生。看完你能搞明白每个考点背后考察的是什么能力也能直接拿题目清单去自测。1. 为什么是350道题目怎么分类整理1.1 三大板块的题量配比逻辑350道题不是平均分配的。整理过程中我先把近两年大厂Java后端岗的面经全部拉出来做了词频统计发现分布式、微服务、高并发三个方向加起来占了技术面问题的七成以上。我在最终清单里把题量配比定为分布式约120道微服务约110道高并发约120道。这个比例不是拍脑袋而是对照面试轮次倒推出来的。大厂Java岗的面试一般有四到五轮一轮基础 coding 一轮项目深挖 一轮系统设计 一轮交叉面或终面。项目深挖和系统设计这两轮基本就是分布式、微服务、高并发的主场。基础数据结构算法题反而占比不高因为到了面试官面前大家八股文水平都差不多拉开差距靠的全是工程判断力。比如同样问分布式锁怎么做初级候选人会背Redis SETNX那套有经验的候选人会把Redisson源码实现中的看门狗机制、主从切换时的锁丢失问题一并讲清楚。如果你的复习时间只有两周我建议优先啃高并发部分的缓存与消息队列题这部分性价比最高几乎每场面试都会出现。如果有四周以上再按分布式事务、服务治理、JVM调优的顺序往下推进。题量配比的另一个作用是帮你控制复习节奏每天消化12道左右正好一个月过完一轮第二轮用来重点突破薄弱点。1.2 大厂面试题的核心规律从会做题到会解题的转变整理这350道题的过程中我发现一个特别明显的趋势纯记忆类题目的数量在逐年下降取而代之的是场景题和系统设计题。以前面试喜欢问Spring Cloud和Dubbo有什么区别现在更喜欢问你们订单系统从单机改造为微服务架构服务拆分的原则是什么拆分后数据一致性怎么保证。这类题的共同特征是没有标准答案只有更优解。面试官考察的是你在资源受限、时间受限、团队能力参差不齐的现实条件下能不能做出合理的取舍。比如服务拆分理论上有领域驱动设计、按业务能力拆分、按子域拆分等一堆方法论但落到真实场景中你还要考虑团队规模能不能支撑多服务运维、拆分后调用链变长带来的延迟、分布式事务的成本能不能接受。我在题目清单里画了一条递进线先是基础概念题比如什么是CAP定理、BASE理论算是入场券接着是方案对比题比如分布式事务选2PC还是Saga考察的是知识广度最后是场景设计题比如设计一个支持百万并发的秒杀系统考察的是把零散知识串起来的综合能力。这条递进线也回答了另一个常见困惑为什么我背了很多八股文面试却挂在一道听过的场景题上。因为背诵只覆盖了前两层第三层需要你真正动手搭建过、踩过坑才能答得出来。2. 分布式板块120道题背后的底层逻辑2.1 分布式事务面试频次最高的三个问题分布式事务在120道分布式题目里占比将近四分之一是整个板块最核心的考点。我统计下来的高频题是这三个分布式事务有哪些解决方案、2PC和三阶段提交的区别、Seata的AT模式和TCC模式底层怎么实现的。先说方案分类。目前工业界能落地的方案基本就是两PC2PC、三PC3PC、TCCTry Confirm Cancel、Saga、本地消息表、MQ事务消息这几种。2PC的缺点是同步阻塞和协调者单点3PC引入了超时机制和准备阶段但依然没有彻底解决脑裂问题。真正在生产环境用得多的还是TCC、Saga和事务消息因为它们在最终一致性和可用性之间做了更好的折中。Seata的AT模式很多人只背了自动生成反向SQL这句话面试官一追问就露馅。底层其实是三个核心组件全局事务协调者TC、事务管理器TM和资源管理器RM。TM负责开启全局事务RM把本地事务注册到TC英国每次数据变更都会记录undolog日志全局提交时删掉undolog全局回滚时用undolog反向补偿。这里有个关键细节AT模式之所以能自动回滚依赖的是数据库本身的本地事务和行锁所以对数据库类型有限制Oracle和MySQL没问题但某些分布式数据库就不支持。我整理题目时还补了一道容易被忽略的题订单和库存的分布式事务怎么设计。这道题考察的不是事务方案选型而是业务层设计。常规做法是把下单拆成创建订单和扣减库存两个步骤中间用本地消息表或RocketMQ事务消息作为缓冲。但更进一步的答案是先锁定库存而不是直接扣减订单超时未支付时释放锁定的库存这样能大幅减少分布式事务的触发概率。很多系统其实不需要强一致的分布式事务从业务流程上规避才是最优解。2.2 分布式锁与缓存答好主从一致性的关键分布式锁是分布式板块的第二个高频考点但面试官的提问方式已经从怎么实现分布式锁升级成你们生产环境用Redis分布式锁主从切换的时候锁丢了怎么办。这个升级背后的背景是很多团队把Redisson的看门狗机制背得很熟却忽略了它底层依赖的Redis主从复制是异步的。Redisson的实现机制值得讲透。它通过lua脚本保证原子性用SETNX加锁EXPIRE设置超时看门狗每10秒自动续期防止锁持有者宕机后死锁。但看门狗的续期逻辑有一个前提锁key必须在Master节点上。如果Master写入锁key之后还没同步到Slave节点Master就宕机了Slave节点升为Master此时新Master上根本没有这把锁其他线程就能拿到锁进入临界区。这道题的标准答法是Redis官方推荐的RedLock算法或者引入ZooKeeper的临时顺序节点。但我在题注里写了一段重要提醒RedLock算法在工程界争议非常大Martin Kleppmann专门发文章论证过它存在时钟跳跃和GC暂停导致的锁失效问题。实践中很多大厂宁愿用ZooKeeper因为强一致性和顺序性天然适合分布式协调。如果你在面试中觉得项目简单也不用慌关键是说出我知道这个问题的存在并且对比过两种方案的取舍这种诚实比背一个看似完美的方案更打动人。分布式缓存的高频题集中在缓存穿透、缓存击穿、缓存雪崩和缓存与数据库一致性这四个方向。布隆过滤器、互斥锁、逻辑过期、延迟双删、订阅binlog增量更新这些名词不少人都知道但面试官现在更愿意追问延迟双删失败怎么办。我总结的唯一稳妥答案以DB为准通过监听MySQL binlog或者Canal组件异步更新缓存失败就消费重试。缓存一致性问题永远无法彻底解决只能通过架构设计把不一致窗口缩小到可接受范围。2.3 分布式ID、链路追踪等基础组件的考察方式分布式ID生成是分布式板块里少有的可以具体到代码的题目。常见的方案有UUID、数据库自增、号段模式、雪花算法。UUID无序且太长不适合做数据库主键数据库自增有性能瓶颈号段模式是美团Leaf的核心思路雪花算法则是面试中讨论最多的。雪花算法需要关心四个参数机器ID、数据中心ID、毫秒时间戳和序列号总共拼成一个64位long。面试官常问的两个细节是时钟回拨怎么处理序列号在同一毫秒内溢出怎么办。时钟回拨有三种处理级别直接抛异常、等时钟追上来、记录最后一次生成ID的时间戳并用备用号段兜底。美团Leaf的号段模式能覆盖大部分场景但如果你的系统对时钟特别敏感可以参考百度UidGenerator的缓存实现。我在整理时把这道题归为必须能手写的级别因为分布式ID的代码量不大面试官经常会随手拿来考察候选人的编码能力。链路追踪这一块大厂现在基本是下面这套组合拳用SkyWalking或Jaeger做全链路追踪用Prometheus抓指标用Grafana展示用ELK收集日志。面试问得最多的是Trace ID和Span ID的传递机制。这道题的价值在于考察你是否理解线程上下文、HTTP请求头传递和消息队列消息头透传。很多人一上来就说我们用了SkyWalking但被问到Trace ID怎么跨线程传递就卡住了。答案其实不复杂对于Spring Boot项目用Tracer实例把Trace ID放进MDC用ThreadLocal传递注意使用TransmittableThreadLocal解决线程池场景下上下文丢失的问题。3. 微服务板块110道题从架构拆分讲到治理闭环3.1 服务拆分与注册发现面试官的连环追问微服务的题我按拆分→调用→治理→部署这个生命周期来组织第一步就是服务拆分。面试官最烦的答案是按模块拆分这种空话。要答好服务拆分得有判断标准AKF扩展立方体可以处理纵向和横向拆分但微服务架构中的主流方法还是按领域驱动设计的限界上下文来拆分。关键是给出约束条件每个服务的代码量控制在什么范围、团队规模决定拆分粒度、数据库不可跨服务访问。这里有个我特别提醒的坑很多候选人答服务拆分时只讲理论一提你们公司服务怎么拆的就露馅。我建议准备一个自己负责过的真实拆分案例数据不用多把服务从一个大单体拆成五个子服务的动机写出来哪些模块迭代最频繁、哪些模块扩容需求最大、哪些模块依赖了不同的存储引擎。如果实际工作中没做过拆分就找一个开源项目把代码拉下来自己画清楚它的服务边界。注册发现这块的核心题是Nacos和Eureka有什么区别。Eureka的自我保护机制会让它在本地区域内故障时不剔除服务实例适合集群规模小、网络不稳定的情况Nacos不仅支持注册发现还内置了配置中心且区分临时实例和持久化实例。现在主流Spring Cloud版本都用Nacos但面试官会深挖AP和CP的切换逻辑Nacos默认是AP模式保证可用性但配置中心功能却需要CP模型保证数据一致性所以Nacos实际上在同时承担两种角色。3.2 熔断限流与网关让服务稳得住的设计微服务治理里最常被问到的是服务雪崩怎么解决答案里离不开熔断、降级、限流三个词。Sentinel是阿里巴巴开源的轻量级组件相比Hystrix它做了两件事一是提供实时的监控面板和规则配置热更新二是支持QPS和并发线程数两种流量控制维度。面试官问你们怎么做限流时最好直接说出Sentinel的DashBoard和网关集成的细节顺带提一下流控规则中快速失败和排队等待的区别。网关部分的高频题是Gateway和Zuul的区别以及网关里做过哪些事。Spring Cloud Gateway基于WebFlux的响应式编程线程模型上比Zuul 1.x的Servlet阻塞式IO更有优势。网关层一般做的事包括协议转换、统一鉴权、灰度路由、流控和日志埋点。这里我建议准备一个真实例子比如你们把JWT鉴权从各个业务服务移到网关后上线流程图是什么样的之前那种每个服务各自验一次Token的做法问题在哪。答出前置到网关后业务服务只需要信任请求头里的用户ID不用关心解析逻辑这就是面试官想听到的工程思维。3.3 微服务面试题的常见延伸配置中心与可观测性配置中心这道题在微服务面试里越来越难回避尤其是Spring Cloud Config、Apollo、Nacos三者对比。Apollo的优势在于配置变更的实时推送和Namespace隔离适合复杂配置管理场景Nacos的配置中心功能更简洁和注册中心是统一控制台部署成本低。很多面试官会追问配置改了一台机器其他机器怎么感知底层是客户端长轮询机制。Nacos客户端发起一个带超时时间的HTTP请求服务端有配置变更就立即返回没变更就挂起等待达到超时时间后再发起下一次请求。这个机制比基于WebSocket的实时推送稳对网络抖动更友好。可观测性在大厂面试中的存在感越来越强面试题从什么是三色指标到怎么排查接口突然变慢了都有。三色指标就是Metrics、Logs、Traces对应Prometheus ELK SkyWalking。一条常见排查链路是先用SkyWalking查慢Trace找到耗时最高的Span再去ELK搜该Trace ID对应的业务日志最后用Prometheus看服务所在主机的CPU、内存和JVM指标。把这条链路讲完整比背十个框架名字都管用。可观测性不是额外功能而是当你把服务拆成几十个小应用后唯一能让你在半夜两点定位问题的依赖工具。微服务板块我还额外收录了微服务之间的调用方式这道基础题同步有REST和Dubbo的RPC异步走MQ。同步调用的优点是直观但链路长时延迟累积严重异步解耦后吞吐量高但事务边界和一致性复杂。业界主流做法是内部高吞吐场景用Dubbo接口对App开放用REST异步事件用MQ--三种调用方式并存而不是只选一种。4. 高并发板块120道场景题怎么答才不翻车4.1 秒杀、订单库存、IM消息三大经典场景拆解高并发题目里最常出现的三个场景是秒杀、订单库存和IM消息推送。这三类题基本覆盖了缓存、消息队列、限流、分布式锁、数据库优化的所有考点。秒杀系统的核心约束是瞬时流量是日常的十倍甚至百倍但库存只有固定的数量。思路一定要讲出层层削峰的逻辑CDN静态化商品页、网关层限流、Redis预扣库存、MQ异步下单、数据库最终扣减。其中最容易出彩的是库存扣减的方案。先用Redis的Lua脚本原子扣减库存到0抢到名额的用户再往MQ里发一条下单消息消费者端用数据库唯一索引或版本号做幂等最终保证没有超卖也没有少卖。所有方案都允许你说我们是这么做的但必须说清楚为什么这样设计。订单和库存场景我前面提过分布式事务这里再补充一个高频追问数据库库存字段用int够不够扣减SQL怎么写才有高性能。答案是用update stock set stockstock-#{count} where id#{id} and stock#{count}这样的原子条件更新配合乐观锁版本号。性能瓶颈在行锁竞争上因此扣减集中在库存服务内部不要跨服务频繁加分布式锁。ERP库存场景的思路也类似高并发写库之前先合并请求用状态机区分入单、锁定、扣减、回滚各阶段。IM高并发场景考察的是推送链路设计。Kafka或者RocketMQ负责事件分发客户端通过WebSocket长连接接入。连接层是无状态的可以水平扩展关键在于把谁在线的映射关系放到Redis里推送时先从Redis找到该用户所在的连接节点再把消息投递给该节点。如果用户不在线消息进离线存储上线后拉取未读消息。答这道题时最容易出错的是漏掉消息顺序性单聊消息可以用相同的key打到一个分区保证顺序群聊则需要将发送者ID作为分片键。4.2 限流与削峰从算法到落地的完整链路限流算法面试题虽然基础但真正会做出取舍的人不多。固定窗口计数器有临界突变问题滑动窗口解决了部分漏桶算法可以平滑流量但无法应对突发令牌桶算法允许突发流量是业界最常用的方案。Guava的RateLimiter就是令牌桶实现Sentinel默认采用滑动窗口Nginx也内置了漏桶实现。我在答案中专门列了一张对比表如果你只需要保护DB漏桶更合适如果希望允许短时抢购的突发流量令牌桶更合适。削峰这块RocketMQ和Kafka都有各自的顺序消费和批量消费机制。如果消息量在峰值达到每秒几万条消费者侧的优化比生产者更重要批量拉取、批量提交offset、消费逻辑里减少远程调用。Kafka的高吞吐不是白来的但用不好也是在面试中区分用过和用过且懂的分水岭。比如如何保证消息不丢失从生产者端要开启ackall配合重试机制Broker端要配置副本数大于1且minISR大于1消费者端要等业务逻辑执行成功后才提交offset。这三层缺一不可。这里有一个常被忽略的点限流和削峰要和业务SLA挂钩。不是所有流量都值得削峰微博热搜和电商大促的做法就完全不同。大促可以接受短暂排队但IM场景延迟增加几秒就是事故。所以高并发设计没有一个通用的模板面试官要听到的是你针对具体业务做的参数选择比如我们设定QPS上限为2000超出部分进入排队等待是因为下游数据库单库的支撑能力在2500左右留出20%余量这种具体数字。4.3 JVM与数据库调优高并发系统的最后一公里高并发题目做了很多最终还是要落到JVM和数据库的调优上。JVM的高频题是JVM内存结构GC调优实战线上OOM怎么排查。现在面试官基本不看你能背出几个收集器而是直接抛出场景线上服务Full GC频繁怎么办。标准排查链路是先用jstat看GC频率和内存使用率再用jmap dump出堆内存通过MAT分析大对象和泄漏点。如果堆没问题再看代码里是否有大循环导致撑爆线程栈以及是否存在内存缓存放了无限增长的数据。数据库调优的核心是索引和SQL。面试题一个慢查询SQL怎么优化的标准答法分四步走先看执行计划是否走了全表扫描和文件排序再看索引设计是否符合最左前缀原则然后检查是否发生了隐式类型转换导致索引失效最后确认是否可以用覆盖索引减少回表。这套步骤用在真实压测调优过程中能解决九成的慢查询问题。高并发下的数据库瓶颈还有一个隐藏考点连接池大小。很多人以为连接数越大越好实际上连接过多会导致数据库CPU上下文切换膨胀。PostgreSQL官方给出的建议是连接数等于核数乘以2加磁盘数对于MySQL的常规SSD场景几十个连接已经足够支持每秒几千次的事务处理多余的连接只会拖垮性能。把连接池的配置当成面试题的一部分能体现出你真正考虑过资源配比。5. 刷题方法、时间规划与避坑手册5.1 350道题的刷题顺序与时间分配我建议的刷题顺序和上面章节的顺序不同先从高并发场景题开始因为场景题最容易建立全局视角再回到分布式体系化补基础最后再做微服务治理题。原因很简单场景题能让你知道各种技术组件是为什么存在的。比如先看秒杀方案你才会真正理解Redis为什么会话中锁、MQ为什么叫削峰填谷反过来直接背Redis数据结构这类基础题容易越背越焦虑。时间分配上如果你是在职准备每天两小时六周为一个周期。前两周专门刷高并发场景题并结合一个实际项目把这些组件画进系统架构图中中间两周攻分布式事务、分布式锁、分布式缓存三座大山每个方向至少写一个笔记做方案对比最后两周做微服务治理题把网关、熔断、服务拆分串成一条完整的知识链路。最后留一周时间总复习重新过一遍自己整理的题注而不是重新背诵全文。在职准备最大的敌人是碎片化。我整理的时候给自己的要求是每道题必须有一句话结论 展开细节 面试官追问应对这样上下班路上直接看笔记不用再临时翻博客。比如分布式锁那题一句话结论是Redis锁适合大部分场景但主从切换存在锁丢失风险强一致性场景应该用ZooKeeper展开细节是Redisson watch dog的续期机制追问应对是RedLock的争议点。5.2 系统设计题答题框架防止被连环追问打乱节奏系统设计题是350道题里最难临场发挥的部分比如设计一个支持百万并发的直播间弹幕系统设计一个短链系统。我的答题框架固定为六步明确需求边界、估算规模、制定核心流程、选择存储组件、识别瓶颈与优化、画出架构图。以弹幕系统为例。先确认是只做文本弹幕还是包含礼物特效然后估算在线人数和每秒吞吐量。存储上实时弹幕用Redis的有序集合按消息序号排序滚动展示窗口内的数据回放弹幕落到ClickHouse或者HBase。消息分发走WebSocket长连接服务端通过Redis的发布订阅或者消息队列广播。瓶颈在单节点WebSocket的连接数上限、广播风暴、以及弹幕排序的实时性。这套框架最大的作用是防止被连环追问打乱节奏。我们习惯性地先讲方案A结果面试官从方案A的缺点切入越问越偏最后把自己逼进死胡同。用框架答的好处是你每一步都有明确的目的面试官不管从哪一步切入你都还有上下文知道接下来要到哪一步。5.3 整理过程中踩过的坑和给后来者的建议这份350道题从我起意到最终成稿中间踩过一些坑这几条经验一定值得分享。第一不要迷信大厂官方真题来源。市面上的面经鱼龙混杂同一道题在不同出处里答案质量差别很大。我只相信两类来源一手面经中带完整回答的帖子以及官方博客或源码解析文章。很多Java面试题库只是把知识点洗了一遍稿回答里还掺着明显错误比如把RabbitMQ和RocketMQ的事务消息混为一谈。第二整理题目时必须自己写一遍答案哪怕只是写大纲。因为一旦直接收藏别人的答案大脑会误以为自己已经掌握等到面试时组织语言才发现思路是断的。我的习惯是先做题再对答案给自己模拟一个面壁五分钟写下自己会怎么答、漏掉了哪些点再对照参考答案补充。这个过程比单纯刷十道题都有效。第三高并发题目不要只啃并行编程一定要动手压测。面试官问JVM参数、问线程池配置如果你没有压测数据支撑答案就只是背诵。我整理期间用JMeter和wrk对我自己搭的一个Spring Boot服务做了基线压测把线程池大小、数据库连接池、Redis缓存命中率三个变量分别调整记录了下QPS和TP99的变化。这些数据在面试时直接说出来可信度完全不是一个级别。第四注意知识的体系化串联。我最后整理出的目录不是按题目序号罗列而是按从单机到分布式会遇到什么问题、每个问题有哪些解法、各解法怎么选型组织起来的。面试官问分布式事务时你能从2PC一路讲到Saga、讲到本地消息表、讲到业务设计如何规避这种横向串联能力才是350道题背后的核心价值。6. 面试现场的经验沉淀刷完这350道题之后我和几位大厂面试官朋友聊过一次大家一致认可的结论是面试的本质是用有限的问题探测你知识的深度和广度。深度靠项目经验广度靠知识体系。整理这份题的目的不是押中题目而是逼着自己把平时散落的知识重新编排一遍。如果你时间紧迫至少把这350道题中的三个必考方向学透分布式锁与缓存的一致性方案、服务拆分与治理思路、高并发场景题的标准答题框架。这三个方向占据了技术面至少一半的问题来源也能检验你的系统设计能力。最后再分享一个我实测有效的练习方法拿出一个真实的线上系统架构图把自己当成面试官对着图问如果这里出现故障怎么办这个模块为什么不拆成两个服务这个数据库表的数据量达到亿级之后怎么优化。自己出题考自己比任何题库都更能暴露知识盲区。 350道Java面试题解析：分布式、微服务与高并发核心考点
350道Java面试题整理下来我最想说的不是哪道题该背而是这份题目背后藏着大厂筛选人的真实逻辑。我花了将近两个月的时间把分布式、微服务、高并发三个方向的最新面试题连同岗位JD、面经、源码分析帖一起过了一遍最后沉淀出这350道。整个过程下来最大的感受是面试官根本不指望你把所有细节背得滚瓜烂熟他们想确认的是你在真实系统中遇到问题时能不能做出靠谱的判断。这篇整理适合三类人准备跳槽的Java后端、正在带团队做架构升级的技术负责人、以及想把分布式和高并发这块知识体系补完整的在校生。看完你能搞明白每个考点背后考察的是什么能力也能直接拿题目清单去自测。1. 为什么是350道题目怎么分类整理1.1 三大板块的题量配比逻辑350道题不是平均分配的。整理过程中我先把近两年大厂Java后端岗的面经全部拉出来做了词频统计发现分布式、微服务、高并发三个方向加起来占了技术面问题的七成以上。我在最终清单里把题量配比定为分布式约120道微服务约110道高并发约120道。这个比例不是拍脑袋而是对照面试轮次倒推出来的。大厂Java岗的面试一般有四到五轮一轮基础 coding 一轮项目深挖 一轮系统设计 一轮交叉面或终面。项目深挖和系统设计这两轮基本就是分布式、微服务、高并发的主场。基础数据结构算法题反而占比不高因为到了面试官面前大家八股文水平都差不多拉开差距靠的全是工程判断力。比如同样问分布式锁怎么做初级候选人会背Redis SETNX那套有经验的候选人会把Redisson源码实现中的看门狗机制、主从切换时的锁丢失问题一并讲清楚。如果你的复习时间只有两周我建议优先啃高并发部分的缓存与消息队列题这部分性价比最高几乎每场面试都会出现。如果有四周以上再按分布式事务、服务治理、JVM调优的顺序往下推进。题量配比的另一个作用是帮你控制复习节奏每天消化12道左右正好一个月过完一轮第二轮用来重点突破薄弱点。1.2 大厂面试题的核心规律从会做题到会解题的转变整理这350道题的过程中我发现一个特别明显的趋势纯记忆类题目的数量在逐年下降取而代之的是场景题和系统设计题。以前面试喜欢问Spring Cloud和Dubbo有什么区别现在更喜欢问你们订单系统从单机改造为微服务架构服务拆分的原则是什么拆分后数据一致性怎么保证。这类题的共同特征是没有标准答案只有更优解。面试官考察的是你在资源受限、时间受限、团队能力参差不齐的现实条件下能不能做出合理的取舍。比如服务拆分理论上有领域驱动设计、按业务能力拆分、按子域拆分等一堆方法论但落到真实场景中你还要考虑团队规模能不能支撑多服务运维、拆分后调用链变长带来的延迟、分布式事务的成本能不能接受。我在题目清单里画了一条递进线先是基础概念题比如什么是CAP定理、BASE理论算是入场券接着是方案对比题比如分布式事务选2PC还是Saga考察的是知识广度最后是场景设计题比如设计一个支持百万并发的秒杀系统考察的是把零散知识串起来的综合能力。这条递进线也回答了另一个常见困惑为什么我背了很多八股文面试却挂在一道听过的场景题上。因为背诵只覆盖了前两层第三层需要你真正动手搭建过、踩过坑才能答得出来。2. 分布式板块120道题背后的底层逻辑2.1 分布式事务面试频次最高的三个问题分布式事务在120道分布式题目里占比将近四分之一是整个板块最核心的考点。我统计下来的高频题是这三个分布式事务有哪些解决方案、2PC和三阶段提交的区别、Seata的AT模式和TCC模式底层怎么实现的。先说方案分类。目前工业界能落地的方案基本就是两PC2PC、三PC3PC、TCCTry Confirm Cancel、Saga、本地消息表、MQ事务消息这几种。2PC的缺点是同步阻塞和协调者单点3PC引入了超时机制和准备阶段但依然没有彻底解决脑裂问题。真正在生产环境用得多的还是TCC、Saga和事务消息因为它们在最终一致性和可用性之间做了更好的折中。Seata的AT模式很多人只背了自动生成反向SQL这句话面试官一追问就露馅。底层其实是三个核心组件全局事务协调者TC、事务管理器TM和资源管理器RM。TM负责开启全局事务RM把本地事务注册到TC英国每次数据变更都会记录undolog日志全局提交时删掉undolog全局回滚时用undolog反向补偿。这里有个关键细节AT模式之所以能自动回滚依赖的是数据库本身的本地事务和行锁所以对数据库类型有限制Oracle和MySQL没问题但某些分布式数据库就不支持。我整理题目时还补了一道容易被忽略的题订单和库存的分布式事务怎么设计。这道题考察的不是事务方案选型而是业务层设计。常规做法是把下单拆成创建订单和扣减库存两个步骤中间用本地消息表或RocketMQ事务消息作为缓冲。但更进一步的答案是先锁定库存而不是直接扣减订单超时未支付时释放锁定的库存这样能大幅减少分布式事务的触发概率。很多系统其实不需要强一致的分布式事务从业务流程上规避才是最优解。2.2 分布式锁与缓存答好主从一致性的关键分布式锁是分布式板块的第二个高频考点但面试官的提问方式已经从怎么实现分布式锁升级成你们生产环境用Redis分布式锁主从切换的时候锁丢了怎么办。这个升级背后的背景是很多团队把Redisson的看门狗机制背得很熟却忽略了它底层依赖的Redis主从复制是异步的。Redisson的实现机制值得讲透。它通过lua脚本保证原子性用SETNX加锁EXPIRE设置超时看门狗每10秒自动续期防止锁持有者宕机后死锁。但看门狗的续期逻辑有一个前提锁key必须在Master节点上。如果Master写入锁key之后还没同步到Slave节点Master就宕机了Slave节点升为Master此时新Master上根本没有这把锁其他线程就能拿到锁进入临界区。这道题的标准答法是Redis官方推荐的RedLock算法或者引入ZooKeeper的临时顺序节点。但我在题注里写了一段重要提醒RedLock算法在工程界争议非常大Martin Kleppmann专门发文章论证过它存在时钟跳跃和GC暂停导致的锁失效问题。实践中很多大厂宁愿用ZooKeeper因为强一致性和顺序性天然适合分布式协调。如果你在面试中觉得项目简单也不用慌关键是说出我知道这个问题的存在并且对比过两种方案的取舍这种诚实比背一个看似完美的方案更打动人。分布式缓存的高频题集中在缓存穿透、缓存击穿、缓存雪崩和缓存与数据库一致性这四个方向。布隆过滤器、互斥锁、逻辑过期、延迟双删、订阅binlog增量更新这些名词不少人都知道但面试官现在更愿意追问延迟双删失败怎么办。我总结的唯一稳妥答案以DB为准通过监听MySQL binlog或者Canal组件异步更新缓存失败就消费重试。缓存一致性问题永远无法彻底解决只能通过架构设计把不一致窗口缩小到可接受范围。2.3 分布式ID、链路追踪等基础组件的考察方式分布式ID生成是分布式板块里少有的可以具体到代码的题目。常见的方案有UUID、数据库自增、号段模式、雪花算法。UUID无序且太长不适合做数据库主键数据库自增有性能瓶颈号段模式是美团Leaf的核心思路雪花算法则是面试中讨论最多的。雪花算法需要关心四个参数机器ID、数据中心ID、毫秒时间戳和序列号总共拼成一个64位long。面试官常问的两个细节是时钟回拨怎么处理序列号在同一毫秒内溢出怎么办。时钟回拨有三种处理级别直接抛异常、等时钟追上来、记录最后一次生成ID的时间戳并用备用号段兜底。美团Leaf的号段模式能覆盖大部分场景但如果你的系统对时钟特别敏感可以参考百度UidGenerator的缓存实现。我在整理时把这道题归为必须能手写的级别因为分布式ID的代码量不大面试官经常会随手拿来考察候选人的编码能力。链路追踪这一块大厂现在基本是下面这套组合拳用SkyWalking或Jaeger做全链路追踪用Prometheus抓指标用Grafana展示用ELK收集日志。面试问得最多的是Trace ID和Span ID的传递机制。这道题的价值在于考察你是否理解线程上下文、HTTP请求头传递和消息队列消息头透传。很多人一上来就说我们用了SkyWalking但被问到Trace ID怎么跨线程传递就卡住了。答案其实不复杂对于Spring Boot项目用Tracer实例把Trace ID放进MDC用ThreadLocal传递注意使用TransmittableThreadLocal解决线程池场景下上下文丢失的问题。3. 微服务板块110道题从架构拆分讲到治理闭环3.1 服务拆分与注册发现面试官的连环追问微服务的题我按拆分→调用→治理→部署这个生命周期来组织第一步就是服务拆分。面试官最烦的答案是按模块拆分这种空话。要答好服务拆分得有判断标准AKF扩展立方体可以处理纵向和横向拆分但微服务架构中的主流方法还是按领域驱动设计的限界上下文来拆分。关键是给出约束条件每个服务的代码量控制在什么范围、团队规模决定拆分粒度、数据库不可跨服务访问。这里有个我特别提醒的坑很多候选人答服务拆分时只讲理论一提你们公司服务怎么拆的就露馅。我建议准备一个自己负责过的真实拆分案例数据不用多把服务从一个大单体拆成五个子服务的动机写出来哪些模块迭代最频繁、哪些模块扩容需求最大、哪些模块依赖了不同的存储引擎。如果实际工作中没做过拆分就找一个开源项目把代码拉下来自己画清楚它的服务边界。注册发现这块的核心题是Nacos和Eureka有什么区别。Eureka的自我保护机制会让它在本地区域内故障时不剔除服务实例适合集群规模小、网络不稳定的情况Nacos不仅支持注册发现还内置了配置中心且区分临时实例和持久化实例。现在主流Spring Cloud版本都用Nacos但面试官会深挖AP和CP的切换逻辑Nacos默认是AP模式保证可用性但配置中心功能却需要CP模型保证数据一致性所以Nacos实际上在同时承担两种角色。3.2 熔断限流与网关让服务稳得住的设计微服务治理里最常被问到的是服务雪崩怎么解决答案里离不开熔断、降级、限流三个词。Sentinel是阿里巴巴开源的轻量级组件相比Hystrix它做了两件事一是提供实时的监控面板和规则配置热更新二是支持QPS和并发线程数两种流量控制维度。面试官问你们怎么做限流时最好直接说出Sentinel的DashBoard和网关集成的细节顺带提一下流控规则中快速失败和排队等待的区别。网关部分的高频题是Gateway和Zuul的区别以及网关里做过哪些事。Spring Cloud Gateway基于WebFlux的响应式编程线程模型上比Zuul 1.x的Servlet阻塞式IO更有优势。网关层一般做的事包括协议转换、统一鉴权、灰度路由、流控和日志埋点。这里我建议准备一个真实例子比如你们把JWT鉴权从各个业务服务移到网关后上线流程图是什么样的之前那种每个服务各自验一次Token的做法问题在哪。答出前置到网关后业务服务只需要信任请求头里的用户ID不用关心解析逻辑这就是面试官想听到的工程思维。3.3 微服务面试题的常见延伸配置中心与可观测性配置中心这道题在微服务面试里越来越难回避尤其是Spring Cloud Config、Apollo、Nacos三者对比。Apollo的优势在于配置变更的实时推送和Namespace隔离适合复杂配置管理场景Nacos的配置中心功能更简洁和注册中心是统一控制台部署成本低。很多面试官会追问配置改了一台机器其他机器怎么感知底层是客户端长轮询机制。Nacos客户端发起一个带超时时间的HTTP请求服务端有配置变更就立即返回没变更就挂起等待达到超时时间后再发起下一次请求。这个机制比基于WebSocket的实时推送稳对网络抖动更友好。可观测性在大厂面试中的存在感越来越强面试题从什么是三色指标到怎么排查接口突然变慢了都有。三色指标就是Metrics、Logs、Traces对应Prometheus ELK SkyWalking。一条常见排查链路是先用SkyWalking查慢Trace找到耗时最高的Span再去ELK搜该Trace ID对应的业务日志最后用Prometheus看服务所在主机的CPU、内存和JVM指标。把这条链路讲完整比背十个框架名字都管用。可观测性不是额外功能而是当你把服务拆成几十个小应用后唯一能让你在半夜两点定位问题的依赖工具。微服务板块我还额外收录了微服务之间的调用方式这道基础题同步有REST和Dubbo的RPC异步走MQ。同步调用的优点是直观但链路长时延迟累积严重异步解耦后吞吐量高但事务边界和一致性复杂。业界主流做法是内部高吞吐场景用Dubbo接口对App开放用REST异步事件用MQ--三种调用方式并存而不是只选一种。4. 高并发板块120道场景题怎么答才不翻车4.1 秒杀、订单库存、IM消息三大经典场景拆解高并发题目里最常出现的三个场景是秒杀、订单库存和IM消息推送。这三类题基本覆盖了缓存、消息队列、限流、分布式锁、数据库优化的所有考点。秒杀系统的核心约束是瞬时流量是日常的十倍甚至百倍但库存只有固定的数量。思路一定要讲出层层削峰的逻辑CDN静态化商品页、网关层限流、Redis预扣库存、MQ异步下单、数据库最终扣减。其中最容易出彩的是库存扣减的方案。先用Redis的Lua脚本原子扣减库存到0抢到名额的用户再往MQ里发一条下单消息消费者端用数据库唯一索引或版本号做幂等最终保证没有超卖也没有少卖。所有方案都允许你说我们是这么做的但必须说清楚为什么这样设计。订单和库存场景我前面提过分布式事务这里再补充一个高频追问数据库库存字段用int够不够扣减SQL怎么写才有高性能。答案是用update stock set stockstock-#{count} where id#{id} and stock#{count}这样的原子条件更新配合乐观锁版本号。性能瓶颈在行锁竞争上因此扣减集中在库存服务内部不要跨服务频繁加分布式锁。ERP库存场景的思路也类似高并发写库之前先合并请求用状态机区分入单、锁定、扣减、回滚各阶段。IM高并发场景考察的是推送链路设计。Kafka或者RocketMQ负责事件分发客户端通过WebSocket长连接接入。连接层是无状态的可以水平扩展关键在于把谁在线的映射关系放到Redis里推送时先从Redis找到该用户所在的连接节点再把消息投递给该节点。如果用户不在线消息进离线存储上线后拉取未读消息。答这道题时最容易出错的是漏掉消息顺序性单聊消息可以用相同的key打到一个分区保证顺序群聊则需要将发送者ID作为分片键。4.2 限流与削峰从算法到落地的完整链路限流算法面试题虽然基础但真正会做出取舍的人不多。固定窗口计数器有临界突变问题滑动窗口解决了部分漏桶算法可以平滑流量但无法应对突发令牌桶算法允许突发流量是业界最常用的方案。Guava的RateLimiter就是令牌桶实现Sentinel默认采用滑动窗口Nginx也内置了漏桶实现。我在答案中专门列了一张对比表如果你只需要保护DB漏桶更合适如果希望允许短时抢购的突发流量令牌桶更合适。削峰这块RocketMQ和Kafka都有各自的顺序消费和批量消费机制。如果消息量在峰值达到每秒几万条消费者侧的优化比生产者更重要批量拉取、批量提交offset、消费逻辑里减少远程调用。Kafka的高吞吐不是白来的但用不好也是在面试中区分用过和用过且懂的分水岭。比如如何保证消息不丢失从生产者端要开启ackall配合重试机制Broker端要配置副本数大于1且minISR大于1消费者端要等业务逻辑执行成功后才提交offset。这三层缺一不可。这里有一个常被忽略的点限流和削峰要和业务SLA挂钩。不是所有流量都值得削峰微博热搜和电商大促的做法就完全不同。大促可以接受短暂排队但IM场景延迟增加几秒就是事故。所以高并发设计没有一个通用的模板面试官要听到的是你针对具体业务做的参数选择比如我们设定QPS上限为2000超出部分进入排队等待是因为下游数据库单库的支撑能力在2500左右留出20%余量这种具体数字。4.3 JVM与数据库调优高并发系统的最后一公里高并发题目做了很多最终还是要落到JVM和数据库的调优上。JVM的高频题是JVM内存结构GC调优实战线上OOM怎么排查。现在面试官基本不看你能背出几个收集器而是直接抛出场景线上服务Full GC频繁怎么办。标准排查链路是先用jstat看GC频率和内存使用率再用jmap dump出堆内存通过MAT分析大对象和泄漏点。如果堆没问题再看代码里是否有大循环导致撑爆线程栈以及是否存在内存缓存放了无限增长的数据。数据库调优的核心是索引和SQL。面试题一个慢查询SQL怎么优化的标准答法分四步走先看执行计划是否走了全表扫描和文件排序再看索引设计是否符合最左前缀原则然后检查是否发生了隐式类型转换导致索引失效最后确认是否可以用覆盖索引减少回表。这套步骤用在真实压测调优过程中能解决九成的慢查询问题。高并发下的数据库瓶颈还有一个隐藏考点连接池大小。很多人以为连接数越大越好实际上连接过多会导致数据库CPU上下文切换膨胀。PostgreSQL官方给出的建议是连接数等于核数乘以2加磁盘数对于MySQL的常规SSD场景几十个连接已经足够支持每秒几千次的事务处理多余的连接只会拖垮性能。把连接池的配置当成面试题的一部分能体现出你真正考虑过资源配比。5. 刷题方法、时间规划与避坑手册5.1 350道题的刷题顺序与时间分配我建议的刷题顺序和上面章节的顺序不同先从高并发场景题开始因为场景题最容易建立全局视角再回到分布式体系化补基础最后再做微服务治理题。原因很简单场景题能让你知道各种技术组件是为什么存在的。比如先看秒杀方案你才会真正理解Redis为什么会话中锁、MQ为什么叫削峰填谷反过来直接背Redis数据结构这类基础题容易越背越焦虑。时间分配上如果你是在职准备每天两小时六周为一个周期。前两周专门刷高并发场景题并结合一个实际项目把这些组件画进系统架构图中中间两周攻分布式事务、分布式锁、分布式缓存三座大山每个方向至少写一个笔记做方案对比最后两周做微服务治理题把网关、熔断、服务拆分串成一条完整的知识链路。最后留一周时间总复习重新过一遍自己整理的题注而不是重新背诵全文。在职准备最大的敌人是碎片化。我整理的时候给自己的要求是每道题必须有一句话结论 展开细节 面试官追问应对这样上下班路上直接看笔记不用再临时翻博客。比如分布式锁那题一句话结论是Redis锁适合大部分场景但主从切换存在锁丢失风险强一致性场景应该用ZooKeeper展开细节是Redisson watch dog的续期机制追问应对是RedLock的争议点。5.2 系统设计题答题框架防止被连环追问打乱节奏系统设计题是350道题里最难临场发挥的部分比如设计一个支持百万并发的直播间弹幕系统设计一个短链系统。我的答题框架固定为六步明确需求边界、估算规模、制定核心流程、选择存储组件、识别瓶颈与优化、画出架构图。以弹幕系统为例。先确认是只做文本弹幕还是包含礼物特效然后估算在线人数和每秒吞吐量。存储上实时弹幕用Redis的有序集合按消息序号排序滚动展示窗口内的数据回放弹幕落到ClickHouse或者HBase。消息分发走WebSocket长连接服务端通过Redis的发布订阅或者消息队列广播。瓶颈在单节点WebSocket的连接数上限、广播风暴、以及弹幕排序的实时性。这套框架最大的作用是防止被连环追问打乱节奏。我们习惯性地先讲方案A结果面试官从方案A的缺点切入越问越偏最后把自己逼进死胡同。用框架答的好处是你每一步都有明确的目的面试官不管从哪一步切入你都还有上下文知道接下来要到哪一步。5.3 整理过程中踩过的坑和给后来者的建议这份350道题从我起意到最终成稿中间踩过一些坑这几条经验一定值得分享。第一不要迷信大厂官方真题来源。市面上的面经鱼龙混杂同一道题在不同出处里答案质量差别很大。我只相信两类来源一手面经中带完整回答的帖子以及官方博客或源码解析文章。很多Java面试题库只是把知识点洗了一遍稿回答里还掺着明显错误比如把RabbitMQ和RocketMQ的事务消息混为一谈。第二整理题目时必须自己写一遍答案哪怕只是写大纲。因为一旦直接收藏别人的答案大脑会误以为自己已经掌握等到面试时组织语言才发现思路是断的。我的习惯是先做题再对答案给自己模拟一个面壁五分钟写下自己会怎么答、漏掉了哪些点再对照参考答案补充。这个过程比单纯刷十道题都有效。第三高并发题目不要只啃并行编程一定要动手压测。面试官问JVM参数、问线程池配置如果你没有压测数据支撑答案就只是背诵。我整理期间用JMeter和wrk对我自己搭的一个Spring Boot服务做了基线压测把线程池大小、数据库连接池、Redis缓存命中率三个变量分别调整记录了下QPS和TP99的变化。这些数据在面试时直接说出来可信度完全不是一个级别。第四注意知识的体系化串联。我最后整理出的目录不是按题目序号罗列而是按从单机到分布式会遇到什么问题、每个问题有哪些解法、各解法怎么选型组织起来的。面试官问分布式事务时你能从2PC一路讲到Saga、讲到本地消息表、讲到业务设计如何规避这种横向串联能力才是350道题背后的核心价值。6. 面试现场的经验沉淀刷完这350道题之后我和几位大厂面试官朋友聊过一次大家一致认可的结论是面试的本质是用有限的问题探测你知识的深度和广度。深度靠项目经验广度靠知识体系。整理这份题的目的不是押中题目而是逼着自己把平时散落的知识重新编排一遍。如果你时间紧迫至少把这350道题中的三个必考方向学透分布式锁与缓存的一致性方案、服务拆分与治理思路、高并发场景题的标准答题框架。这三个方向占据了技术面至少一半的问题来源也能检验你的系统设计能力。最后再分享一个我实测有效的练习方法拿出一个真实的线上系统架构图把自己当成面试官对着图问如果这里出现故障怎么办这个模块为什么不拆成两个服务这个数据库表的数据量达到亿级之后怎么优化。自己出题考自己比任何题库都更能暴露知识盲区。