同學信誓旦旦地說，我司的系統從來不做性能調優！

前幾天，和一個同學瞎聊，他說，“我們公司的系統從來都沒有經過性能調優，集成測驗沒問題后就上線了，上線后也幾乎沒出現過性能問題，”

我當時沒回他，因為沒遇到性能問題不代表程式不存在性能問題，只能說明系統的訪問量有點小，有印象吧？每次明星爆出個大瓜，微博就掛了，那就是因為短時間內訪問量暴增后，扛不住壓力，出現了性能瓶頸，

大部分的性能問題都是由于訪問量過大導致的，我記得汪峰在京東做過一次直播，那畫面卡成狗，幾乎沒法下單，畫面都出不來，因為京東之前沒做過直播，沒遇到這么大訪問量，估計那次活動結束后，直播方面的開發沒少挨批，

還有一部分性能問題是隨著時間積累爆發的，程式在服務器上運行一段時間后就要重啟，否則某個時間節點記憶體就突然爆掉了，反正我司一些專案就遇到過這方面的尷尬，一開始的解決方案就是寫個腳本，在夜深人靜的時候，偷偷地重啟釋放一下記憶體，

在性能方面要求最高的我認為就是 12306，搞不好是要被全國人民罵街的，以前在蘇州的時候，不論是不是節假日，每次坐火車回洛陽，或者從洛陽去蘇州，都感覺同伴好多啊，怎么這么多人坐火車，不是南下就是北上，不是東進就是西出，遇到春運的時候，12306 承載的壓力可想而知有多大，秒殺活動壓根沒法和它相提并論，

如果有小伙伴為 12306 作業過，那可以吹一輩子的牛逼了，你比在淘寶雙十一作業過的小伙伴牛逼一萬倍（嗯，我先替你吹一波，據說 12306 的高峰訪問是 10 億 PV，非常 BT），

知道了性能調優的重要性后，我來問問小伙伴們，什么時候介入性能調優會比較好？

如果你的回答是“越早越好”，那顯然是錯誤的答案，

我在之前的文章中提到過軟體開發的一條原則，就是“Done is better than perfect”，因為“perfect is never done”，性能調優是一項持久戰，很早就開始介入，并不是一件好事，

你想啊，系統第一時間上線才是最重要的，不然你一邊想著性能調優，一邊疲于開發進度，可能兩者都做不好，反而拖累了系統研發的進度，等你系統上線了，可能用戶已經被別的系統搶走了，你永遠都沒有性能調優的機會了，

不要總想著把所有的功能做完善，做完美后再上線，應該在產品具有一定的雛形后就立即上線試錯，根據用戶的反饋，根據市場的需求再去考量是否追加一些其他的功能或者優化，

那我再來問問小伙伴，哪些因素會成為系統的性能瓶頸呢？閉上眼睛，轉個圈，想一想，

• 資料庫：幾乎所有的系統都會用到資料庫，大量的資料庫讀寫操作會嚴重影響到系統的性能，所以資料庫快取技術 Redis 變得越來越重要，另外，系統運行時間久了之后，資料量就會變得非常大，不僅需要在 SQL 上做很多優化，還要在分庫分表上下足功夫，

• 網路：如果你家的網速很慢，那就要去問問運營商，你家的帶寬多少，或者，至少檢查一下，你家的網線是百兆的還是千兆的，雖然網線都很短，短到只有貓到路由器那么一小節，網路帶寬如果太小的話，就意味著資料傳輸得很慢，就像跑車到市區，搞不好還沒有自行車快，

• 磁盤：我家里的臺式機都換成了固態硬碟，換了之后的速度就比之前普通硬碟的快很多，多說一點，資料庫的讀寫操作就是磁盤 I/O，而 Redis 之所以快，就是因為 Redis 操作的是記憶體，但 Redis 牛逼的一點在于它不僅可以做快取，還可以將資料持久化到磁盤，

• 記憶體：記憶體的讀寫速度比磁盤快得多，但空間遠沒有磁盤那么大，一般家用的計算機記憶體在 16G 已經是很高的配置了，眾所周知，Java 程式是通過 JVM 分配記憶體的，創建的物件都放在堆記憶體上，操作起來就很快，但如果代碼寫得有問題的話，就很容易造成記憶體溢位，

• CPU：CPU 的計算速度快到超出人的想象，所以阿爾法狗可以輕松地打敗柯潔，如果，我真的是說如果啊，放在 CPU 還是奔騰的年代，柯潔還是可以輕松打敗阿爾法狗的，如果程式涉及到大量的背景關系切換，或者造成 JVM 頻繁的 GC，就很容易長時間占用 CPU，導致出現性能問題，

在實際的作業當中，小伙伴們也可以按照上面的順序進行性能調優，一開始，不要盲目對記憶體和 CPU 下手，這個難度有點大，并且效果不明顯；搞不好，還會影響到整個系統的使用，先從資料庫、網路和磁盤著手優化，很容易看到效果，并且不容易出錯，

最后一個問題，小伙伴們知道系統的性能指標嗎？

1）回應時間

很多年以前，我干過一件很蠢的事，公司有一臺閑置的云服務器，是 Windows Server 版的，剛好有一客戶想體驗我司的系統，我就沒想那么多，把系統部署到了這臺云服務器上，

結果呢？

首頁打開的速度超級慢，慢到需要將近一分鐘的時間，不僅客戶的下巴驚掉了，我自己的也掉了，

為了挽回顏面，我對首頁相關的后端和前端做了很多優化，后端刻意使用了快取技術，減少了 SQL 陳述句的查詢；前端壓縮了 JavaScript 和 CSS，減少了請求數，甚至更換了 CDN，使用了圖片懶加載，但收效甚微，

最后靜下心來想了想，同樣的代碼，部署到 Linux 環境下的那個系統就很快，就算是第一次打開首頁需要加載資源，回應時間仍然短到無法感知，于是就把 Windows Server 重裝成了 CentOS，效果立竿見影，回應時間短到離譜，

那，一個系統的性能好不好，回應時間（指系統對請求作出回應的時間，比如用戶打開首頁）就是最明顯的一個直觀上的指標，對于游戲來說，回應時間小于 100 毫秒還算不錯，回應時間在 1 秒左右勉強接受，如果回應時間達到 3 秒就沒法玩了，

2）吞吐量

吞吐量（Transaction Per Second）是指系統在單位時間內處理事務的數量，一個事務可能包含多次請求，它反映出系統承受的壓力，

需要注意的是，TPS 和 QPS 是不一樣的，后者指的是單位時間內請求的數量，當用戶的操作只包含一個請求介面時，TPS 和 QPS 沒有區別，

吞吐量可以細分為網路吞吐量和磁盤吞吐量，前者是指在某個時刻，在網路中的兩個節點之間，提供給網路應用的剩余帶寬， 即在沒有幀丟失的情況下，設備能夠接受的最大速率，后者是指單位時間內系統能處理的 I/O 請求數量，I/O 請求通常為讀或寫資料操作請求，關注的是隨機讀寫性能，

最后來簡單總結一下，性能調優非常重要，不僅用戶體驗好，系統穩定，更能體現出真正優秀的編碼水平，我相信所有的小伙伴都能寫出跑的通的代碼，但至于痛不痛快，就需要在性能方面有所研究了，

換句話說，如果你跳槽到一家公司，恰好解決了原有系統的性能瓶頸，那不得了啊，兄弟，你立馬就得到公司重用了！

加油吧，騷年！

PS：如果你想學習性能調優方面的知識，我推薦給你一些書單：

《代碼整潔之道》，從代碼層面進行優化，干凈的代碼，既在質量上較為可靠，也為后期維護、升級奠定了良好的基礎，

《碼出高效：Java 開發手冊》，對 Java 規約的來龍去脈進行了全面而徹底的內容梳理，深入淺出地將計算機基礎、面向物件思想、JVM 探源、資料結構與集合、并發與多執行緒、單元測驗等知識客觀、立體地呈現出來，教你從根上寫出高效的 Java 代碼，

《重構，改善既有代碼的設計》，重構，就是在不改變外部行為的前提下，有條不紊地改善代碼，

《Effective Java》，揭示了應該做什么，不應該做什么，從而寫出清晰、健壯和高效的代碼，

《Java 性能優化》、《MySQL 性能優化》、《Tomcat 性能優化》等等就是從實戰的角度，優化應用程式的性能，

PPS：推薦一個 GitHub 倉庫吧，里面有部分性能優化方面的電子書，需要的自取：

https://github.com/itwanger/JavaBooks

日常求個三連，謝謝你勤勞的手指，嘿嘿，