Java程式設計師普遍存在的面試問題以及應對之道（新書第一章節摘錄）
其實大多數Java開發確實能勝任日常的開發工作，但不少候選人卻無法在面試中打動面試官。因為要在短時間的面試中全面展示自己的實力，這很需要技巧，而從當前大多數Java開發的面試現狀來看，會面試的候選人不多。所以在展開講述分散式元件面試技巧前，就先給出大多數候選人普遍會出現的問題，這需要大家引以為戒。
1 不少人只會“增刪改查”
對於Java初級開發而言，平時的主要工作確實只是“增刪改查”，即需要根據不同的業務需求，用Java和資料庫等技術實現各種增刪改查功能。而對於Java高階開發乃至架構師而言，日常工作中除了要做“調優”、“元件架構設計”和“問題排查”等高階的技術工作以外，“增刪改查”之類的開發工作也會佔到一定的比重，但在面試中，你不能讓面試官感覺你除了“增刪改查”之外，不會其它技能。
• 資料庫效能調優方面的問題，比如，在專案裡，你是怎麼用索引和執行計劃等方式優化SQL語句的效能？
• Java虛擬機器記憶體調優方面的問題，比如，在專案裡，請舉例說明你是怎麼排查OOM問題？或者你在開發業務功能時，用過哪些措施來提升JVM（Java虛擬機器）的記憶體效能？
• 資料庫和分散式元件叢集方面的問題，比如，你們專案裡是如何用（資料庫或Dubbo或Redis）叢集來確保服務高可用？
• 分散式元件綜合應用方面的問題，比如，你們專案裡用到過哪些分散式元件？它們是如何整合到一起來應對高併發的需求？
由於目前大多數的專案需要工作在高併發的場景裡，所以對應地在面試中，有極大的可能會問及上述效能調優、分散式叢集乃至其它應對高併發方面的問題。所以如果候選人僅在面試中展示“增刪改查”做專案的技能，那麼就可能只 能應聘技術含量較低的開發工作，比如外派和外包類工作。
2 能背題，但不大會結合專案講技術
目前在網際網路上能搜尋到很多Java方面的面試題，比如有演算法方面的，有Java核心（Java Core）基礎知識方面的，有資料庫方面的，有Spring Boot或Spring Cloud等web開發方面的，甚至也有分散式元件和叢集架構方面的，不少比較上心的候選人也會在面試前依次做充分的準備。
面試前確實需要背題，而且有些關於底層程式碼和原理型別的說辭也能幫到候選人，但如果僅僅複習這些題目的話，可能只能掌握理論層面的知識點，無法在面試中向進一步向面試官展示你在實際專案裡用過相關技能，而面試官恰恰是對後者更感興趣。
這裡來講一個面試問題的案例，比如面試官提問：“說下Java集合裡ArrayList和Vector兩種物件的區別？”，如果看過相關的面試題，候選人一般也能說出如下的說辭：“Vector是執行緒安全而ArrayList是執行緒不安全，同時在擴容時，Vector會擴容100%，而ArrayList是50%。”說到這個程度，面試官會認為候選人知道這兩種物件，
但如果候選人再進一步給出如下的說辭：“在上個專案裡的，如果遇到單執行緒的工作環境，我會使用ArrayList之類的執行緒不安全物件，而且出於提升記憶體效能的考慮，在專案裡我是使用ArrayList，因為它的擴容比例較低。”
雖然上述說辭也就寥寥幾語，但由於結合到了專案，所以面試官會因此確認候選人真實在專案裡用過，但這種“結合專案說技術”的能力，可能是候選人，尤其是初級開發層次的候選人普遍缺乏的。
或許在Java核心基礎技能方面，“結合專案經驗說技術”這種做法對候選人幫助並不大，那麼在分散式元件方面，“能結合專案說技術”的候選人與“僅會背題”的候選人之間的差別就足以決定面試成敗了。來看下相關的面試案例。
又如在Redis方面，假設某候選人只是根據網上的面試題，瞭解了Redis資料結構和底層程式碼甚至搭建叢集的做法，那麼面試官只要用類似“結合專案說下Redis怎麼用的”之類的問題就能問倒這位候選人，但如果另外一位候選人能結合使用場景說下配置、快取資料的細節以及防穿透等專案實踐要點，那麼就能有效證明自己在專案裡用過Redis。其實在面試中有不少候選人只會背題說理論，所以只要讓面試官認為你在專案裡做過，那麼你就可以比那些只會背題的人強。
本書會在分散式元件方面，一方面結合案例告訴大家在專案裡使用分佈元件的實踐要點，另一方面會結合這些實踐要點為大家整理相關面試說辭，並且還會在此基礎上給出“Redis防穿透”、“Dubbo防超時”以及“Kafka防重發”等亮點技術的展示方式，從中大家能直觀地掌握分散式元件方面準備面試的技巧，並能以此在面試中成功地超越大多數競爭者。
3 linux層面，普遍缺乏基本操作技能
確實大多數的專案是在windows作業系統上開發的，所以有不少候選人沒有接觸過linux等其它作業系統。根據作者技術面試官的經驗，不少候選人會認為，開發好的專案是部署在windows系統上，分散式元件是安裝在windows系統上的，日常排查問題，也只需要觀察windows系統上的日誌。
但實際情況不是這樣，分散式元件乃至叢集，大多部署在linux系統上，開發好的Spring Boot等型別的專案也是部署並執行在linux系統上，所以面試官在面試過程中問及linux操作等相關問題，也就絕非是為難候選人了。
大家可以試想一下，如果某位候選人連如何在linux上查詢並開啟檔案，並在檔案裡查詢關鍵字串之類的問題也說不上，那麼如何證明自己真的在專案裡排查過問題？甚至有些面試官會以此認為候選人只會“在windows系統上開發增刪改查”這類初級的技能。
其實哪怕對初級開發而言，要準備linux方面的面試，難度也不大，只需要準備些基本的檔案操作命令，外帶些基本的script指令碼操作技能即可。也就是說，大家只需要稍微花點時間，根據本書後繼章節裡給出的步驟準備linux方面的說辭，就能在面試中讓面試官有耳目一新的感覺，更何況通過linux操作技能，候選人還能有效地展示自己“分析、排查和解決問題”方面的能力。
4 排查和解決問題的能力，很多人不會展示
大家可以試想一下，面試官最希望候選人有相關技術的專案開發經驗，所以如果候選人能有效證明自己在之前的專案裡，有排查和解決線上問題的經歷，那絕對是個加分項。
但在面試過程中，很多候選人只是被動地回答問題，除此之外不會主動擴充套件。這樣如果遇到不善於挖掘候選人亮點的面試官，那麼這些被動回答問題的候選人是沒有機會展示這類加分項的。
在後繼講述Redis、Dubbo和Netty等分散式元件時，作者會給出針對相應元件“排查和解決線上實際問題”的技巧和說辭，這裡先給出展示這類加分項經歷的通用步驟。
第一， 先說下對應的線上故障，比如某個系統不可用了，或者系統輸出和預期的不同，或者在日誌檔案裡發現錯誤日誌。
第二， 再說下根據錯誤日誌定位到問題的流程，比如通過Redis哪些日誌發現Redis有超時問題。
第三， 再說下通過日誌看到的錯誤和故障之間的因果關係，比如因為Redis超時，所以返回時間變長，這導致服務不可用。
第四， 最後說下怎麼解決的，比如在配置檔案裡對應地縮小Redis超時時間。
這樣候選人就能高效地在面試中展示相關技能地專案實踐經驗。而且請大家注意，這種“排查和解決問題”的相關說辭，在面試中怎麼說都不會嫌多，所以在面試前，候選人可以針對“調優”、“高併發分散式應用”和“分散式叢集”等諸多值錢技術，儘可能多地準備相關說辭。
5 被動回答問題，缺乏主動引導和丟擲亮點的意識
剛才也提到了，不少候選人在面試中只會被動地回答問題，這樣就拱手讓出面試裡的提問權，如果面試官問的問題不巧是候選人不熟悉的，那麼面試結果可想而知。
但其實只要在回答好相關問題後，再多說幾句話，就有可能把面試官的問題引導到你準備好的各種亮點說辭。其實這種“引導”技能一學就會，而本書在後繼講具體分散式元件的章節裡也會較多地給出這種引導說辭，這裡先給出些範例，請大家體會下這種引導的做法以及可能會帶來的好處。
比如當你回答好JDBC裡Connection元件的相關問題後，再多說一句，“在我們專案裡，除了用JDBC連線資料庫外，還用到了Redis快取來提升資料庫效能”，這樣面試官就很有可能繼續問Redis相關問題，這樣你就有機會展示面試前準備過的Redis叢集和防穿透等亮點說辭。
又如你回答好Redis防穿透方面的問題後，也可以再多說一句，“在之前的專案裡，我們還解決過Redis防穿透方面的線上問題”，當面試官細問時，你可以繼續說，“是通過日誌發現了Redis穿透問題，原因是沒有在Redis裡快取空資料和不存在的資料，後面快取這類資料就解決了”，也就是說這裡成功地把面試官的問題引導到“解決線上實際問題”的方面，併成功地展示了Redis方面的實際專案經驗和排查問題的能力。
其實不少面試官在面試前，還在辛苦地修改bug或者參加各種會議，也就是在面試前草草地瀏覽了一遍候選人的簡歷，而且也不大會準備面試問題，很多問題都是在面試中臨時想的。所以當候選人在面試中丟擲這類“引導”說辭後，面試官很有可能順著這個話題繼續問下去，通過這種方法，候選人就可以在面試中把問題儘量引導到自己準備過的範圍內。
6 準備面試的難度，要低於做好專案的難度
怎麼才算做好一個專案？要確保專案裡沒有各類bug，而且還要把專案成功部署上線，並且還要有效修復專案在線上執行時遇到的各種問題。怎麼才能通過面試？回答出面試官的關鍵提問即可。
專案裡遇到問題的種類和數量是不可測的，而面試官提的問題大多是有套路的，而且開發專案的週期至少幾個月，而技術面試的時間最多也就持續一個小時，所以準備面試的難度，要低於做好專案的難度。
一般面試分技術面試、專案經理面試和人事面試這三輪，本書更多會地會關注技術面試。技術面試一般二三十分鐘，再長一般也不會超過一個小時，具體流程一般如下所述。
1. 寒暄後會讓候選人介紹諸如學歷和工作過的公司等基本情況，這些說辭面試前可以準備。
2. 隨後會讓候選人介紹最近的（或最拿得出手）專案情況，此時候選人可以用本書將要給出的方法，根據面試前的準備，結合專案實際丟擲各種亮點說辭，並可以把後繼面試官的提問引導到準備好的範圍內，也就是說，介紹專案環節也可以準備。
3. 在介紹完專案情況後，面試官一般就會自由提問。說是自由提問，但也會圍繞著職位介紹上提到的技術點提問，如果是招Java方面的程式設計師，分散式元件方面也是一個考核點。這時，如果候選人能用到前文提到的引導技術，就能儘可能多地把面試官的問題控制在自己熟悉的範圍內。
4. 面試官可能再會問些資料結構和演算法等方面的問題，不過這類問題也可以通過刷題來準備。
5. 最後面試官會讓候選人提問，這個環節也可以準備，候選人還能借機丟擲之前沒機會展示的亮點說辭。
從中大家看到，做好專案和準備技術面試是兩個不同維度的事情，前者是動手做，後者是開口說。而且如果在面試前準備充分，面試時絕對能結合專案丟擲各種亮點說辭，或者可以通過“邊寫（細節）邊畫（框圖流程圖等）邊說”的方式展示你對某個技術的理解，甚至還可以通過“回答好問題再多說一句”的方式引導面試官的問題。也就是說，通過準備面試以及在面試中引入各種技巧，候選人不僅能最大程度展示自己的亮點，還能有效地避免面試官過多地問及自己的薄弱點，這樣就能有效提升通過技術面試的可能性。
7 準備面試的錯誤做法和正確做法
前文也說到，準備面試的難度要低於做好專案的難度，但事實上有不少候選人由於事先沒有準備，或者準備方法不得當，從而無法通過面試，其中可能還不乏一些在專案組裡承擔重要作用的技術大牛，這也是為什麼很多候選人在面試中表現不佳的原因。
其實原因前文裡也提到過：準備面試和做好專案是兩個維度的事情。在給出面試的正確準備方法之前，先來對比性地看些錯誤的準備做法。
1. 只根據之前專案裡用過的技術準備面試。由於程式設計師日常開發工作大多是“增刪改查”，所以接觸到的值錢技術非常有限，單憑此無法拉開和其它競爭者的距離，所以這樣做哪怕最後面試成功，能力和薪資也有可能被低估。
2. 過多地刷演算法題或程式設計題或相關面試題。要知道面試官一定會考核候選人相關技術的專案實踐能力，如果就這樣準備，可能面試初級開發崗位時還有機會過，但可能就很難應聘成高階開發崗。
3. 僅在理論層面背些（分散式元件等方面的）說辭。對於這些值錢說辭，面試官大概率會問技術實現細節和排查問題的步驟，如果單憑理論說辭，無法有效證明自己在專案裡用過這些值錢技能。
對應地，正確的面試準備方法就呼之欲出了。這裡給出的方法不僅涵蓋了分散式元件方面，更適合於準備其它Java方面的面試。
1 . 刷題等必要工作不能拉下，因為面試裡也有可能問及相關問題，同時結合專案展示基本技能的說辭也得準備。
2. 結合你做過的專案，儘可能多地準備值錢技術方面的亮點說辭，比如你能結合之前開發過的風控模組業務，說出Dubbo遠端呼叫流程，這要比你單純從理論角度講要好很多。最好是類似的值錢技術，都找個和專案的結合點。
3. 不僅要結合專案準備亮點說辭，更需要準備丟擲這些亮點說辭的預案。比如你在面試前充分準備了Dubbo、Redis和Netty等方面的說辭，但面試官一直不問及，你也不能自說自話地展示。對應地，你需要準備“回答好SQL問題後引導到Redis元件”的話術，或者是“回答好Redis資料結構問題後引導到Redis快取調優”的話術。總之對於你準備好的亮點說辭，你都要準備一套或多套“引導方案”，這樣就能最大程度地展示你的亮點。
本書之後會詳細展開描述上述準備方法。當然不乏有一些資深的面試官會很好地把控面試走向，不大會輕易被候選人的話術所引導。但你如果用到了上述準備方法，哪怕是遇到這類面試官，也能最大程度地丟擲亮點說辭。況且你遇到的很多面試官可能是技術大牛，但在面試方面未必經驗豐富。
8 面試時可以主動丟擲的亮點彙總
對於前文提到的亮點說辭，Java程式設計師可以從哪些方面準備呢？其實有些話題上文已經提到過，這裡更多的是總結性歸納。
第一， 底層原始碼方面。往淺了講，可以講述Java核心物件方面的底層原始碼，比如ArrayList擴容、HashMap讀寫操作等底層實現，往深了講，可以講述Spring層面的底層原始碼，比如IOC機制如何注入物件，或者切面程式設計裡如何關聯物件和切面程式碼。再往深了講，就可以講分散式元件的底層原始碼，比如Dubbo的服務暴露或者Netty裡的零拷貝。通過底層原始碼講述對應的實現機制，能讓面試官感覺你在這方面很專業。
第二， 效能調優方面。這裡可以從JVM垃圾回收機制講到記憶體調優，也可以在資料庫調優方面從索引引申到Redis快取或MyCAT分庫分表元件，甚至可以再講述資料庫和快取叢集，當然最好是要結合專案案例講。通過展示這種技能，就讓面試官感受到你技術的深度。
第三， 監控、分析、排查和解決問題的能力。候選人可以結合案例從“通過監控或日誌發現問題”、“通過日誌分析排查問題”和“對應給出解決方案”這三個角度來說明，如果可以，再加上“分散式元件”、“效能調優”、“分析底層原始碼”和“同其它組合作解決”這些關鍵要素。在面試實踐中，這部分的亮點說辭甚至能很好地抵消掉一些候選人在次要技能方面的不足。
當然Java面試中可以丟擲的亮點絕非只有這些，但在最多持續一個小時的面試過程中，候選人哪怕就充分丟擲上述三個方面的亮點，就足以影響到面試結果。
而且，對於Java初級開發和高階開發而言，分散式元件方面的使用經驗都可以算是亮點。小到使用基本語法，中到使用叢集，大到排查問題，只要結合專案說好了，也都是加分項。
9 不是總結，僅是開始
本文是我講分散式元件面試技巧書的第一個章節裡的部分內容，在其中僅是介紹大多數候選人的現狀，並對應地給出了相關方法。
由於是第一個章節，所以很多方法只是亮相，並沒有詳細展開，甚至還沒涉及到分散式元件這塊。在後繼章節裡，本人將圍繞Dubbo，Redis，Kafka，Netty等分散式元件，結合案例向大家講述面試準備技巧和在面試中結合專案展示分散式技能的方式。對此，本人將在後繼的博文裡，陸續摘錄相關文章，敬請期待。
而且本書尚在編寫過程中，預計半年後出版，書出版後，也請大家多多支援。
版權說明：如要轉載本文，請事先徵得本人同意。
&n