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模式底层怎么实现的。
先说方案分类。目前工业界能落地的方案基本就是两PC（2PC）、三PC（3PC）、TCC（Try 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 stock=stock-#{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的高吞吐不是白来的，但用不好也是在面试中区分"用过"和"用过且懂"的分水岭。比如"如何保证消息不丢失"，从生产者端要开启ack=all配合重试机制，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道题中的三个必考方向学透：分布式锁与缓存的一致性方案、服务拆分与治理思路、高并发场景题的标准答题框架。这三个方向占据了技术面至少一半的问题来源，也能检验你的系统设计能力。
最后再分享一个我实测有效的练习方法：拿出一个真实的线上系统架构图，把自己当成面试官，对着图问"如果这里出现故障怎么办""这个模块为什么不拆成两个服务""这个数据库表的数据量达到亿级之后怎么优化"。自己出题考自己，比任何题库都更能暴露知识盲区。
