前言(也就是廢話)

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

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

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

個人背景

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

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

歡聚時代一面(1h)

先做下自我介紹，固定環(huán)節(jié)

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

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

面試官：好，那你說下Synchroized的升級過程?

這個應(yīng)該是基本的八股文了吧，不用多說

面試官：用過HashMap吧，它的存儲結(jié)構(gòu)是怎樣的?

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

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

修飾變量，保證多線程下修改共享變量對其他線程可見;禁止指令重排序

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

基于緩存一致協(xié)議(MESI)

面試官：線程池有哪些參數(shù)，有什么作用，運行過程如何

基礎(chǔ)八股文，不多說

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

CallerRunsPolicy：線程池之外的線程直接調(diào)用run方法執(zhí)行，除非線程池shutdown

AbortPolicy：直接丟棄任務(wù)，拋異常，默認策略

DiscardPolicy ：丟棄任務(wù)，不報錯

DiscardOldestPolicy：拋棄阻塞隊列最早的那個任務(wù)，把最新的任務(wù)重新放到隊列中

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

取決于線程池情況，這個隊列不保留任務(wù)的，有任務(wù)被提交就直接轉(zhuǎn)發(fā)給線程或創(chuàng)建新線程執(zhí)行，如果最大線程數(shù)滿了，不會進隊列

**面試官：線程池如果線程空閑，哪個參數(shù)可以設(shè)置多久銷毀 **

keepAliveTime

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

上家公司的項目是電商系統(tǒng)，從性能和業(yè)務(wù)上綜合考慮，RocketMQ比較適合，也足夠用，Kafka的話雖然性能更高，但功能較為單一?？偟膩碚f，在性能滿足需求的情況下，大數(shù)據(jù)、日志處理場景基本選用Kafka，業(yè)務(wù)處理相關(guān)選擇RocketMQ

面試官：你們項目用的是哪個垃圾收集器?

CMS

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

歷史原因，一開始創(chuàng)建項目用的就是CMS，團隊人員也很少G1方面的調(diào)優(yōu)經(jīng)驗

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

對CPU敏感，如果CPU數(shù)量少，吞吐量會下降很多;

無法處理浮動垃圾，并發(fā)清除階段用戶線程還在執(zhí)行，可能會產(chǎn)生浮動垃圾，達到某種程度就會出現(xiàn)"Concurrent Mode Failure"，然后導致了一次full gc的產(chǎn)生

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

可以設(shè)置一個參數(shù)-XX:CMSFullGCsBeforeCompaction，表示CMS還要再執(zhí)行多少次full GC才會做壓縮，默認是0就可以。

面試官：什么時候會發(fā)生老年代的GC?

老年代發(fā)生垃圾回收說明觸發(fā)了FULL GC，一般是老年代空間不足或者調(diào)用System.gc出發(fā)

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

排除網(wǎng)絡(luò)斷電等抽風的情況，一般線上問題都是業(yè)務(wù)代碼出現(xiàn)問題或者訪問量過高導致的，檢查的方式也比較通用，就是經(jīng)典的top命令查看異常的線程，然后再根據(jù)是否是VM Thread決定用jstack 還是jstat 命令作進一步的排查

面試官：說下MySQL吧，你了解它的索引結(jié)構(gòu)嗎?

數(shù)據(jù)庫必問到的索引八股文，B+樹

面試官：主鍵索引和非主鍵索引區(qū)別，索引覆蓋怎么回事?

在innodb引擎中，非主鍵索引的葉子節(jié)點存放的是主鍵的值，而主鍵索引的葉子節(jié)點存放的是整行數(shù)據(jù)，如果沒有發(fā)生索引覆蓋的情況，根據(jù)非主鍵索引查到對應(yīng)的數(shù)據(jù)還需要到主鍵索引做一次回表查詢。

索引覆蓋指的是一個索引包含了所有需要的字段，不需要回表查了

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

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

面試官：你們是怎么做sql優(yōu)化的?

一般來說，針對sql的優(yōu)化都是在業(yè)務(wù)代碼開發(fā)前就要做好的，除了基本的表字段設(shè)計，在開發(fā)的過程還要針對業(yè)務(wù)方法輸出對應(yīng)的sql語句，然后做好對應(yīng)的sql review以及explain分析，同時還要考慮到業(yè)務(wù)的訪問量，如果過高的情況下是否需要走強制索引之類的優(yōu)化

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

加鎖，解鎖，給鎖設(shè)置超時時間

面試官：分布式鎖如果線程拿不到鎖，直接就返回嗎

不是，可以設(shè)置等待時間，比如Redisson就支持

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

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

面試官：如果鎖即將過期，但業(yè)務(wù)沒處理完，該怎么處理

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

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

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

面試官：你簡歷上寫了緩存異常的處理方案，那你說說緩存穿透是什么樣子，怎么處理，跟緩存雪崩有什么區(qū)別?

緩存穿透：指緩存和數(shù)據(jù)庫中都沒有的數(shù)據(jù)，這樣每次請求都會去查庫，不會查緩存，如果同一時間有大量請求進來的話，就會給數(shù)據(jù)庫造成巨大的查詢壓力，甚至擊垮db系統(tǒng)。

一般解決方案有兩種：

1、緩存空對象，但設(shè)置一個較短的時間，避免占用大量內(nèi)存

2、布隆過濾器

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

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

面試官：項目有用到布隆過濾器嗎，如果用的話要多大內(nèi)存

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

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

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

面試官：如果一個類有兩個方法加了注解，然后一個調(diào)用另一個方法，那個方法的注解會生效嗎?

不會，因為同個類的話不是代理對象調(diào)用方法

面試官：說說項目方面吧，你簡歷上的領(lǐng)取優(yōu)惠券有哪些流程，為什么用緩存還要接近100ms的rt

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

面試官：你寫了訂單數(shù)據(jù)是以用戶id維度分表，是基于什么考慮

業(yè)務(wù)場景需要滿足用戶可以查看自己訂單

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

可以把訂單數(shù)據(jù)放es，或者定時任務(wù)將數(shù)據(jù)加到一張寬表

面試官：你們的項目每臺機設(shè)置最大多少線程訪問，有測過可以支撐多大的訪問量嗎

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

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

二面(1h)

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

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

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

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

面試官：你覺得現(xiàn)有的公司滿足不了你了嗎

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

面試官：你說你看過jdk源碼，你覺得哪個設(shè)計驚艷了你

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

面試官：緩存血崩和穿透該怎么做

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

面試官：你簡歷上寫了sql優(yōu)化，那你是怎么針對索引做設(shè)計的

常規(guī)的八股文，盡量滿足常用查詢的字段走索引，然后多用explain做分析就可以規(guī)劃大部分的情況。

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

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

因為筆者之前所負責的項目是電商系統(tǒng)，日活量達到百萬級別，對訂單那部分做了分表的處理，也算是技術(shù)上的亮點吧，簡歷上肯定是著重說明了，所以面試的時候也是一直被詢問這兩方面的場景。

分表的話呢，我們之前是把訂單的數(shù)據(jù)從單表同步到100張新表，基于用戶id做sharding key，遷移數(shù)據(jù)的過程，需要考慮到數(shù)據(jù)同步的一致性，以及不對現(xiàn)有的業(yè)務(wù)流程造成影響，所以我們采用的是訂閱binlog的方式來遷移數(shù)據(jù)，算是比較常規(guī)的方案。

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

除此之外，筆者所從事的電商項目也包含了秒殺那部分的功能，雖然QPS不高，但也需要做好秒殺系統(tǒng)的常規(guī)處理，比如限流，高并發(fā)扣減庫存，保證不超賣等。

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

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

扣減庫存那里是直接扣db的庫存數(shù)據(jù)，還是預減庫存，如果是預減庫存的話，Redis減了庫存但db沒減怎么辦;

秒殺的過程有些服務(wù)如Redis掛了，該怎么處理;

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

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

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

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

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

三面(2h)

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

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

總結(jié)

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

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