攜程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天出結果。整體效率比較高，比很多公司快。