其實大多數Java開發確實能勝任日常的開發工作，但不少候選人卻無法在面試中打動面試官。因為要在短時間的面試中全面展示自己的實力，這很需要技巧，而從當前大多數Java開發的面試現狀來看，會面試的候選人不多。所以在展開講述分布式組件面試技巧前，就先給出大多數候選人普遍會出現的問題，這需要大家引以為戒。
1 不少人只會“增刪改查”
對於Java初級開發而言，平時的主要工作確實只是“增刪改查”，即需要根據不同的業務需求，用Java和數據庫等技術實現各種增刪改查功能。而對於Java高級開發乃至架構師而言，日常工作中除了要做“調優”、“組件架構設計”和“問題排查”等高級的技術工作以外，“增刪改查”之類的開發工作也會占到一定的比重，但在面試中，你不能讓面試官感覺你除了“增刪改查”之外，不會其它技能。
比如作者在做技術面試官面試候選人時，發現不少人確實能很好地結合之前做過的項目需求，展示用Spring和數據庫等技術實現各種業務需求的能力，也確實能回答用相關技術實現“增刪改查”業務功能的相關問題，但被問及如下其它方面的問題時會一籌莫展，不少候選人甚至連相關術語都沒聽說過。
• 數據庫性能調優方面的問題，比如，在項目里，你是怎么用索引和執行計划等方式優化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等分布式組件，結合案例向大家講述面試准備技巧和在面試中結合項目展示分布式技能的方式。對此，本人將在后繼的博文里，陸續摘錄相關文章，敬請期待。
而且本書尚在編寫過程中，預計半年后出版，書出版后，也請大家多多支持。
版權說明：如要轉載本文，請事先征得本人同意。