大廠面試來了，歡聚時代四年多經驗的Java面經

前言（也就是廢話）

今年年底，額，不對，應該說是去年了，我開始進行了一個多月的面試之旅，

面試的公司并不多，但從體量上來看，基本算是一二三線的大廠都囊括了，其中還包括BAT，當然，最后我也是順利的拿到了offer，雖然不是很理想，但我也挺滿意的，畢竟對我這種一直向往大廠的人來說，能進大廠已經算是很好的一次職業躍遷，在這個程序中，我也積累了不少面試經驗，并且跟很多朋友交流過，不少人都說讓我寫篇面經分享下經驗（其中也就幾個人），

我這個人呢，別的優點不說，朋友的善意請求我基本都很少推辭的，既然他們都這么熱切的請求了，那我也不負君期，舍棄一天假期來寫篇實戰面經分享下，

個人背景

好了，不說廢話了，先介紹一下個人背景，本人是17年畢業的，算到去年年底的話大概是四年半的作業經驗，我當時第一個面試的公司是廣州這邊的歡聚時代集團，也就是yy直播的前身，后來還面試了位元組、Lazada、騰訊、網易等公司，最后拿到歡聚和網易的offer，結果不算圓滿吧，但怎么說呢，體驗這么一圈下來，感覺大廠的面試難度也沒想象中那么夸張，其中位元組和Lazada我都是在技術終面被刷的，詢問過內推的朋友，可能未必是技術方面的原因，當然，這是后話了，我想說的是，就算是面試大廠，只要準備充足的話，還是可以從容應對的，

每一次面試完之后我都有做問題的記錄和復盤，基于篇幅原因，本文只會分享歡聚的面經，其他公司的面經后面再給大家整理好了，

歡聚時代一面（1h）

先做下自我介紹，固定環節

面試官：既然你用Java語言，那我們先講點Java基礎的東西吧，你說下Java有哪些鎖？

按斬訓制區分的話，Java中包含的鎖可以分為公平鎖和非公平鎖、樂觀鎖和悲觀鎖，獨占鎖和共享鎖，還有什么無鎖，偏向鎖，輕量鎖，重量級鎖之類的吧，比如Synchroized升級的程序中就涉及到這幾種鎖的轉換，大概就這些吧

面試官：好，那你說下Synchroized的升級程序？

這個應該是基本的八股文了吧，不用多說

面試官：用過HashMap吧，它的存盤結構是怎樣的？

不用多說，八股文最常見的，1.8之前的版本就是陣列加鏈表，1.8之后鏈表長度達到8的閾值轉成紅黑樹，當然，回答的時候盡量不要這么簡單，可以加多點料，比如說下為什么1.8之后這么轉換，有什么優點之類的，充充面子，給面試官有個我們基礎還可以的印象

面試官：Volatile用過吧 ，有什么作用

修飾變數，保證多執行緒下修改共享變數對其他執行緒可見；禁止指令重排序

面試官：Volatile是怎么保證可見性的，原理是什么

基于快取一致協議(MESI)

面試官：執行緒池有哪些引數，有什么作用，運行程序如何

基礎八股文，不多說

面試官：拒絕策略有哪些，你們用的是哪個

CallerRunsPolicy：執行緒池之外的執行緒直接呼叫run方法執行，除非執行緒池shutdown

AbortPolicy：直接丟棄任務，拋例外，默認策略

DiscardPolicy ：丟棄任務，不報錯

DiscardOldestPolicy：拋棄阻塞佇列最早的那個任務，把最新的任務重新放到佇列中

面試官：有哪些阻塞佇列，可以不斷加任務的（SynchronousQueue），如果用SynchronousQueue，有兩個任務進來，哪個能進佇列，還是都不行

取決于執行緒池情況，這個佇列不保留任務的，有任務被提交就直接轉發給執行緒或創建新執行緒執行，如果最大執行緒數滿了，不會進佇列

**面試官：執行緒池如果執行緒空閑，哪個引數可以設定多久銷毀 **

keepAliveTime

面試官：看到你簡歷上專案用了mq啊，為什么用RocketMQ，不用其他，說下選型原因

上家公司的專案是電商系統，從性能和業務上綜合考慮，RocketMQ比較適合，也足夠用，Kafka的話雖然性能更高，但功能較為單一，總的來說，在性能滿足需求的情況下，大資料、日志處理場景基本選用Kafka，業務處理相關選擇RocketMQ

面試官： 你們專案用的是哪個垃圾收集器？

CMS

面試官：為什么用CMS，不用G1？

歷史原因，一開始創建專案用的就是CMS，團隊人員也很少G1方面的調優經驗

面試官：CMS有什么缺點你知道嗎？

對CPU敏感，如果CPU數量少，吞吐量會下降很多；

無法處理浮動垃圾，并發清除階段用戶執行緒還在執行，可能會產生浮動垃圾，達到某種程度就會出現"Concurrent Mode Failure"，然后導致了一次full gc的產生

面試官：針對CMS產生的浮動垃圾，有什么辦法

可以設定一個引數-XX:CMSFullGCsBeforeCompaction，表示CMS還要再執行多少次full GC才會做壓縮，默認是0就可以，

面試官：什么時候會發生老年代的GC？

老年代發生垃圾回收說明觸發了FULL GC，一般是老年代空間不足或者呼叫System.gc出發

面試官：你有沒有遇到過線上的一些故障什么的，舉個例子

排除網路斷電等抽風的情況，一般線上問題都是業務代碼出現問題或者訪問量過高導致的，檢查的方式也比較通用，就是經典的top命令查看例外的執行緒，然后再根據是否是VM Thread決定用jstack 還是jstat 命令作進一步的排查

面試官：說下MySQL吧，你了解它的索引結構嗎？

資料庫必問到的索引八股文，B+樹

面試官：主鍵索引和非主鍵索引區別，索引覆寫怎么回事？

在innodb引擎中，非主鍵索引的葉子節點存放的是主鍵的值，而主鍵索引的葉子節點存放的是整行資料，如果沒有發生索引覆寫的情況，根據非主鍵索引查到對應的資料還需要到主鍵索引做一次回表查詢，

索引覆寫指的是一個索引包含了所有需要的欄位，不需要回表查了

面試官：如果有個聯合索引a,b，然后order a asc, b desc，會用到索引嗎

8.0之后的版本可以，之前的版本不支持desc排序

面試官：你們是怎么做sql優化的？

一般來說，針對sql的優化都是在業務代碼開發前就要做好的，除了基本的表欄位設計，在開發的程序還要針對業務方法輸出對應的sql陳述句，然后做好對應的sql review以及explain分析，同時還要考慮到業務的訪問量，如果過高的情況下是否需要走強制索引之類的優化

面試官：你用過Redis做分布式鎖，那你說說Redis分布式鎖的核心要保證哪些因素？

加鎖，解鎖，給鎖設定超時時間

面試官：分布式鎖如果執行緒拿不到鎖，直接就回傳嗎

不是，可以設定等待時間，比如Redisson就支持

面試官：分布式鎖如果master掛了，然后鎖沒有同步到其他機器，這時別的執行緒也拿到鎖了，怎么辦

Redis做分布式并非絕對安全，最保底的方式就是保證業務冪等

面試官：如果鎖即將過期，但業務沒處理完，該怎么處理

可以參考Redission的看門狗設計，就是定時對即將失效的鎖續期

面試官：冪等性和分布式鎖是同時要的嗎，為什么都有了冪等性還要加鎖

分布式鎖可以防止用戶誤操或者流量過高的情況，如果完全由業務冪等保底，可能會讓流量都達到db（很好的問題）

面試官：你簡歷上寫了快取例外的處理方案，那你說說快取穿透是什么樣子，怎么處理，跟快取雪崩有什么區別？

快取穿透：指快取和資料庫中都沒有的資料，這樣每次請求都會去查庫，不會查快取，如果同一時間有大量請求進來的話，就會給資料庫造成巨大的查詢壓力，甚至擊垮db系統，

一般解決方案有兩種：

1、快取空物件，但設定一個較短的時間，避免占用大量記憶體

2、布隆過濾器

快取雪崩：大量的key同一時間失效，導致流量都打到db

解決方案一般是設定給key設定隨機過期時間，或者互斥鎖的方式抵擋請求

面試官：專案有用到布隆過濾器嗎，如果用的話要多大記憶體

沒用到，說不上來，但也別這么直接，可以適當延伸一下，比如說經過綜合考慮，專案場景在這方面不需要做那么復雜的功能，或者是運維層面做了大量的例外請求攔截之類的，別讓面試官覺得你這方面沒什么思考，

面試官：你簡歷上還寫用了Spring，那你了解Spring AOP的原理嗎？

常見的八股文，基于Java動態代理，簡單描述下就好

面試官：如果一個類有兩個方法加了注解，然后一個呼叫另一個方法，那個方法的注解會生效嗎？

不會，因為同個類的話不是代理物件呼叫方法

面試官：說說專案方面吧，你簡歷上的領取優惠券有哪些流程，為什么用快取還要接近100ms的rt

引入了RocketMQ異步入庫的方式做削峰，防止流量過高的時候介面RT過高，至于為什么還接近100ms，是因為領取優惠券的邏輯一般是以券包方式，也就是同時領取多張優惠券，判斷的邏輯比較多，所以在高峰期會耗時點，

面試官：你寫了訂單資料是以用戶id維度分表，是基于什么考慮

業務場景需要滿足用戶可以查看自己訂單

如果查的維度是其他欄位，比如商品id，怎么辦

可以把訂單資料放es，或者定時任務將資料加到一張寬表

面試官：你們的專案每臺機設定最大多少執行緒訪問，有測過可以支撐多大的訪問量嗎

見鬼，剛好那時候腦子發昏不記得，所幸轉換了個思路，表達我們專案最高cpu也就達到百分之30，說明還可以撐起至少一倍的訪問量，我真聰明啊

印象中后面又問了幾道專案方面的問題，然后就結束了面試，總的來說，第一面的問題難度不算高吧，雖然針對的點比較多，但也基本是常見的八股文，專案場景方面沒什么考究，準備好的話還是很好面對的，不出意外，第二天hr那邊就通知我一面通過，然后就約了二面的時間，

二面（1h）

一面隔了一個星期左右就開始第二輪面試，同樣也是遠程視頻，不過跟第一面不同，這一面考察的大多跟專案有關，所以，在面試前對于專案方面的準備是必須下功夫的，

不用問，剛開始肯定是自我介紹了，介紹完面試官眉頭緊鎖了將近一分鐘才開口.........

面試官：看你的簡歷，你在上家公司也呆了兩年了，為什么要這個時候出來找機會

這點不用說啦，前爸爸不都說了嗎，要么錢少了，要么受委屈了，當然面試的時候肯定不能這么輕浮，就按照常規的說法，比如說個人發展，職業規劃什么的說下就好

面試官：你覺得現有的公司滿足不了你了嗎

是的，這也是我長久以來的考慮（廢話，不然我閑的蛋疼來面試）

面試官：你說你看過jdk原始碼，你覺得哪個設計驚艷了你

這個因人而異，我就針對比較熟悉的AQS部分和HashMap索引設計那塊做了講解

面試官：快取血崩和穿透該怎么做

一面就問過了，照著背就行

面試官：你簡歷上寫了sql優化，那你是怎么針對索引做設計的

常規的八股文，盡量滿足常用查詢的欄位走索引，然后多用explain做分析就可以規劃大部分的情況，

后面的問題基本都是專案方面的細節了，比如優惠券怎么防刷，作業中你覺得有所成就的是哪一次，做了什么，這些問題沒有參考答案，每個人的專案不同，作業經歷也不同，只要針對自己的實際情況回答就可以，

不過，這個程序還是有幾點值得跟大家分享下，就是分表遷移方面和高并發突發流量的問題，

因為筆者之前所負責的專案是電商系統，榷訓量達到百萬級別，對訂單那部分做了分表的處理，也算是技術上的亮點吧，簡歷上肯定是著重說明了，所以面試的時候也是一直被詢問這兩方面的場景，

分表的話呢，我們之前是把訂單的資料從單表同步到100張新表，基于用戶id做sharding key，遷移資料的程序，需要考慮到資料同步的一致性，以及不對現有的業務流程造成影響，所以我們采用的是訂閱binlog的方式來遷移資料，算是比較常規的方案，

但怎么說呢，雖然方案很常見，但實際操作的時候你會發現需要考慮的點非常的多，比如歷史資料和增量資料的同步問題，是停服還是不停服遷移，資料遷移一致后該怎么切換新系統，以及新系統上線后出現例外資料該怎么回滾回舊系統的問題等等，如果有同學做過分表遷移的話，這些方面的問題應該都是頭疼過的，當然，你越頭疼的點面試官就越是喜歡考究，所以，這方面的技術處理事先要考慮到各種可能性，你才能越有余力應付各種刁鉆的面試題，

除此之外，筆者所從事的電商專案也包含了秒殺那部分的功能，雖然QPS不高，但也需要做好秒殺系統的常規處理，比如限流，高并發扣減庫存，保證不超賣等，

以我個人的經驗來看，處理秒殺的高并發場景無非兩種方案，要么同步，要么異步，實際操作無非就是加機器或者是放到佇列等待，當然，實際要考慮的點非常的多，在高流量下所有的業務缺陷都會被無限放大，你需要考慮各種例外的情況做好預防措施，還有補償機制，限于篇幅，我無法在這里給大家講解太多，而且我本人也并非對所有的場景有處理經驗，只能介紹幾點思路讓大家去思考，

比如限流方面有什么策略，怎么防止大量的惡意請求；

扣減庫存那里是直接扣db的庫存資料，還是預減庫存，如果是預減庫存的話，Redis減了庫存但db沒減怎么辦；

秒殺的程序有些服務如Redis掛了，該怎么處理；

流量突然增大，大到某個商品的訪問量超過了Redis的單機閾值怎么辦；

如果引入訊息佇列做削峰組件，那么消費過慢導致用戶一直等待怎么處理等等，

雖說實際中我們基本沒有機會遇到那么大的訪問量，但你無法預防面試官是不是會考察，所以，如果你的專案中涉及到高并發場景的話，我是比較建議你在這些方面去下點功夫準備的，

接著說面試吧，問完了專案方面的東西，也基本沒什么技術題了，剩下的算是一些軟實力方面的問題，比如為什么寫博客啊；博客訪問量挺高的，是有專門運營過嗎；還有未來有什么職業規劃之類的，這些問題也是因人而異，雖說沒什么難度，但事前準備的好點還是更利于你面試的程序表達流暢的，所以，也建議大家可以多準備下軟實力方面的題，

結論：這一面八股文問的不多，專案方面問的比較多，軟實力方面也略有涉及，總的來說，難度是有的，面試的流程也挺順利，幾天后就通知面試通過，

三面（2h）

三面的面試官是歡聚的技術總監，也是視頻面試，這一面沒問技術問題，更多像是在聊天一樣，說實話，面試官是真能聊啊，整個面試程序長達兩個小時，他一直在介紹歡聚時代的一些歷史以及我面試崗位那個部門的業務情況，同時還對我未來的技術方向做了一些建議，讓我受益匪淺，總的來說，這一面雖然在技術面試上沒什么識訓，但能遇到這么一位熱心的面試官也算是我的運氣了，這里不勝感激，可惜后面有更好的offer，我也沒機會跟他做同事了，

hr面

hr面也沒什么好說的，交流了我的職業情況和期待薪資，幾天后給完流水就發了offer，

總結

整個面試程序就大概是這樣了，我想對大家來說，看完文章有識訓的可能是一面和二面的分享，總的來說，歡聚的技術面試難度不算很高，都是比較常規的面試考察點，我個人的話還是那句話，只要事先準備充足，還是可以從容應對的，

個人體會上的話也沒什么好說的，畢竟整個程序比較順利，沒什么刁鉆的題，后面我還會寫幾篇面經介紹下我面試其他公司遇到的難題，希望能幫到各位看官少遇點坑，好了，今天就這樣了，我們下期再見，

如果您覺得文章有用的話，歡迎點個推薦支持一下，這將是對我創作的最好鼓勵！

作者：鄙人薛某，一個不拘于技術的互聯網人，喜歡用通俗易懂的語言來解構后端技術的知識點，想看更多精彩文章的可以關注我的公眾號，微信搜索【鄙人薛某】即可關注