你好，我是 yes。java
這篇文章我想談談如何在面試官前面吹牛P。web
我給了六個案例，教你如何把 B 格提上去。面試
這篇文章的靈感來自於一個讀者，他在羣裏@了我。算法
我一看，確實啊！緩存
首先 「幾個 offer」 說明關於 Synchronized 的面試題很常見。安全
而後從 「面試官和我爭」 能夠看出，確實不少人的理解是錯的。微信
而後你再從 JVM 源碼層面和他說說，這面試不就妥了？網絡
若是我是面試官，這候選人透露出來他看過 JVM 代碼，而且還發現了書上的錯誤，說的有理有據的，這 level 不就上來了？併發
這面試不就穩了？app
就是這篇關於Synchronized的一個點。
提高 B 格的時候到了。
想一想看，當面試官問你看過什麼源碼呀？
你答：我看過 JVM 關於 Synchronized 的源碼，我發現網上有好多理解都是錯誤的...阿巴阿巴。
安逸得慘咯！
這麼一想，我發現我寫過的文章還有好多能夠裝23的地方！
好比這篇：從Dubbo源碼到CPU分支預測之旅
面試官問：看過 Dubbo 源碼嘛？
你答：看過，我以前看源碼的時候還發現了一個很奇怪的地方，有個地方 if 和 switch結合着用。
我就很奇怪，因此我就用 benchmark 跑了跑，試了試 if 和 switch 的執行效率。
我發現全 if 的效率是最高的。
因而我又反編譯了代碼。
我發現 switch 是經過查表直接拿索引去訪問的，而 if 是每次都會取出變量和條件進行比較。
那不是應該 switch 的效率最佳嗎？
帶着疑問的我繼續查閱資料，後來我發現原來是 CPU 分支預測（詳細看上面文章）搞得鬼，因此 Dubbo 的源碼纔會這樣寫。
你看，這一波下來，你這表現滿分啊！
會主動看源碼！
會用示例跑(動手)。
會反編譯比較，鑽研(動手)。
最後到底層 CPU(6666)。
這一套下來？面試官不要你要誰？
再好比這篇：炸了！一口氣問了我18個JVM問題！
面試官：你平時看什麼書呀？
你答：我看過《深刻理解Java虛擬機》，我還發現了一個錯誤呢。
面試官：什麼錯誤呀？
你答：不是由於「Con-current Mode Failure」而致使 Full GC ，而是由於發生了 Full GC 因此拋這個錯。
我當時好奇看了看 CMS 的源碼，我發現.....
後續不貼了，以前的文章寫的很清楚了，也是從源碼上找證據。
面試官一聽，這小夥子看書就算了，由於想鑽研還去看源碼，源碼不只看進去了還看出錯誤？
不只熱愛學習還有鑽研精神，我要給他發 offer！！！！
再好比這篇：Kafka索引設計與二分查詢與底層緩存
面試官：你看過 Kafka 源碼嘛？
你答：看過。
當時看到了 Kafka 索引的設計，採用了稀疏索引，利用二分查找來加快搜索速度。
可是我從源碼發現這個二分查找是變型的，由於就消息隊列的特性而言，索引數據都是在文件末尾追加的寫入的，而且寫入的數據基本上會立馬被讀取。
也就是說數據熱點集中在尾部，而操做系統又是根據LRU來管理內存頁的，因此標準的二分會致使缺頁中斷的狀況發生。
因此 Kafka 巧妙的採用了冷熱分區來實現變型的二分查找。
你看看，這一波下來，面試官大拇指不給你給誰？
看過源碼， 懂得基本算法，理解消息隊列尾部熱點特性，曉得操做系統LRU來淘汰內存頁，嘖嘖！
面試官對你說：
面試官：讓你設計一個鏈接池你怎麼設計？
你答：我以前看過 HikariCP 的源碼。
重點就是無鎖設計，由於鏈接池是讀多寫少的場景，因此能夠利用 CopyOnWriteArrayList 來存儲鏈接，而後再利用本地化存儲的思想來減小競爭。
獲取鏈接的流程：
-
先去 ThreadLocal 找以前用過的鏈接，找到則直接返回。 -
若是找不到就去 CopyOnWriteArrayList 實現的 sharedList 裏面找鏈接(這裏還有個竊取的概念)，若是找到則返回。 -
若是找不到則用 SynchronousQueue 等待鏈接，超時則返回 null。
再詳細就看上面文章吧。
怎麼說？
通常的回答，估計也就會說個加鎖保證線程安全。
好點的，說個讀多寫少場景，用個寫時複製。
你這波無鎖+寫時複製+本地資源加速緩存+SynchronousQueue 無緩存等待隊列。
若是你以爲還不夠細，那就再說說 HikariCP 的 FastList，它優化了 ArrayList。
ArrayList 每次 get 都會有範圍檢查，而且 remove 是從前日後遍歷的。
而在鏈接池這個場景每次 get 範圍檢查沒有必要，而且 remove 的時候從後往前遍歷更好。
夠不夠細？
我細到 ArrayList 的 get 的範圍檢查我都要計較！(HikariCP 不愧是最快的)
面試官可能在角落裏瑟瑟發抖。
再好比這個：RPC 核心，萬變不離其宗
面試官：讓你設計一個RPC框架你怎麼設計？
你答：容我想一想(僞裝思考，其實小宇宙就快忍不住爆發了)。
RPC 框架基礎的核心其實就這麼幾點：
-
動態代理(屏蔽底層調用細節) -
序列化(網絡數據傳輸須要扁平的數據) -
協議(規定協議，才能識別數據) -
網絡傳輸(I/O模型BB一下，通常用 Netty 做爲底層通訊框架便可)
注意，上面加粗的其實二字，必定要說，要注意語氣，要顯得你遊刃有餘，低調奢華。
固然上面只是基礎核心，生產級別須要註冊中心做爲服務的發現、路由分組、負載均衡、異常重試、限流熔斷等。
更詳細的就看上面的文章吧~
面試官已經躲在角落裏瑟瑟發抖了。
再好比.....
好比不了了，太多了！
不信你去翻翻看！
我寫這篇文章的時候，我發現電腦屏幕居然愈來愈高。
原來，是我慢慢地從椅子上滑了下去....
我怕我再舉幾個例子，我要給本身跪下了。
我時常會看看本身寫的文章。
而後，默默在內心念叨這傢伙真滴牛P。
因此不要錯過個人文章喲，可能每一篇都是裝23的機會。
由於微信推送機制，文章可能沒法及時送達，因此加個星標，文章必會及時推送~。
唉，再這樣下去，我怕和半佛老師同樣，成爲一個天天在鏡子面前給本身磕頭的硬核男人。
我是 yes，從一點點到億點點，咱們下篇見。
本文分享自微信公衆號 - yes的練級攻略（yes_java）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。