有道無術，術可成；有術無道，止於道；以術識道，以道御術
面試前的小姐姐
來說說前不久螞蟻金服一面的情況。說來也是巧合，當時在羣裏有位螞蟻金服的小姐姐發了個內推，看了下JD感覺可以試試於是就私聊了小姐姐發簡歷內推了。
我16年也就是大三上就開始實習了，到現在其實不到三年的經驗。就我個人而言面試的經驗真的是少之又少，不超過一個手掌的數。因此我簡歷發給小姐姐之後又聯繫她，讓她晚點推讓我先找幾個公司練練手。
但是小姐姐說她可以先幫我熱熱身，她也是面試官（小姐姐可真的是太好了！），挑了晚上和小姐姐語音了20多分鐘，雖然不是具體的面試內容，但是內容比這個更幹！她我說了說一面二面大致的問的方向和注重點，還有一些注意事項：
一面：
小姐姐：上來先會給兩道編程題，二選一，不會是很難的算法那種，比較務實。基本上常年在一線編程的話能寫的出來。是發個鏈接給你的郵箱，然後點擊鏈接在線編程，沒有代碼提示，寫不出來基本上就是沒了。
我：假如有些方法實在記不起來能在idea寫了拷過去嗎？
小姐姐：這個你可以跟面試官提，不過就我而言比較減分，並且你idea寫代碼，面試官可能會把代碼拿來跑而不是目測過了就好了。如果沒跑過也基本上沒了。
我：哦哦好的好的。
小姐姐：然後就是自我介紹，一面着重考察基礎方面，比如鎖啊、GC啊、常見集合等等。再會根據你的簡歷，比如我看你簡歷寫了dubbo，那就會問一些dubbo方面的問題。這麼一堆談下來差不多了，一面半小時左右。
我：哦哦好的好的。對了一面如果過了的話得多久纔會有通知？週期會很長嗎？
小姐姐：基本上2-3個工作日就會有結果了。
二面
小姐姐：二面的話比較考察項目，基本上會先讓你描述一些項目整體的架構，從哪裏到哪裏數據怎麼流轉，項目的tps、qps等，基本上答不出來就認爲你不是項目的核心人員。然後爲什麼這麼設計，有哪些優化點？這是考察你對平日的工作有沒有足夠的思考。
我：哦哦好的好的(瑟瑟發抖)。
三面、四面
小姐姐：emm....你過了一面二面再說吧。
我：是是是！放眼當下。
其實我是真想先投幾個公司先找下節奏的，但是小姐姐都這樣說了我就只能直麪人生了！過了兩天面試官就來電話了，約個幾天後的晚上7點，並且指明需要有電腦(小姐姐誠不我欺啊)，我問需要攝像頭不，答：不需要，能上網就行。
面試正文
其實我也忘記到底約的是7點還是7點半，反正我7點坐在電腦前面等了，內心激動的一批，飯都喫不下等到了7.35，終於等到你還好我沒放棄！！
聽到電話那頭傳來的溫柔的小哥哥聲音，來了他終於來了！我已經打開郵箱等待編程題的到來了！
小哥哥：來先做個自我介紹吧。
我：emm？？？不是說上來先做兩道題嗎？額可能是先自我介紹下再做題吧？於是我就巴拉巴拉說了20秒，說到在現在公司做一部分前端開發的時候就被打斷了。小哥哥：說說你寫前端有什麼感觸？
我：我想要換工作有很大一部分原因就是因爲現在我需要做前端，前端對我而言吸引力不大，雖然對於後端而言前端給予的正反饋更加的明顯和及時，但是我更喜歡後端在背後默默輸出的感覺。
小哥哥：是的，前端對於後端而言更加的簡單，掌握了幾個框架基本上就夠用了，天花板比較低。
我：是的是的，後端的東西太多了，涉及到的面很廣(各位前端聽友，上面的話是小哥哥說的，原話，與我無關。我也是身不由己是吧，請海涵哈)
小哥哥：看你簡歷寫了Dubbo、Redis、RocketMq，你挑個你最厲害的說說？
我：（我個人覺得這個問題看似爲我考慮，實則暗藏殺機）redis吧？
我其實大腦快速過濾了一下感覺redis比較穩，我覺得能問的無非是：redis爲什麼單線程？IO多路複用？redis和memcached的優缺點？redis五個對象？每個對象的底層數據結構？redis的布隆過濾器(我還可以給你引申個布穀鳥過濾器)、hyperLogLog(我還給你說出是基於伯努利實驗) redis的過期刪除機制？淘汰機制？redis的RDB和AOF？redis的事務？redis的主從?哨兵？集羣？redis的分佈式鎖？redlock？(來嘛martin大神對剛redis作者的內容我都說的出來) redis的一些優化？大key拆分？通過遊標分批返回避免key*等命令阻塞？禁止swap？考慮內存碎片等等？感覺好像挺穩的那就redis吧！
小哥哥：redis集羣介紹一下
我：（來了來了！）redis的集羣是將一共16384個槽分給集羣中節點，每個節點通過gossip消息得知其它節點的信息，並在自身的clusterState中記錄了所有的節點的信息和槽數組的分配情況
小哥哥：客戶端是如何訪問集羣的？
我：客戶端會先訪問集羣中的一個節點，如果槽命中直接訪問，如果不命中，則會返回MOVED指令，並告知槽實際存在的節點，然後再去訪問。(這裏其實還有個遷移中的情況，如果訪問的槽正在遷移，則返回ask命令，客戶端會被引導去目標節點查找)
小哥哥：你們公司是用集羣麼？
我：是主從
小哥哥：知道關曉彤麼？
我：？？？(什麼情況這個跨度這麼大嗎？)
小哥哥緊接着說：就是和鹿晗那次把微博弄掛了的情況
我：哦哦哦知道知道
小哥哥：微博這麼大的公司了，而且出了這麼多這種事故？爲什麼還會掛了？
我：（，爲什麼這麼出了這麼多次情況還會掛我咋知道！這麼大公司監控服務很到位的啊，並且報警自動擴縮容這一套組合拳下來感覺不應該掛的啊，它爲啥掛了...）我弱弱的說了句熱點key的問題？太熱了頂不住
小哥哥：那怎麼處理呢？
我: 首先保障熱點 key 過期問題，給不同的熱點key分配隨機的過期時間，保證過期的平滑。然後可以通過在 Redis 中設置分佈式鎖，只有獲取到鎖的請求才能夠穿透到數據庫，保證同一時間只有一個請求可以穿透到數據庫更新緩存。
小哥哥：不是，我不是這個意思，我是問這個熱點key的訪問要如何解決？
我：可以通過 hash 分 key，把一個 key 拆分成多個 key，分佈到不同的節點，防止單點過熱。比如一個 key 之前就分到一個節點上，我把 key 做了拆分，就像一致性 hash 的虛擬節點，分散訪問。
小哥哥：你說到一致性 hash？那和普通hash有什麼區別？
我：一致性hash把hash的空間虛擬成一個圓環，key做hash落在圓環上，按順時針查找，遇到的第一個緩存節點就命中。通過虛擬節點避免緩存分佈不均，並且使得某個節點掛了之後，下面的節點只需要承擔一部分的流量而不會因爲需要承擔所有流量而掛了，然後發生雪崩
小哥哥：好，那我們說回剛纔的問題，你剛說的是一種解決方案那還有什麼別的方案麼？
我：（還有？？我真的沒了，我思考了十秒鐘，一片空白不知道了）不知道了。
其實還有本地緩存，簡單點就一個HashMap就行，或者Guava cache或者Ehcache。用本地緩存來應對極熱數據。
小哥哥：那好吧，來說說MQ吧
我：（小哥哥有點失望的樣子，哎也是不應該但是腦子就是想不起來..）常見的有RocketMQ、KafKa等，RocketMQ更適合業務，注重時驗的優化。Kafka因爲存在攢一波的思想，吞吐更高，並且適合大數據場景，不適合業務。
小哥哥：攢一波是什麼意思？
我：攢一波就是發消息默認不是一條一條發，是等一波再發(其實攢一波思想很常見，例如tcp的那個算法，pageCache的批量刷盤等等)
小哥哥：那Kafka是哪種模式？
我：什麼意思？什麼模式？
小哥哥：就是消息不是有推和拉兩種模式
我：額...（我不知道，我就知道RocketMQ的，是基於拉的，雖說有個pushConsumer，但是本質上也就是拉，只是broker先hold住了拉的request。我也知道拉模式和推模式的優缺點，只是我當時傻了，我當時腦子想我簡歷就沒寫Kafka，爲啥問我Kafka不問我RocketMQ，其實我應該先說說推拉模式的優缺點然後說了RocketMQ是採用什麼的，然後說下我對Kafka不太熟，只是我當時傻了...）我說推？應該是推吧？不對不對好像是拉....（我真的是神操作）
小哥哥：不知道就說不知道，不要亂說一通。
我：是是是，我不知道對不起。(是的不知道就直接說不知道，然後應該把自己知道的說出來，彌補下)
小哥哥：說說synchronize和lock區別
我：（來了來了，趕緊彌補下剛纔的操作）synchronized是java內置鎖，不需要手動的解鎖，支持可重入，但是非公平，不可中斷，條件單一，在1.6之前性能較差，經過1.6優化只有性能有顯著的提升。lock，基於AQS，拿reentrant爲例，需要手動解鎖，可重入，支持中斷，支持多條件，支持超時操作。(來快問我synchronized底層和1.6做了什麼優化，我來從monitor對象開始說到字節碼到monitorenter和monitorexit再到mutex，從偏向鎖到輕量級鎖到重量級鎖，我再說個逃逸分析、鎖消除、鎖粗化。再引申出個JMM，來個cpu緩存L1、L2、L3到MESI，我還可以給你來個cpu緩存行爲共享問題。什麼你問的是鎖爲什麼重？那就來上下文切換，內核態用戶態，系統調用，再給你引導上一個mq話題，搞個mmap、sendfile零拷貝，扯一波pageCache、內存預分配、文件預熱、mlock等。來啊！！！)
小哥哥：說說AQS原理吧
我：（我竟然不問我synchronized）AQS主要是採用state，通過對state的CAS判斷來獲取鎖和解鎖，並且存在等待隊列和條件等待隊列來park相關線程之後入隊等待，有公平和非公平兩者模式來喚醒等待的線程。
小哥哥：那爲什麼需要個AQS？
我：主要是爲了封裝和抽象，通過封裝了公共的方法，減少重複代碼。
小哥哥：說說GC調優吧
我：GC調優一般具體是通過GC日誌的情況來分析。基本上發現minor gc頻繁，新生代空間太小了。如果發現晉升的年齡很小，老年代迅速被填滿，導致頻繁的major gc，並且回收比率又很大，那說明對象的生命週期確實很短也需要調整新生代。如果看full gc很頻繁，但是每次回收的內存就一點點，那目測就是內存泄露了。總體上就是根據分代的根本，也就是新生代朝生夕死的事實調整GC，避免分配大對象。具體還是得分析GC日誌。
小哥哥：好，那說下mysql like有什麼注意點？
我：最左匹配，防止全表掃描而不走索引
小哥哥：那說說mysql查找過程
我：就拿命中索引的說吧，innodb主鍵是聚簇索引，採用b+樹結構，非葉節點存的是主鍵和指向子節點的指針，葉子節點存的就是整體行數據，整體都是有序的，通過主鍵掃描根據樹查找，最終落到葉子節點，命中然後返回。(其實更細的有mysql的一頁有16kb，一頁其實有多行記錄，命中一頁之後還要通過行記錄索引通過二分找到行記錄)
小哥哥：那知道LSM樹麼？
我：（LSM，其實我是知道的，而且我還做過筆記，不過當時就是好耳熟啊...然後就沒然後了）我說聽過，但是不太記得
小哥哥：那cassandra知道麼？
我：啥cass的？
小哥哥：就是cassandra
我：（我腦子在想什麼卡絲娜的瑞，上面mq被教育過了）我果斷的說不知道 （實際上我聽過，只知道是個nosql數據庫，沒用過）
小哥哥：行，那說了這麼多我們來寫一道題吧？
我：（我纔想起來還得寫題，這不是先上來寫題的嗎，節奏怎麼不對？） 好的好的
小哥哥：LRU知道吧？來實現這個接口
我：（哎我抖了個機靈....想展示一下自己知道的多），我可以用LinkedHashMap嘛，我繼承LinkedHashMap，重寫removeEldestEntry
小哥哥：不行，給你接口當然只能實現這個接口
我：哦哦好的。(好像弄巧成拙了)，那我先說說思路吧，通過鏈表，存儲節點，新插入的節點插入到頭部，訪問過的節點也移動到頭部
小哥哥說：好的你寫吧
我：我在草稿紙上畫了一下，然後邊寫邊說我的寫什麼，其實我感覺不說點啥有點奇怪，我就邊寫邊說我在寫啥。
我：大概過了10多分鐘，我寫完了。
小哥哥：看着我的代碼，他也捋了一遍思路，口述一下說恩可以，那說說時間複雜度和空間複雜度吧
我：我用了HashMap以空間換時間的思路存儲了key和node之間的關係，並且有記錄頭尾節點的引用，並且鏈表是雙向鏈表，因此插入和查找的時間複雜度都是O(1)，空間複雜度是O(n)。
小哥哥：那說說要線程安全的話怎麼改造吧
我：簡單粗暴就是在每個方法上都加鎖了，在競爭不是很激烈的時候挺合適的，再進階一下，可以使用concurrentHashMap，然後再鎖方法內部，移動鏈表等代碼，減少鎖的粒度。
小哥哥：行，那差不多了，你有什麼想問的麼？
我：我剛纔的表現怎麼樣
小哥哥：從剛纔的回答可以看出你有一定的積累，包括剛纔你說的LinkedHashMap，可以看出你也有所準備的(emmm...好像讓小哥哥覺得我能寫出這個代碼是因爲我寫過LRU...講真我只寫過繼承LinkedHashMap的....從node實體都要自己建的開始我還真沒寫過..)，不過還是需要多看看公衆號，多看看一些好的博客，逛逛社區，至於今天的結果我答覆不了，還是得會去討論的。
我：是是是，持續學習，好的。
小哥哥：那今天就到這了。
我：嗯嗯好的好的
結果
說好的半小時左右，這一波下來算上筆試花了1小時25分鐘.....結果掛了.... 回顧下剛纔的情況，鹿晗那波沒答出本地緩存、KafKa推拉都不知道、LSM樹竟然不知道、cassandra也不曉得..推斷出這個人好像知識面不是很廣的樣子...難受確實慚愧。
事後我去查了查鹿晗那波爲掛了：主要是時間點在17年10.8號，17年的時候微博的報警擴縮容還是人爲的，沒有自動擴縮容，並且10.8號，國慶期間很多人出去玩了都沒打開微博，然後還有很多平時不玩微博的喫瓜羣衆，一聽到這個消息都打開微博，這波冷數據擊垮了微博某個系統，導致雪崩。
KafKa 是拉，拉的時候沒消息阻塞住，或者等消息達到一定數量拉請求才返回。
LSM（Log Structured Merge Trees），像日誌一樣順序追加，順序寫，因此寫入性能很高，爲了優化讀，到一定階段會排序合併。
cassandra 上網查吧..這裏不再贅述。
總而言之還是太菜了...
共勉。
因爲一波失利，奮發圖強多半年。。。狂刷了面試題，中間找面試題的艱辛就不多說了，大家應該都懂。爲此我把找來的面試題拿出來，也算是造福大家快樂自己吧。。。
有“阿里面試題集及阿里必問200道面試題”、“大廠真題”、“batj大廠面試題總結”、“1000道面試”、“Java核心知識點”等等
阿里面試題集及阿里必問200道面試題
大廠真題
batj大廠面試題總結
互聯網Java工程師1000道面試
Java核心知識點
由於篇幅限制，不能給大家全部展現出來，但是完整文檔已備好