這篇文章對很多沒有高併發經驗的程式設計師來說，會非常有幫助。
很多程式設計師可能都遇到過類似的困惑：
我沒有高併發專案經驗，但是面試的時候經常被問到高併發、效能調優方面的問題，該怎麼辦？
這個問題怎麼解決？和大家說說我招人的一個經歷。
程式設計師小張參加工作已 5 年，是一位高階工程師，是我親自招進公司，表現很出色。
前一陣子，我把小張叫進會議室，想讓他單獨帶個團隊。其中，我談到了面試時，他簡歷注水的問題。
事情是這樣的，大概兩年前，公司有個核心專案缺人，需要一位高階程式設計師。這個崗位非常重要，所以對面試人要求不低：
- 有高效能、高併發開發經驗
- 有高可用系統經驗
- 參與中介軟體研發、優化和系統儲存優化
招聘持續了兩個月，面試了許多工作五年以上甚至十年的人選，卻依然沒有招到一個特別合適的。
就在我們快不抱希望的時候，同事讓我去面試一個有趣的人，他強烈推薦，並順手把簡歷遞給了我，這人正是小張。
接過簡歷後，我先翻了翻。這一翻，讓我皺起了眉頭。
簡歷裡，小張的工作經驗只有區區三年，這三年全都在一家公司，公司本身還沒有什麼名氣。
更重要的是，我懷疑他的簡歷做了手腳。
他說自己三年裡，負責過兩個專案，一個是電商專案，一個是關於這個電商專案的對外開放平臺。對這兩個專案，他著重強調了專案的高併發，並說自己解決了很多技術難題。
就是這裡出現了問題。我們當時也有電商專案，市面上稍微有點名氣的電商平臺我都非常清楚，卻沒聽說過他簡歷裡的產品。所以我懷疑，這份簡歷是包裝過度了。
但是，對於這麼明顯的問題，我不信前面的面試官們都沒看出來。那麼，為什麼他們還推薦我去見見呢？
說心裡話，對簡歷包裝過度我是比較惱火的，但是這只是我的懷疑。同時，前面的面試官竟然是帶著一種從未有過的滿意語氣，叫我一定面面他，對同事們的認可我又比較好奇。
就這樣，我帶著惱火又好奇的矛盾心思見到了小張。
見到小張的時候，我由於有點惱火，臉色顯得非常嚴肅。他可能看到我如此嚴肅，不禁侷促了起來。但是，從他的眼神中，我又看到了很強的自信。我心裡想，確實挺有趣的人。我決定要好好的面試下這個人，看看他到底有什麼本事，能讓我的同事如此滿意。
問了下他大概背景後，開始了進入了正題。當進入了正題之後，小張的回答態度就讓我大加讚賞。態度自信，不卑不亢，邏輯表達也十分清晰明白。
這時候，我心裡決定，如果小張後續的回答，能證明他的實力達到簡歷描述的八成水平，我會傾向於把 offer 給他。
我先問了問他對高併發的理解，比如
高併發需要參考哪些指標？
他告訴我，高併發由於產品型別不同，所以指標都不一樣。以他負責的電商系統來說，根據模組的不同，關注的指標不同。商品瀏覽看得是 QPS，訂單模組則是看得 TPS。同時，他們還需要關注活躍的使用者量等等。
這回答真不錯。面試以來，哪怕是工作多年的人，絕大多數的答案就是 QPS，無非再多一個 TPS。能把產品型別的不同和不同的高併發指標之間關聯起來，這說明小張是仔細對這個問題思考過的。
我愈發滿意了。在後面，我又追問了叢集部署、多級快取、複雜查詢優化等有關效能優化的問題，還附加了系統高可用的各種策略，和如何拆分去保證靈活擴充套件等實際中我們正在採用的問題。
等面試完畢後，時間已經過了一個多小時。小張當時並沒有百分百答好我問的問題。
從實際回答來看，關於效能優化的細節，比如，系統瓶頸的檢測和優化，程式邏輯的優化，JVM 優化甚至資料庫的優化都答得異乎尋常的出色。
但是，對於高可用的大概策略，比如降級處理，限流處理等，他只知道大的方向，很多答案一聽就知道是從書本上或者網際網路上看來的。
而對於系統的擴充套件性相關問題，他甚至答的非常差，很多都回答不上來。
不過瑕不掩瑜，小張依然拿到了 offer，他期望的薪資我也沒有打任何折扣，這足以給他一份大大的驚喜了。
在後來的兩年裡，小張的出色表現，證明我沒有看錯他。
他為了公司的核心專案做出了巨大貢獻，而他的技術水平，也有了肉眼可見的巨大提升。他成為了一名高併發經驗豐富的高階程式設計師。所以，現在打算讓他帶團隊了。
“那麼，就剩一個問題了。你面試之前到底是如何做到熟悉高併發的效能優化的？” 我好奇的問出了我壓在心底的問題。
小張不太好意思的撓了撓頭，他詳細給我講述了他是如何搞定高併發經驗的。
我聽完後，真的是對他這些準備讚不絕口。我認為該分享出來，讓更多的人看到。
劃重點！
劃重點！
劃重點！
如果你也渴望有高併發經驗，那麼下面的內容你要格外關注了。
小張確實是做了電商平臺開發的。但是，這個電商平臺沒多少訪問量，QPS 可能一隻手都能數的過來。說句難聽話，也就是掛在網上而已。
他剛畢業入職開始，就參與維護了這套電商平臺。就這樣持續了一年後，他發現自己已經無法再有任何提高了。
他想跳槽，但是發現很多高階崗位都是要求高併發經驗的，他對此很著急。如果他繼續在以前的公司發展，就勢必接觸不了什麼高併發。但是跳槽的話，他又必須有高併發經驗才能找到一個不錯的崗位去繼續提升自己。
這貌似成了一個死結。
在百般無奈之下，他決定自己模擬高併發去獲得經驗。
現在總結下來，其實他的練習可以粗略分為三個階段:
第一階段
這個階段，小張完成了在高併發條件下，對單機效能優化的學習。
小張用 Docker 容器去執行他維護的電商專案。然後用 jmeter、wrk 等工具去壓測。
在壓測期間，他敏銳地發現了由於系統每個模組不同，所以效能表現就不一樣，這種現象引發了他的思考。他經過網路搜尋和查詢資料，明白了不同模組、不同產品對併發指標的要求是不一樣的。
基於這種情況，他又根據產品的業務邏輯編寫了複雜的壓測指令碼，能自動實現不同模組的壓測任務。
就是在這種不斷地壓測探測下，他明白瞭如何探測問題，如何通過優化程式碼、JVM 去解決問題。
比如，解決誤用 HashMap 導致死迴圈的問題。又比如，誤用不帶快取的檔案 IO 流，去讀取檔案的問題等等。
在程式和 JVM 優化完畢後，他又發現資料庫也存在問題。於是，他又學會了如何優化資料庫 SQL，如何對資料庫分表等問題。
也是在這個階段，他認識到了快取的必要性以及同步快取資料狀態的重要性等重要知識點。
小張在搞了單機優化後，他覺得也沒有辦法再通過單機的壓測學到什麼新的東西了。於是，他轉向了第二階段。
第二階段
小張從阿里雲買了兩臺機器，他開始嘗試使用負載均衡去分擔高併發的壓力。
同樣的，也是藉助壓測工具去模擬了高併發。在壓測期間，負載均衡和系統屢屢出現和單機完全不一樣的問題。
比如，負載均衡本身的效能問題。比如，在一些時候，負載均衡後面的機器負載是不平衡的，需要對負載演算法進行調整。
這個階段，小張理解了負載均衡中大部分的細節。
但是，高併發中，很多系統的構成會很複雜，以至於需要分散式架構系統的程度。他們需要各種中介軟體做通訊，做儲存。
所以，小張根據招聘的一些需求，他做了第三階段的練習。
第三階段
為了能熟悉市面上各中介軟體的使用，小張把他那套電商平臺改了又改。
比如，一些本地呼叫的方法，被他替換成了 Dubbo 遠端呼叫。比如，一些模組間呼叫，被他替換成了 MQ 中介軟體傳訊息。再比如，一些放在關聯式資料庫的被頻繁訪問的資料，被他改存在了 MongoDB 中……
當然，壓測依然繼續。就這樣，小張又實踐了很多中介軟體和分散式框架的使用。
在模擬高併發練習的同時，小張不忘去讀各種高併發高效能的書籍。比如，《大型網站伺服器容量規劃》、《網際網路創業核心技術：構建可伸縮的web應用》等書籍。
在來到我們公司面試之前，小張如此練習了兩年左右。
雖然小張面試的時候表現也存在很多不足，但是我當時看中他的一些優點是:
1. 小張滿足具有高併發經驗的要求
為什麼我們需要找有高併發經驗的人？
說白了，我們想找的程式設計師其實是：
- 不會亂寫效能很差的程式碼
- 能敏銳感知到影響系統的問題
- 能獨立的處理由於高併發引發的問題
小張通過他的練習是掌握了這些技能的。
2. 小張滿足熟悉高可用的要求
我們找熟悉高可用的人，其實並不要求這個人一定能給出什麼獨特的高可用方案。我們要求的是，他能知道高可用的知識後，去意識到高可用的重要性。
比如限流功能出現問題，他要能馬上認識到這是個很重要的問題，從而把解決的優先順序提到很高。
小張通過學習，明白了高可用的重要性，也知道了高可用的大方向，這就夠了，剩下的細節，我們有信心帶小張在實際工作中學出來。
3. 小張能參與我們的中介軟體研發和儲存優化
小張主動改造過他們的電商系統，而且使用了很多的中介軟體，並對這些中介軟體都進行過優化。對這些中介軟體的特性比較熟悉，並且在實踐中，他也瞭解了很多原理。
除此之外，小張的主觀能動性尤其打動我們。他對技術的主動鑽研、主動學習，表明了他是一個喜歡走出舒適區，願意挑戰自己的人。而這樣的人，有哪個團隊不歡迎呢？
所以，其實沒有高併發經驗並不可怕。
如果在工作中你接觸不到高併發的專案，那麼也沒必要太糾結。公司做什麼專案你改變不了，你能改變的只有你自己。關鍵還是自己要去主動學習，主動練習，主動提升。只有這樣的人，機會才會去垂青。
最後，畢竟在程式設計師這個圈子，90% 以上的人可能都沒有真正的高併發經驗，所以在此也希望各位面試官，在招人的時候，如果遇到好苗子可以適當寬容一些，給新人們一點機會，說不定能找到一匹千里馬。
碼字不易，看完之後如果覺得有幫助，希望你能幫忙隨手點個贊，你的支援對我很重要。
最最後，推薦一本高併發相關的開源書籍：《深入淺出Java多執行緒》
本書的作者們都是阿里、ThoughtWorks 等大廠的高階程式設計師。
我看了一部分，雖然還沒全部看完，但是我已經迫不及待的想給這本書點讚了。
不多說了，我們直接看目錄：
書裡還有很多例子，可以說是圖文並茂。
獲取方式：關注我的公眾號【四猿外】，關注後在後臺回覆 666 。
還有更多幹貨資料不定期更新
你好，我是四猿外，一家上市公司的技術總監，管理的技術團隊一百餘人。
我從一名非計算機專業的畢業生，轉行到程式設計師，一路打拼，一路成長。
我會把自己的成長故事寫成文章，把枯燥的技術文章寫成故事。