【本文是公眾號讀者投稿的面試經歷，感謝大家分享自己的面試經歷給其他廣大同學參考】
目錄：
一、以往履歷
二、技術積累
2.1 公司裡的積累
2.2 業餘時間的積累
三、面試過程
3.1 一面：深挖技術
3.1 二面：結合專案
3.3 三面：聊薪資、聊理想、聊人生
先說一下這位同學的面試成果，普通本科學歷，畢業僅僅3年，原先年薪也才20萬，但是最近跳槽一舉拿下年薪38萬的offer。
以下是這位同學整理的這次面試經過的一些心得體會，供廣大同學參考
一、以往履歷
之前經歷過的都是小的網際網路創業公司，技術氛圍不好，過程管理也不規範，做過的專案也都是一個個的風投專案，容易被市場優勝劣汰下來。
進入大公司一直是我的夢想也是我的情結，但是目前年限不夠。所以先沉澱一下，找了一家B輪融資的網際網路公司，希望下次有幸能寫面經的時候能夠收到大廠的offer。
二、技術積累
2.1 公司裡的積累
① 珍惜專案帶來的技術挑戰
之前做一個專案時，遇到了地理位置相關的技術挑戰，於是接觸到了GeoHash演算法。
當時是使用mongo儲存經緯度 + geo計算來解決了這個問題。
在這個過程就會對MongoDB技術進行一定的研究，而且對地理位置相關的問題也會有一定的經驗積累。
做另外一個專案時接觸到了千萬級別的使用者量，在搞活動的時候受到了高併發挑戰。
使用者量很大時，高併發請求後臺系統，對交易鏈路造成了壓力，這裡應該如何解決也有了一定的積累。
還有就是我在做一個公司全新探索性專案時，由於是全新的領域，需要進行一定的領域建模。在建模的過程中，大大鍛鍊了自己的系統設計能力。
② 珍惜團隊管理的機會
印象很深刻的一點是，當時由於一個探索性的專案屬於公司的試點專案，剛開始後端研發人員就3個人。
所以我們作為老員工，在後麵糰隊擴招時也順理成章的成了小組leader之類的角色。
新領域有技術調研的困難，也有需求合理性的苦惱，加上剛開始人員不多，基本上是加班特別嚴重的。
於是公司高層引入了敏捷開發，我們成立了一個個scrum小組，需求拆解，迭代任務，物理看板，每日站立會。
第一次接觸scrum給我的職業生涯帶來了很大的衝擊，而團隊管理也讓我從另一個角度來認識整個團隊的容量和交付能力。
但是一旦把這次機會把握住了，就可以快速積累帶一個小團隊的能力，包括人員招聘、專案管理、團隊管理、任務拆分、進度追蹤、保證產出，等等。
2.2 業餘時間的積累
① 善於總結和複習
1）週期性總結，有利於對知識的整理記憶。
自己平時會學習很多的技術，比如Java併發、快取、MQ、微服務、分散式，等等。
但是其實人有一個很大的問題，就是學完就會忘。這個是很正常的，人不是神仙，誰不會忘呢？
所以說一定要週期性的複習，這樣你每一年才會發現自己把很多技術都掌握的很紮實。
2）有段落標題有總結的文字比一堆文字更直觀
對於自己平時學習的時候記錄的筆記，不是說寫一堆文字就可以的，我們都需要自己提煉一番，歸納出一堆小標題。
通過小標題的形式串聯起來大量的知識點，在複習的時候，哪怕就是看到標題就知道背後的知識點。
② 尋根究底
平時在學習一些技術的時候，往往會找很多的書籍還有視訊。
但是其實在學習的時候，不光是吸收書籍或者視訊裡的東西，還要有自己主動思考的能力。
舉幾個例子：比如之前研究Spring Cloud技術的時候，就對裡面很多技術都有自己的思考，然後帶著自己思考的問題主動去裡面進行探索。
1、我對Ribbon作為負載均衡技術，在Spring Cloud原始碼內部的一些實現細節上，有以下的疑問：
- springclientfactory原理是什麼？
- 誰觸發注入了springclientfactory？
- 為什麼ribbon這裡的整合使用springclientfactory，還有其他方式嗎？
- 將bean注入ioc容器的方式有哪些？
- 自動配置的原理是什麼？
- spring.factories和jdk的spi有什麼異同？
然後會帶著這些問題去深入探索Spring Cloud原始碼的一些實現。
2、我對Zuul作為SpringCloud的閘道器也有疑問：
路由表只是從配置檔案讀取的嗎，會不會從serverList裡動態重新整理路由表呢？
帶著這個問題也會去探究其底層原始碼。
3、對MySQL技術，我的疑問是：
mvcc機制為innodb提供了讀寫併發的能力，快照讀都是通過隱藏的事務ID列來讀取快照資料？
此時可以再深入研究innodb的其他細節：
- innodb的事務的ACID特性是如何實現的？
- undo日誌是儲存在哪的，快照讀是怎麼和undo日誌結合起來的？
③ 培養獨立看原始碼，畫圖的能力（重要性：5顆星）
第三個，平時一定要建立起來自己獨立看原始碼的能力。
比如說之前我通過一些網上的部落格，大概看過裡面對Atomikos、ByteTCC的原始碼的分析，瞭解了XA事務和TCC事務的執行流程和框架設計。
優秀的分散式事務框架其實也有很多，在ByteTCC中，cancel是和try對應的，如果confirm失敗，便會根據事務日誌一直重試，這是ByteTCC的設計理念。
但是，我們還可以看看其他TCC框架，如tcc-transaction、Hmily他們在TCC方面的設計理念。
根據看原始碼的方式，先大致瀏覽文件，跑一個demo，找單元測試和框架入口。
先讀靜態原始碼，再debug跟進，邊除錯邊畫流程圖
慢慢的，這種獨立看原始碼和畫圖的能力可以得到很大提升，從怕看原始碼到愛看原始碼。
三、面試過程
其實這家公司，因為我知道他是一家B輪融資發展很好的公司，所以直接就去面試了。
自己這次的目標，就是找一家發展潛力好的中型網際網路公司，而不是直接進大廠，因為自己知道年紀太輕，直接面大廠信心還有所不足，就想先沉澱一下。
3.1 一面
① jvm類載入機制，何時觸發類的載入和解除安裝
主要說了Java為了實現語言的靈活性，採用了在執行時動態載入位元組碼，以及載入、連線、初始化的各個步驟流程。
還說了載入使用的雙親委派模型以及其打破該模型的案例，各個類載入器載入什麼樣的類，如何自定義類載入器。
對類的七種主動使用觸發類的載入，類的解除安裝的條件。
總結起來：主要就是圍繞類載入，聊了一些老生常談的問題。面試官肯定是知道，但是答的時候，要儘可能的多說多擴充套件。
這樣可以讓面試官知道我們大致的知識範圍，也掌握面試主動性。
② gc演算法
說gc演算法之前，先聊瞭如何判斷一個物件可以被回收，我說了引用計數法，GC Root等方式，回收物件的流程。
然後先從標記清除演算法開始談，說出其優缺點，從而引申出複製清除和標記整理演算法。各個演算法聊完之後，引申出分代清除演算法。
聊完演算法便開始聊各種垃圾收集器的特點和使用場景。
這裡我的一點感受是：很多知識點其實不是死記硬背的，而是前人設計的智慧或者是妥協。
我們可以按邏輯分析的方式跟面試官侃侃而談，用分析問題的方式來回答，而不是死背答案的方式。
③ nio，aio，netty
這方面其實不太熟，直接跟面試官表明對這方面有欠缺，但是有一定自己的瞭解。
主要從傳統的bio模型開始說起，然後說到tomcat在bio模型下同步阻塞的問題。
接著說了為什麼要設計nio這同步無阻塞的模型，是怎麼通過一個selector多路複用來監控多個channel的。
最後還聊了聊aio的非同步無阻塞模型的大致概念，nio基於事件的同步無阻塞模型適用於伺服器端程式設計，aio非同步無阻塞適用於大檔案讀取。
這裡給大家分享的一點心得就是，不熟悉的知識點千萬不要亂掰，浪費面試官時間，也讓自己在面試中處於被動形勢。
可以先表明自己對該知識點有欠缺，再大致說說自己的瞭解，讓面試官快速瞭解自己的水平。
④ innodb的索引結構
直接和麵試官說了innodb的BTree索引的B+樹，說說其儲存結構和優點。再聊到了聚集索引和輔助索引。
後來補充了下二叉查詢樹，連結串列，hash，B樹的優劣勢以及為什麼會選擇用B+樹來作為索引結構。
儘量多從自己作為設計者的角度來回答問題，表現出分析和表述能力。
⑤ 一致性hash
- 先聊hash演算法的優點
- 再聊一致性hash的使用場景：
- 分散式環境下多節點負載資料
- 防止節點的動態增減影響到大範圍的資料
- 再聊一致性hash的原理，如何實現，自己實現該演算法的思路
- 再聊其他中介軟體對其的實現，如redis-cluster的hash slot方式
⑥ redis的持久化、哨兵、cluster
這些都是老生常談的問題，基本上你只要看過石杉老師的億級流量課程，都可以輕鬆的回答。
⑦ synchronized的原理
先聊了sync的指令，再說其加鎖的原理。
然後聊到了JDK 1.6對其的優化（自旋鎖，自適應自旋，偏向鎖等），然後說到了sync和wait、notify這對黃金搭檔。
⑧ AQS、CAS、以及其他元件
說完sync，面試官就問了JDK的可重入鎖，問其實現原理。
自然而然的就說到了AQS，以及可重入鎖的那一套原理，然後順理成章的聊了公平鎖，非公平鎖。
接著面試官就問了使用AQS的其他元件，然後就聊了讀寫鎖，訊號量，CountDownLatch、ThreadPoolExecutor等的原理。
⑨ 讓你實現一個RPC框架該如何設計
- 通訊協議
- 序列化方式
- SPI擴充套件
- 底層代理
- 超時、重試、負載均衡
- 攔截器、外掛等自定義支援
- 註冊中心的選型與互動
這類開放式問題按照我個人的理解，應該不是讓我們直接回答底層很詳細的細節，而是從很hign level的級別來談談需要考慮哪些點。
⑩ 設計秒殺系統
我本身沒做過秒殺系統，之前也沒怎麼看過相關的設計，只記得之前上班通勤的時候偶爾翻過幾篇博文，於是帶著自己的分析跟面試官談的。
- 臨時機器、頻寬申請，環境隔離，不要影響主體業務
- 與產品溝通，前端限流方式是否影響使用者體驗（如答題、拼圖等）
- 預估使用者量：比如只有40%的使用者能搶到，那麼直接讓50%的使用者立即秒殺失敗，不進入後續服務
- 後端做好流量控制，限流降級，一些非核心的資料做好多級快取
- 層級過濾下的少量使用者，進入秒殺核心邏輯，這時候有多種方式：
- 使用佇列（削峰，序列化，扛併發）
- redis的incr（單執行緒）
- 分散式鎖（可以聊聊分段加鎖，增大分散式鎖的TPS）
- 再聊聊產品需求設計，是採用下單即鎖定庫存還是支付才鎖定庫存
3.2 二面
二面比較關注我的專案經驗，主要問了我最近的一個專案以及專案的使用者量，訂單量，交易量，QPS，TPS等。
另外還問了相關的業務，看我是否對一個專案及業務有著完整的理解，然後跟著專案問了一些簡歷上寫到的東西。
① 分散式事務
跟面試官聊了分散式事務的各種解決方案以及適用場景，大致聊了下具體的細節。
② 分散式鎖
很多人聊分散式鎖喜歡單刀直入的直接聊redis和zk鎖，我喜歡先聊分散式鎖的原理。
其實就是在分散式系統中，找一個全域性唯一的第三方的一個標識，某個節點的某個執行緒，獲取到該標識，即為獲取到分散式鎖。
相應的方案有很多：
- 基於某個遠端本地檔案鎖（只有某個執行緒能唯一建立一個檔案）
- 基於資料庫某張表的唯一索引
- 基於Redis的setnx/lua實現
- 基於zk的瞬時序列節點實現
再一個個聊他們的優缺點以及自己是如何在專案中封裝落地的。
③ 限流演算法
- 單節點限流：簡單的聊了下漏斗和令牌桶演算法以及他們的特性
- 叢集限流：想了想用Redis做訊號量
順便聊了下Hystrix的訊號量以及執行緒池限流。
④ 設計模式
設計模式我個人掌握的很熟，這也是很基礎的東西。
主要聊了在上一個專案的哪些場景使用了哪些設計模式，為什麼要用該模式。
然後又補充了一下，一些第三方框架裡使用的一些設計模式。
⑤ RabbitMQ
因為專案用的是RabbitMQ，所以主要聊的是他的使用場景，如何保證訊息儘可能不丟失，RabbitMQ的叢集模式。都是很基礎的問題。
⑥ 手寫ArrayList
這個沒什麼好說的，相信看過相關原始碼都能寫出來。
⑦ 不使用連結串列怎麼讓HashMap有序
問問題的時候，二面面試官邊面試還在邊拿著本子修復線上bug（看起來來的不是時候...）
當時考慮時間很短，沒有什麼好的想法。
於是說HashMap為什麼插入讀取是無序的，因為其為了快速查詢定位的hash演算法，導致其在陣列中雜湊。
如果不使用連結串列記錄順序的話，可能就想著有個有序的佇列之類的來記錄索引，從而遍歷。
答完之後，個人感覺答得不好，不過也過了。
3.3 三面
三面主要是人事面，聊了聊公司業務，公司目前融資情況，公司人員情況。
人事主要就是聊人生聊理想，問了問上一家離職原因，期望薪資以及入職時間。
最後因為一面和二面，幾乎技術面試無死角無短板，哪怕是不擅長的技術問題，也會給出自己的一些思考。
所以最後得到了面試官一致的認可，直接就給出了38萬年薪的offer，自己也沒有繼續面試，直接就去了這家公司。
一大波微服務、分散式、高併發、高可用的原創系列文章正在路上,
歡迎關注公眾號：石杉的架構筆記
週一至週五早八點半！精品技術文章準時送上！！！
十餘年BAT架構經驗傾囊相授