這篇文章對很多沒有高並發經驗的程序員來說，會非常有幫助。
很多程序員可能都遇到過類似的困惑：
我沒有高並發項目經驗，但是面試的時候經常被問到高並發、性能調優方面的問題，該怎么辦？
今天給大家說一自己學習高並發的方法。
你可以自己寫一個小的電商項目，建議最簡單的單體結構的電商項目即可。
從最簡單的單體項目開始，然后按照以下三個階段來學習高並發。
第一階段
在高並發條件下，學習對單機性能優化。
用 Docker 容器去運行電商項目，然后用 jmeter、wrk 等工具去壓測。
在壓測期間，你會發現：由於系統每個模塊不同，所以性能表現就不一樣。
這是正常的，不同模塊、不同產品對並發指標的要求本身想·是不一樣的。例如，商品瀏覽和下訂單，一個讀為主，一個寫為主。
基於這種情況，你最好要編寫復雜的壓測腳本，能自動實現不同模塊的壓測任務。
然后在這種不斷地壓測探測下，去探測問題，並且通過優化代碼、JVM 去解決問題。
比如，解決誤用 HashMap 導致死循環的問題。又比如，誤用不帶緩存的文件 IO 流，去讀取文件的問題等等。
在程序和 JVM 優化完畢后，你可能又會發現數據庫也存在問題。於是，你又要去研究如何優化數據庫 SQL，如何對數據庫分表等問題。
也是在這個階段，你可能還會學的到，緩存的必要性以及同步緩存數據狀態的重要性等重要知識點。
在搞了單機優化后，沒有辦法再通過單機的壓測學到什么新的東西了。於是，轉向第二階段。
第二階段
從阿里雲買了兩台機器，開始嘗試使用負載均衡去分擔高並發的壓力。
同樣的，也是借助壓測工具去模擬了高並發。在壓測期間，負載均衡和系統屢屢出現和單機完全不一樣的問題。
比如，負載均衡本身的性能問題。比如，在一些時候，負載均衡后面的機器負載是不平衡的，需要對負載算法進行調整。
這個階段，你會接觸到負載均衡中大部分的細節。
但是，高並發中，很多系統的構成會很復雜，以至於需要分布式架構系統的程度。他們需要各種中間件做通信，做存儲。
所以，繼續第三階段的練習。
第三階段
為了能熟悉市面上各中間件的使用，開始對單體的電商平台進行改造。
比如，一些本地調用的方法，替換成 Dubbo 遠程調用。
比如，一些模塊間調用，替換成 MQ 中間件傳消息。
再比如，一些放在關系數據庫的被頻繁訪問的數據，改存在 MongoDB 中……
當然，壓測依然繼續。就這樣，你可以實踐到很多中間件和分布式框架的使用。
在模擬高並發練習的同時，別忘了去讀各種高並發高性能的書籍。比如，《大型網站服務器容量規划》、《互聯網創業核心技術：構建可伸縮的web應用》等書籍。
三個階段的學習之后，面試的大部分基礎問題你基本可以應付了。
畢竟在程序員這個圈子，90% 以上的人可能都沒有真正的高並發經驗。作為面試官來說：
為什么我們需要找有高並發經驗的人？
說白了，我們想找的程序員其實是：
- 不會亂寫性能很差的代碼
- 能敏銳感知到影響系統的問題
- 能獨立的處理由於高並發引發的問題
我們找熟悉高可用的人，其實並不要求這個人一定能給出什么獨特的高可用方案。我們要求的是，他能知道高可用的知識后，去意識到高可用的重要性。
比如限流功能出現問題，他要能馬上認識到這是個很重要的問題，從而把解決的優先級提到很高。
通過以上三個階段的學習和練習，基本是可以掌握這些技能的，這就夠了，剩下的細節，就靠在實際工作再實踐吧。
此也希望各位面試官，在招人的時候，如果遇到好苗子可以適當寬容一些，給新人們一點機會。
你好，我是四猿外。
一家上市公司的技術總監，管理的技術團隊一百余人。
我從一名非計算機專業的畢業生，轉行到程序員，一路打拼，一路成長。
我會把自己的成長故事寫成文章，把枯燥的技術文章寫成故事。
歡迎關注我的公眾號。
