2019年7月底我還在實驗室啃《深入理解Java虛擬機》突然收到一個杭州座機打來的電話。接起來才知道是蘑菇街提前批的一面。說實話當時有點措手不及因為投完簡歷才三天根本沒想過會這么快好在提前批本身就是臨時起意的機會能走到哪兒是哪兒。后來這一面面了將近一個小時問的內容不算偏但每一塊都問得很細尤其是項目細節和Java基礎答得讓我印象深刻。這幾天陸續有學弟學妹問我當年提前批的情況干脆把這場蘑菇街一面完整復盤出來按面試問題我的答案復盤點評的結構寫希望能給準備校招后端崗位的同學一些參考。1. 提前批的節奏與我的準備狀態1.1 蘑菇街提前批的時間線回顧2019年的秋招比往年更早蘑菇街的提前批大概在7月中旬就開了。我當時是通過實驗室學長內推投的投遞的是Java后端開發崗位。內推后的第三天接到面試電話約在當天晚上七點電話面試。時間線大概是這個節奏7月中旬內推投遞簡歷投遞后第3天接到一面電話邀約一面電話面試約55分鐘面試形式電話溝通沒有共享屏幕手撕代碼通過口述思路事后發代碼鏈接完成這里提醒一句蘑菇街當時提前批和正式批是不沖突的提前批掛了還可以走正式批。所以不要因為準備不充分就放棄投遞提前批等于多了一次面試機會拼的就是一個早。1.2 我當時的復習重心接到面試電話之前我的復習已經持續了大概一個月。因為目標是后端開發崗所以復習重心分配得很明確刷題劍指Offer全部過了一遍LeetCode按高頻題刷了大概100道重點放在鏈表、二叉樹、動態規劃三類。Java基礎HashMap、ArrayList源碼級理解JVM內存模型和GC整理成腦圖。并發編程synchronized、ReentrantLock、volatile、線程池把原理和對比都寫了一遍。數據庫MySQL索引底層、事務隔離級別、MVCC、常見索引失效場景。中間件Redis的數據結構、持久化、緩存穿透/擊穿/雪崩。面的過程中我發現這種按主線復習臨時補充的策略是對的。蘑菇街一面并沒有問太偏門的內容全部落在Java后端開發的核心范圍內。換句話說只要認真準備過上述內容一面基本都能應對。2. 一面全程從自我介紹到項目深挖2.1 開場定調自我介紹怎么說電話接通后面試官簡單確認了身份直接讓我自我介紹。我的回答大概是這樣面試官您好我是XX大學軟件工程專業2020屆研究生研究生期間主要做Java后端開發方向。對Java基礎、并發編程、JVM和MySQL底層原理有過系統的學習平時用Spring Boot和MyBatis做項目。最近主要做了兩個項目一個是基于微服務的校園秒殺系統另一個是實驗室的設備借用管理平臺。其中秒殺系統涉及到高并發下的庫存扣減和緩存一致性設計是比較能聊的一個項目。復盤時回頭看這段自我介紹其實埋了兩個鉤子一是主動把話題引到并發和緩存二是強調秒殺項目可以深聊。面試官后續果然順著項目問了很多這比被動等他隨便問要舒服得多。我的經驗是自我介紹不用太長但一定要有意識地引導面試官去問你準備最充分的部分。2.2 項目深挖秒殺系統的緩存一致性設計面試官聽完自我介紹沒有問實驗室管理平臺直接問秒殺系統你剛才說秒殺系統涉及高并發說說最核心的難點你怎么解決的我當時把項目里的技術方案完整講了一遍。這里還原關鍵對話。面試官庫存扣減怎么設計的我最開始是直接操作數據庫每次下單都update庫存表并且加for update鎖。壓測的時候發現連接池滿得非?？霶PS頂到幾百就上不去了。后來改成兩層設計——先把庫存預熱到Redis用Redis的decr命令做庫存扣減扣減成功后再把下單請求丟進RabbitMQ由消費者異步創建訂單。面試官為什么選Redis的decr而不是數據庫悲觀鎖我數據庫的for update本質上是把一行記錄鎖住并發能力受限于數據庫的連接數和鎖等待時間。而Redis是單線程模型decr命令天然是原子的單機QPS可以支撐到十萬級別比數據庫判斷庫存再扣減要快得多。另外這里還有一個細節用戶維度我們用了Redis setnx做一人一單限制防止同一用戶秒殺多件。面試官緩存和數據庫的一致性怎么保證我用的Cache Aside Pattern也就是先更新數據庫再刪除緩存。讀到的時候如果緩存miss再從數據庫讀出來回填緩存。面試官為什么是刪除緩存而不是更新緩存我更新緩存需要算出最新的數據再寫進去成本比刪除高而且并發場景下兩個線程交替更新緩存和數據庫很容易導致緩存里終態錯誤。刪除緩存成本低即使刪早了下一次讀的時候重新從數據庫加載就行邏輯簡單可靠。面試官那刪除緩存失敗怎么辦我我們做了一個兜底緩存key設置了過期時間就算刪除失敗最終也會過期不會永久不一致。同時我們把刪除失敗的key寫入本地消息表通過RabbitMQ延遲隊列重試刪除。更完善的方案是訂閱MySQL的binlog用canal解析出數據變更事件再異步刪除對應緩存這樣完全不依賴業務代碼手動刪除。面試官對這個回答沒有再追問點了下頭就切到下一題。復盤下來項目這塊他能問到的點基本都被我提前準備過。這里最大的心得是項目深挖其實不是考你做得多牛而是考你對方案的理解深度。光說用了Redis不夠得說得出來為什么不用數據庫鎖Redis為什么合適刪緩存失敗會有什么問題怎么補救。把這些問題想通了項目環節基本穩了。2.3 面試官追問的意圖后來想想面試官在每個追問背后其實都在考察一件事項目到底是不是你自己做的你有沒有真正想過方案背后的取舍。比如緩存一致性問題如果只是背過先更新數據庫再刪除緩存這句話被問失敗怎么辦就露餡了。所以做項目的時候不能只看博客里怎么寫一定要親手把方案跑通把異常場景都模擬一遍。3. 基礎題問答實錄Java并發、JVM、MySQL項目聊了大概15分鐘之后面試官話鋒一轉進入基礎題環節。速度明顯加快基本是我問你答答完就下一題的節奏。3.1 Java集合與并發面試官HashMap的底層結構是什么樣的JDK 1.7到1.8有哪些變化我HashMap底層是數組加鏈表JDK 1.8之后引入了紅黑樹。當鏈表長度超過8同時數組容量達到64鏈表會轉為紅黑樹主要是為了處理hash沖突嚴重時鏈表過長、查詢效率從O(n)惡化的問題。擴容方面默認容量16負載因子0.75也就是元素個數超過閾值12時就擴容到原來的兩倍。JDK 1.8還有一個重要的優化擴容時不用重新計算hash而是看原hash值新增的那一位是0還是10就留在原位置1就放到原位置加舊容量的位置。另外1.7是頭插法并發擴容可能形成環形鏈表1.8改成尾插法避免了這個問題但HashMap本身線程不安全并發場景還是要用ConcurrentHashMap。面試官ConcurrentHashMap底層是怎么做線程安全的我1.7的時候是分段鎖內部維護多個Segment每個Segment繼承ReentrantLock不同段之間可以并行操作。1.8放棄了分段鎖改用synchronized加CAS鎖的粒度是桶也就是數組的每個槽位只有發生hash沖突的桶才會鎖住并發度更高。擴容時支持多線程協助遷移把一個大數組拆成多個任務分給不同線程去做。面試官volatile和synchronized有什么區別我volatile只保證可見性和有序性它會強制把修改立即寫回主內存同時通過內存屏障禁止指令重排序但它不保證原子性。synchronized保證原子性、可見性和有序性。所以像i這種操作光用volatile是不行的。volatile典型的應用場景是狀態標志位還有單例模式里的Double Check用volatile修飾instance防止JVM指令重排導致拿到未初始化完成的對象。面試官synchronized和ReentrantLock怎么選我synchronized是JVM層面的鎖ReentrantLock是JDK提供的API。ReentrantLock多了三個能力可以響應中斷、可以設置超時時間、可以創建公平鎖并且支持多個Condition條件隊列。JDK 1.6之后synchronized做了偏向鎖、輕量級鎖的優化性能差距已經很小。如果只是簡單的同步需求synchronized就夠了代碼更簡潔如果需要超時等待、可中斷、公平性控制就選ReentrantLock。這里有個插曲面試官對公平鎖這個點追問了一句公平鎖的底層怎么實現的我當時只說了一個大概ReentrantLock內部維護了一個等待隊列公平鎖會檢查隊列里有沒有排在前面的線程有就先讓前面的人獲取鎖。面試官沒再追問。后來我仔細研究了源碼AQS里是通過hasQueuedPredecessors()方法判斷當前線程是不是隊列頭部只有真正排在頭部的線程才有資格搶鎖。3.2 JVM內存與GC面試官JVM運行時數據區域有哪些哪些線程共享哪些線程私有我整體分五大塊。程序計數器、虛擬機棧、本地方法棧是線程私有的堆和方法區是線程共享的。JDK 8之后方法區被元空間取代元空間使用本地內存不再受JVM堆內存上限限制。對象實例和數組主要分配在堆上棧上分配是JIT在逃逸分析之后做的優化不是常規路徑。面試官垃圾回收怎么判斷對象可以回收我主流用的是可達性分析算法。從一組稱為GC Roots的根對象出發沿著引用鏈往下找沒有被引用鏈連接的對象就判定為可回收。GC Roots包括虛擬機棧中棧幀里的局部變量引用的對象、靜態變量引用的對象、常量池引用的對象、JNI引用的對象、被synchronized持有的對象。引用計數法因為無法解決循環引用的問題現在基本不會單獨用。面試官CMS和G1有什么區別我CMS是老年代垃圾收集器目標是低停頓用的是標記-清除算法整個過程分初始標記、并發標記、重新標記、并發清除四個階段其中只有初始標記和重新標記需要STW。缺點也很明顯標記-清除會產生內存碎片并發階段會占用CPU資源而且它無法處理浮動垃圾。G1則是把整個堆劃分成多個大小相等的Region既可以回收新生代又可以回收老年代通過維護每個Region的回收價值和回收成本做到可預測的停頓時間。G1在Java 9之后成為默認垃圾收集器它最大的特點是可以在回收過程中把Region里的存活對象復制到空閑Region里本質上是標記-復制不會產生碎片。JVM這塊我明顯感覺面試官比較滿意因為他在我答完之后說了一句JVM底子還可以。這可能是整場面試中我最舒展的一段。3.3 MySQL索引與事務面試官InnoDB的索引為什么用B樹我B樹有幾個特點比較適合數據庫場景。第一非葉子節點只存索引鍵值不存數據所以每個節點能存放更多的索引項樹的高度低一般三層就能存上千萬條數據也就是最多三次磁盤IO就能定位到葉子節點。第二葉子節點之間有雙向指針串聯天然支持范圍查詢和排序B樹就需要回溯父節點才能做范圍查詢。第三哈希索引雖然單點查詢快但不支持范圍紅黑樹和二叉樹在數據量大的時候樹太高磁盤IO次數太多了。面試官聯合索引遵循什么原則哪些情況會導致索引失效我聯合索引遵循最左前綴原則。比如建了(a, b, c)的聯合索引查詢條件里有a或者a、b或者a、b、c才能命中。失效場景常見的有對索引列做了計算、函數操作、隱式類型轉換使用like時前面帶百分號比如like %xx使用or連接非索引列聯合索引中不滿足最左前綴條件。面試官MySQL默認的隔離級別是什么MVCC是怎么實現的我默認是可重復讀RR。MVCC是InnoDB實現一致性讀的關鍵機制核心由三部分組成undo log版本鏈、read view、隱藏的trx_id字段。每行記錄上都有最近修改它的事務IDundo log記錄了歷史版本形成一個版本鏈。查詢時生成read viewread view里保存了活躍事務列表通過比較事務ID判斷當前查詢能看到哪個版本。區別在于讀已提交RC是每條語句生成一個新的read view可重復讀RR是第一次快照讀的時候生成后續復用同一個read view所以同一個事務里兩次查詢結果一致。面試官RR級別下怎么防止幻讀我主要通過兩個機制。一個是MVCC的快照讀第一次讀的時候生成read view之后復用即使別的事務插入了新數據當前事務看不到天然避免了幻讀。另一個是當前讀比如select ... for update需要通過間隙鎖gap lock和臨鍵鎖next-key lock來實現。間隙鎖鎖的是索引記錄之間的間隙讓其他事務無法在間隙內插入新的記錄從而防止幻讀?；A題環節到這里大概持續了25分鐘。面試官把Java、JVM、MySQL各自挑了最核心的幾個點來問沒有一上來就壓八股。給我的感覺是蘑菇街一面更看重能不能把原理講清楚而不是背了多少面試題。4. 計算機網絡與中間件快問快答基礎題之后面試官開始快問快答節奏明顯加快問題更零散像在掃知識點。4.1 TCP與HTTP細節面試官TCP三次握手為什么不是兩次我如果只需要兩次握手可能出現這種情況客戶端發送的SYN報文在網絡中滯留了很久客戶端認為它超時了沒有收到確認所以重發了SYN這一次正常完成了連接。但滯留在網絡中的那個舊SYN報文過了很久又到達了服務端服務端以為是一個新連接于是返回SYNACK給客戶端。如果只有兩次握手服務端這時就認為連接建立成功了會一直等待客戶端發送數據白白浪費服務端的資源。而三次握手中客戶端收到服務端的SYNACK之后并不會立即認為連接建立而是要再回一個ACK。如果服務端收到的是舊SYN的響應客戶端會發現這個連接不是自己期望的就不會回ACK服務端自然也不會建立連接。面試官四次揮手里TIME_WAIT為什么要等2MSL我兩個原因。第一確保最后一個ACK報文能夠到達對端如果ACK丟了對端會超時重傳FIN如果此時連接已經關閉就沒有辦法重發ACK了等一個2MSL可以保證ACK重傳的窗口足夠。第二經過2MSL的時間能讓本次連接產生的所有舊報文都在網絡中消失避免它們出現在未來某個相同的四元組連接里造成數據混亂。面試官HTTPS的握手過程了解嗎我HTTPS本質上是HTTP over TLS握手過程大致分幾步客戶端發起ClientHello攜帶支持的TLS版本、加密套件列表和隨機數服務端返回ServerHello選定加密套件和服務端隨機數同時下發證書客戶端驗證證書合法性然后生成預主密鑰用服務端證書里的公鑰加密發過去服務端用自己的私鑰解密出預主密鑰雙方通過三個隨機數協商出會話密鑰。之后雙方發送Finished消息確認握手成功后續應用層數據全部走對稱加密。TLS 1.3進一步簡化了握手把以往的兩個往返優化成一個往返。面試官HTTP常見的502和504有什么區別我502 Bad Gateway表示網關或代理服務器從上游服務器收到了無效響應簡單說就是上游服務器掛了或者返回了非法內容。504 Gateway Timeout表示網關在指定時間內沒有等到上游服務器返回響應也就是上游處理超時了。實際排查中502更多是后端服務進程崩潰或者重啟504更多是后端處理得太慢或線程池被打滿。4.2 Redis三大經典問題面試官Redis緩存穿透、擊穿、雪崩分別是什么怎么解決我穿透是查詢一個不存在的key緩存里沒有數據庫里也沒有請求直接打到數據庫惡意攻擊時能把數據庫打垮。解決方式是布隆過濾器先用bitmap把所有可能存在的主鍵存進去查不到的直接攔截或者對空結果也做緩存設置一個較短的過期時間。擊穿是某一個熱點key在過期瞬間大量請求同時打到數據庫。解決方式是熱點key不設置過期時間或者過期時間加一個隨機值再或者用互斥鎖讓同一個key只有一個請求去數據庫回源。雪崩是大量key在同一時間段集體過期導致流量瞬間打到數據庫。解決方式有過期時間增加隨機因子避免集中在同一時刻熱點數據不設置過期時間由后臺任務定時更新還可以做熔斷降級數據庫壓力大的時候直接返回默認值。面試官RDB和AOF怎么選我RDB是定時的全量快照文件緊湊恢復速度快適合做備份和主從同步但故障時可能丟失最后一次快照之后的數據。AOF記錄的是每一個寫命令數據安全性更高默認everysec配置最多丟一秒數據但AOF文件體積更大恢復速度慢。生產環境通常兩個都開AOF保證數據安全RDB用于快速恢復和備份。面試官Redis實現分布式鎖要注意什么我最基礎的方式是SETNX加過期時間set key value NX PX 30000保證原子性。但要注意value必須是一個唯一標識釋放鎖的時候要先get判斷是不是自己的鎖再delget和del要保證原子性通常用Lua腳本執行。更完整的做法是用Redisson它有一個看門狗機制會對鎖自動續期防止業務還沒執行完鎖就過期被其他線程拿走了。這套方案里Redis主從切換時可能會丟鎖所以嚴格要求時要用RedLock但實際業務里用得不多。快問快答階段明顯是在掃盲區問題之間沒有太多關聯覆蓋范圍廣但深度不大。我的體感是這部分的目的是快速判斷候選人的知識面夠不夠寬而不是在某一個點上死磕。所以平時積累很重要至少每個常見知識點都要能說出個一二三來。5. 手撕算法鏈表中環的入口節點基礎題問完面試官說最后寫一道題吧。當時電話面試不方便共享屏幕就讓我口述思路然后發一段代碼到指定的鏈接里。5.1 題目分析與快慢指針思路題目是經典題給定一個鏈表如果它包含環找出環的入口節點沒有環就返回null。我聽到題目第一反應是這題有套路分兩步第一步判斷是否有環。用快慢指針slow每次走一步fast每次走兩步兩個指針都從頭節點出發。如果鏈表中存在環那么快指針最終會追上慢指針在環內相遇如果快指針達到了鏈表尾部說明沒有環。第二步找到環的入口。相遇之后讓slow回到頭節點fast留在相遇點然后兩個指針都保持每次走一步的速度繼續走下一次相遇的節點就是環的入口。但光記住結論不夠面試官多半會追問為什么。所以當時我把推導也講了一遍假設從頭節點到環入口的距離是a環入口到第一次相遇點的距離是b相遇點到環入口的距離是c那么第一次相遇時慢指針走了ab快指針走了abn(bc)。因為快指針速度是慢指針的兩倍所以2(ab)abn(bc)整理一下得到a (n-1)(bc)c。也就是說從頭節點重新出發的slow指針走距離a的同時從相遇點重新出發的fast指針會繞環走n-1圈再走c兩者恰好都在環入口位置碰頭。5.2 代碼實現與邊界條件我用Java快速寫出了實現public class ListNode { int val; ListNode next; ListNode(int x) { val x; } } public class Solution { public ListNode detectCycle(ListNode head) { if (head null || head.next null) { return null; } ListNode slow head; ListNode fast head; while (fast ! null fast.next ! null) { slow slow.next; fast fast.next.next; if (slow fast) { break; } } if (fast null || fast.next null) { return null; } slow head; while (slow ! fast) { slow slow.next; fast fast.next; } return slow; } }寫完之后我主動把邊界條件說了一遍空鏈表和只有一個節點的情況直接返回null。鏈表沒有環fast會先到尾部循環自然結束。鏈表整個就是一個環也就是尾節點指向頭節點slow回到頭節點后第一次判斷就與fast相等直接返回頭節點邏輯是成立的。環在鏈表中間慢指針回到頭節點后走a步到入口另一個從相遇點出發經過c步到達入口兩者同步到達。5.3 面試官加試為什么快指針每次走兩步果然面試官接著問為什么快指針每次走兩步走三步行不行我心里慶幸之前看過這個問題的分析。回答思路是快指針走兩步的目的是保證它在慢指針進入環之后一定能追上慢指針?？紤]慢指針剛進入環的時候快指針已經在環里了兩個指針之間的相對距離最多是環長減1。每次快指針比慢指針多走一步這個相對距離就會縮小1所以最多走環長減1步就一定能追上時間復雜度是O(n)是最優步長。如果快指針走三步相對距離每次縮小2那么當初始相對距離是偶數時能追上是奇數時就可能錯過。極端情況下快指針會一直跳過慢指針所在的位置造成永不碰面的情況。當然實際中可能會因為環的形狀不同而碰巧追上但無法保證一定有解。所以兩步是既能保證追上又不會浪費額外時間的穩妥選擇。算法題到這里結束。面試官簡單評價了一句思路清晰然后問我有沒有想問他的問題。這里我也說一個小經驗算法題不光要把代碼寫出來最好能主動說明復雜度和邊界條件。很多面試官不會明確要求你說但你說了他會下意識把你歸類到基礎扎實的那一批。這道題的時間復雜度是O(n)空間復雜度是O(1)我也一并說了。6. 面后復盤與經驗總結6.1 我回答得不夠好的地方這一面整體感覺不差但復盤時我給自己挑出了幾個明顯的問題第一線程池參數當時答得不全。面試官問線程池的核心參數有哪些我答了corePoolSize和maxPoolSize但把keepAliveTime、workQueue、ThreadFactory這幾項漏了還是面試官引導了一下才補齊。這個屬于基礎中的基礎答不全挺不應該的。后來我把ThreadPoolExecutor的七個參數核心線程數、最大線程數、空閑存活時間、時間單位、工作隊列、線程工廠、拒絕策略整理成了一張表每天默寫一遍之后再沒有出現過卡頓。第二反問環節問得太淺。我只問了一句團隊目前主要用什么技術棧面試官簡單回答完就結束了。后來跟已經拿到offer的學長聊才知道好的反問是能加分的。比如可以問團隊目前更多在攻堅哪塊業務候選人入職后一般從什么模塊入手您覺得這個崗位更看重候選人的哪方面能力這能體現你對崗位的思考深度。當然這一面本身已經過去了這個經驗主要是在后面的面試里用上了。第三項目里有一個細節我沒講透。面試官問過為什么訂單創建不直接同步執行而是走MQ異步我當時只說為了削峰填谷但沒有說清楚異步之后怎么保證訂單和庫存的一致性。實際上我們當時的方案是MQ消費者里做庫存二次校驗如果庫存扣減成功但訂單創建失敗會發一條消息到死信隊列由定時任務做狀態對賬。如果當時把這個對賬機制講出來項目這塊會更加完整。6.2 蘑菇街一面的考察特點如果把蘑菇街一面和同期面過的其他公司對比我的感受是技術范圍中規中矩不偏門。核心還是Java基礎、JVM、MySQL、Redis、算法這些后端通用知識。項目深挖比想象中要細。會在緩存一致性、超賣怎么解決這類問題上連續追問直到確定你是真的理解而不是背了個八股。算法題難度適中。沒有出hard題劍指Offer和LeetCode hot 100覆蓋到的程度就夠用了。面試官整體比較溫和會有一點引導性。你卡住的時候他會換個角度問而不是冷場讓你尷尬。這里也列一個表格方便大家對照我當時整理的考察側重點考察模塊涉及知識點準備優先級項目深挖緩存一致性、超賣、異步解耦、消息可靠性最高Java基礎HashMap、ConcurrentHashMap、volatile、鎖高JVM內存區域、GC Roots、CMS/G1高MySQLB樹、索引失效、MVCC、間隙鎖高計算機網絡TCP握手揮手、HTTPS、HTTP狀態碼中中間件Redis穿透/擊穿/雪崩、分布式鎖中算法鏈表、二叉樹、雙指針高6.3 寫在最后的心得這場面試最終的結果是過了后續進入了二面。但說實話一面給我留下的最深印象不在結果而在于它讓我第一次真正體會到準備充分的面試是很有掌控感的。項目、基礎題、算法三個環節節奏分明面試官問的每個深度點我都恰好提前踩過這種正反饋是會滾雪球的最直接的影響就是讓我對后續字節、快手幾家大廠的面試都更有底氣。如果你現在也在準備秋招我的建議就是提前批一定要投尤其像蘑菇街這種有提前批的廠子試一試沒有任何損失。復習時間不夠的時候優先把項目里每一個技術選型的前因后果想明白把HashMap、JVM、MySQL索引、Redis三大問題這幾座大山啃透再拿劍指Offer里的高頻題練手。面經不是背的是拿來對照檢查自己哪里有漏洞的用這個思路去看你會少走很多彎路。