携程Java社招三面经验分享：中间件+分布式全面考察

背景介绍

先说说我的情况吧，4年Java开发经验，之前在一家旅游公司做后端开发，主要负责订单系统和支付系统。在那边待了4年，从初级开发做到了高级开发，但公司的技术栈比较老，还在用Spring Cloud Netflix那一套，很多组件都停止维护了，想找个技术氛围更好的平台。今年5月份，一个猎头联系我说携程在招Java开发，岗位是中间件方向，跟我之前做的分布式系统经验比较匹配，就约了面试。

整个面试流程是3轮技术面+1轮HR面，从第一轮到拿到offer大概用了2周。携程的面试效率还挺高的，每轮面完1-2天就出结果。

一面：Java并发+JVM+MySQL

Java并发编程

一面面试官是中间件团队的一个开发，上来先让我自我介绍，然后直接进入技术问题。Java并发是重点考察方向，问得比较深入。

线程池：面试官问"线程池的核心参数有哪些？各自的作用是什么？"我说了7个核心参数：corePoolSize（核心线程数）、maximumPoolSize（最大线程数）、keepAliveTime（空闲线程存活时间）、unit（时间单位）、workQueue（任务队列）、threadFactory（线程工厂）、handler（拒绝策略）。面试官追问了"线程池的工作流程是怎样的？"我说：先创建核心线程→核心线程满了放入队列→队列满了创建非核心线程→达到最大线程数执行拒绝策略。面试官又问"你在项目中用的什么队列？"我说我们用的是有界LinkedBlockingQueue，容量设置为500，拒绝策略用的是CallerRunsPolicy，让提交任务的线程自己执行，起到一定的限流效果。

锁机制：面试官问"synchronized和ReentrantLock的区别？"我从几个维度回答：实现方式（synchronized是JVM层面，ReentrantLock是API层面）、功能（ReentrantLock支持公平锁、可中断、多条件变量）、性能（JDK 6之后synchronized做了大量优化，性能差距不大）。面试官追问了"synchronized的锁升级过程？"我说：无锁→偏向锁→轻量级锁→重量级锁，并讲了每个阶段的触发条件和适用场景。面试官还问了AQS的原理，我说AQS核心是一个volatile int state和一个CLH双向队列，独占模式下state为0表示未锁定，为1表示锁定；共享模式下state表示可用资源数。

JVM调优

面试官问"你们做过JVM调优吗？怎么做的？"我说我们有一个支付服务经常出现Full GC，通过GC日志分析发现是老年代空间不足导致的。我们的解决方案是：调整堆大小（从2G调到4G）、调整新生代和老年代比例（从默认的1:2调到1:1.5，因为我们的对象大部分是短生命周期的）、使用G1收集器替代CMS。调优后Full GC频率从每天3-4次降到了每周1-2次。

面试官追问了"怎么排查OOM问题？"我说首先看Heap Dump文件，用MAT或者VisualVM分析，找出占用内存最大的对象和引用链。如果是内存泄漏，看哪些对象该回收但没有被回收；如果是内存溢出，看是否需要增加堆大小或优化对象创建。面试官还问了常用的JVM参数，我说了-Xms、-Xmx、-Xmn、-XX:+UseG1GC、-XX:MaxGCPauseMillis、-XX:+HeapDumpOnOutOfMemoryError等。

MySQL索引优化

面试官问"MySQL的索引结构是什么？为什么用B+树？"我说InnoDB用的是B+树，原因是：B+树的叶子节点通过链表连接，范围查询效率高；非叶子节点只存键值，一个节点能存更多键值，树更矮，IO次数更少；查询性能稳定，每次都要到叶子节点。面试官追问了"联合索引的最左前缀原则是什么？"我说联合索引(a,b,c)相当于创建了(a)、(a,b)、(a,b,c)三个索引，查询条件必须从最左列开始匹配。面试官还问了一个实际场景："如果查询条件是a=1 and c=3，能用到索引吗？"我说a列可以用到索引，c列不能，因为跳过了b列。但如果c列的区分度很高，可以考虑调整索引列的顺序。

二面：Spring Cloud+Dubbo+RocketMQ+分布式事务

Spring Cloud组件

二面面试官是团队的架构师，问的问题更偏架构和中间件。先问了Spring Cloud的组件使用情况，我说我们之前用的是Spring Cloud Netflix（Eureka+Ribbon+Hystrix+Zuul），现在正在迁移到Spring Cloud Alibaba（Nacos+Sentinel+Gateway）。面试官问"为什么迁移？"我说Netflix组件基本停止维护了，而且Alibaba生态的组件在中文社区支持更好，Nacos同时支持配置中心和服务注册，比Eureka+Config Server更简洁。

Dubbo vs Spring Cloud

面试官问"Dubbo和Spring Cloud的区别？你怎么选型？"我说Dubbo是RPC框架，Spring Cloud是微服务全家桶，两者不是完全对等的。Dubbo的性能更好（基于TCP的自定义协议），适合内部服务间高频调用；Spring Cloud生态更完善，适合快速搭建微服务架构。在实际项目中，如果对性能要求高、服务间调用频繁，选Dubbo；如果追求开发效率和生态完整性，选Spring Cloud。面试官追问了"Dubbo的负载均衡策略有哪些？"我说有Random（随机，默认）、RoundRobin（轮询）、LeastActive（最少活跃调用）、ConsistentHash（一致性哈希）。

RocketMQ原理

面试官问"为什么选RocketMQ而不是Kafka？"我说几个原因：RocketMQ支持事务消息，适合我们订单系统的最终一致性场景；RocketMQ的延迟消息功能我们用得很多（比如订单30分钟未支付自动取消）；RocketMQ的消息可靠性更高，支持消息追溯。面试官追问了"RocketMQ的事务消息是怎么实现的？"我说核心流程是：先发送半消息→执行本地事务→根据本地事务结果提交或回滚消息→如果长时间没有提交/回滚，Broker会回查本地事务状态。面试官又问了"RocketMQ怎么保证消息不丢失？"我说三个层面：Producer端用同步发送+重试、Broker端用同步刷盘+主从复制、Consumer端用手动ACK。

分布式事务

面试官问"分布式事务有哪些方案？各自的优劣？"我详细讲了三种主流方案：

2PC（两阶段提交）：强一致性，但同步阻塞，协调者单点问题，适合对一致性要求极高的场景。实际中很少直接用，XA就是2PC的实现。

TCC（Try-Confirm-Cancel）：业务层面的两阶段提交，每个服务要实现Try、Confirm、Cancel三个接口。优点是性能好、灵活性高，缺点是业务侵入性强、开发成本高。我们支付系统用的是TCC，通过Seata框架来实现。

Saga：长事务方案，每个步骤有对应的补偿操作。适合业务流程长、参与服务多的场景。优点是性能好、无阻塞，缺点是只有最终一致性，中间状态可见。

面试官追问了"你们实际项目中用的哪种？"我说支付系统用TCC，订单系统用RocketMQ事务消息做最终一致性，两个系统对一致性的要求不同，方案也不同。

三面：架构设计+高并发+线上问题+算法

项目架构设计

三面面试官是部门的技术负责人，问的问题更宏观。让我先讲了之前做的订单系统的整体架构，然后追问了几个关键设计决策。我说我们的订单系统是微服务架构，核心服务包括：订单服务、库存服务、支付服务、通知服务。服务间通过Dubbo RPC调用，异步场景用RocketMQ。面试官问"订单创建的完整流程是怎样的？"我说：用户下单→校验库存→锁定库存→创建订单→发起支付→支付回调→更新订单状态→释放库存/扣减库存→发送通知。每个步骤都有失败处理和幂等设计。

高并发方案

面试官问"如果秒杀场景下，瞬间10万QPS，你怎么设计？"我说了几层防御：第一层CDN+Nginx限流，过滤掉大部分无效请求；第二层Redis预扣减库存，只有库存充足的请求才进入下单流程；第三层消息队列削峰，下单请求先入队再异步处理；第四层数据库层面用乐观锁保证库存不超卖。面试官追问了"Redis预扣减库存怎么保证和数据库一致？"我说用Lua脚本保证原子性，下单成功后同步更新数据库库存，如果下单失败则回补Redis库存。同时有定时任务做数据对账，保证最终一致性。

线上问题排查

面试官问"你遇到过最棘手的线上问题是什么？怎么排查的？"我说有一次支付服务的接口突然变慢，P99从200ms飙升到5s。排查过程：先看监控发现是数据库查询变慢→看慢查询日志发现一条SQL执行时间异常→用EXPLAIN分析发现索引失效（因为用了函数导致索引列被包装）→修复SQL后恢复正常。但根因是有人提交了一段代码，在where条件里对索引列做了函数转换，导致全表扫描。面试官问"怎么防止这种问题再发生？"我说我们在代码评审环节增加了SQL审查，同时上线了SQL审计平台，自动检测慢查询和索引使用情况。

算法题

算法题是两道：TopK问题和二叉搜索树验证。

TopK：面试官问"从1亿个数中找出最大的100个。"我说了三种方案：小顶堆（维护大小为100的堆，时间复杂度O(nlogk)）、快速选择（基于快排的partition，平均O(n)）、分治+归并（适合分布式场景）。面试官让我写小顶堆的方案，我写了大概10分钟，面试官说没问题。

二叉搜索树验证：给定一棵二叉树，判断是否是合法的BST。我用中序遍历+前驱节点的思路，中序遍历BST的结果应该是严格递增的。面试官追问了"如果树很大，递归会栈溢出怎么办？"我说可以用Morris遍历，空间复杂度O(1)，或者用迭代方式的中序遍历。

HR面：职业规划+薪资+入职时间

HR面比较轻松，主要聊了职业规划、薪资期望和入职时间。职业规划方面，我说短期希望深入中间件领域，长期想往架构师方向发展。薪资方面，我报了一个期望范围，HR说携程的薪资结构是base+绩效+期权，具体要看定级。入职时间我说最快1个月。HR还问了有没有其他offer，我说还在面试其他公司，但携程是首选。

面试真题汇总

Java并发

1. 线程池的核心参数和工作流程

2. synchronized和ReentrantLock的区别

3. synchronized的锁升级过程

4. AQS的原理

JVM

5. JVM调优经验

6. OOM排查方法

7. 常用JVM参数

MySQL

8. B+树索引结构及优势

9. 联合索引的最左前缀原则

Spring Cloud与Dubbo

10. Spring Cloud Netflix vs Alibaba的迁移原因

11. Dubbo vs Spring Cloud的选型

12. Dubbo的负载均衡策略

RocketMQ

13. RocketMQ vs Kafka的选型

14. RocketMQ事务消息的实现

15. RocketMQ怎么保证消息不丢失

分布式事务

16. 2PC、TCC、Saga的区别和适用场景

17. Seata框架的使用

架构设计

18. 秒杀系统的高并发设计

19. Redis预扣减库存与数据库一致性

20. 线上问题排查经验

算法

21. TopK问题（小顶堆/快速选择/分治）

22. 二叉搜索树验证（中序遍历/Morris遍历）

心得体会与建议

1. Java基础一定要扎实。携程的面试对Java基础要求很高，尤其是并发和JVM。不是简单背八股文就能过的，要能结合实际项目讲清楚。建议准备的时候每个知识点都准备一个实际案例。

2. 中间件要深入理解原理。RocketMQ、Dubbo这些中间件，不仅要会用，还要能讲清楚底层原理。面试官会追问到源码级别的细节，比如RocketMQ的事务消息半消息机制、Dubbo的服务暴露和引用流程。

3. 分布式事务是高频考点。2PC、TCC、Saga三种方案一定要能讲清楚，最好能结合实际项目说明你们选了哪种、为什么选这种、遇到了什么问题。

4. 系统设计要有层次感。回答高并发问题的时候，建议从外到内分层回答：CDN/网关层→应用层→缓存层→消息队列层→数据库层。每一层做什么、怎么配合，要有清晰的逻辑。

5. 线上问题排查要有方法论。不要只讲结论，要讲排查过程：发现问题→定位范围→分析原因→验证假设→修复问题→预防措施。面试官更看重你的排查思路。

常见问题FAQ

Q1：携程Java面试重点是什么？

重点是Java并发、JVM、中间件（RocketMQ、Dubbo）和分布式事务。系统设计和高并发方案也会考，但不是每轮都有。

Q2：没有中间件经验可以面携程吗？

中间件团队的岗位对中间件经验要求比较高，但如果是业务开发岗位，了解基本原理就行。建议根据岗位要求调整准备重点。

Q3：携程面试算法难度怎么样？

中等难度，不是特别难。TopK、LRU、二叉树相关是高频题，建议重点练习这些经典题型。

Q4：携程的薪资水平怎么样？

携程的薪资在互联网公司中属于中等水平，4年经验大概在T5-T6级别。具体可以参考offershow上的数据。

Q5：面试流程大概多久？

我这次从第一面到拿到offer大概2周，每轮面完1-2天出结果。整体效率比较高，比很多公司快。