阿裡巴巴java性能調優實戰：如何制定性能調優标準？

如何制定性能調優标準？

我有一個朋友，有一次他跟我說，他們公司的系統從來沒有經過性能調優，功能測試完成後就上線了，線上也沒有出現過什麼性能問題呀，那為什麼很多系統都要去做性能調優呢？當時我就回答了他一句，如果你們公司做的是 12306 網站，不做系統性能優化就上線，試試看會是什麼情況。

如果是你，你會怎麼回答呢？今天，我們就從這個話題聊起，希望能跟你一起弄明白這幾個問題。

1.我們為什麼要做性能調優？

2.什麼時候開始做？

3.做性能調優是不是有标準可參考？

為什麼要做性能調優？

一款線上産品如果沒有經過性能測試，那它就好比是一顆定時炸彈，你不知道它什麼時候會出現問題，你也不清楚它能承受的極限在哪兒。

有些性能問題是時間累積慢慢産生的，到了一定時間自然就爆炸了；

而更多的性能問題是由通路量的波動導緻的，例如，活動或者公司産品使用者量上升；當然也有可能是一款産品上線後就半死不活，一直沒有大通路量，是以還沒有引發這顆定時炸彈。

現在假設你的系統要做一次活動，産品經理或者老闆告訴你預計有幾十萬的使用者通路量，詢問系統能否承受得住這次活動的壓力。

如果你不清楚自己系統的性能情況，也隻能戰戰兢兢地回答老闆，有可能大概沒問題吧。是以，要不要做性能調優，這個問題其實很好回答。所有的系統在開發完之後，多多少少都會有性能問題，我們首先要做的就是想辦法把問題暴露出來，例如進行壓力測試、模拟可能的操作場景等等，再通過性能調優去解決這些問題。比如，當你在用某一款 App 查詢某一條資訊時，需要等待十幾秒鐘；在搶購活動中，無法進入活動頁面等等。你看，系統響應就是展現系統性能最直接的一個參考因素。那如果系統線上上沒有出現響應問題，我們是不是就不用去做性能優化了呢？

再給你講一個故事吧。曾經我的前前東家系統研發部門來了一位大神，為什麼叫他大神，因為在他來公司的一年時間裡，他隻做了一件事情，就是把伺服器的數量縮減到了原來的一半，系統的性能名額，反而還提升了。好的系統性能調優不僅僅可以提高系統的性能，還能為公司節省資源。這也是我們做性能調優的最直接的目的。

什麼時候開始介入調優？

解決了為什麼要做性能優化的問題，那麼新的問題就來了：如果需要對系統做一次全面的性能監測和優化，我們從什麼時候開始介入性能調優呢？是不是越早介入越好？

其實，在項目開發的初期，我們沒有必要過于在意性能優化，這樣反而會讓我們疲于性能優化，不僅不會給系統性能帶來提升，還會影響到開發進度，甚至獲得相反的效果，給系統帶來新的問題。

我們隻需要在代碼層面保證有效的編碼，比如，減少磁盤 I/O 操作、降低競争鎖的使用以及使用高效的算法等等。遇到比較複雜的業務，我們可以充分利用設計模式來優化業務代碼。

例如，設計商品價格的時候，往往會有很多折扣活動、紅包活動，我們可以用裝飾模式去設計這個業務。

在系統編碼完成之後，我們就可以對系統進行性能測試了。這時候，産品經理一般會提供線上預期資料，我們在提供的參考平台上進行壓測，通過性能分析、統計工具來統計各項性能名額，看是否在預期範圍之内。

在項目成功上線後，我們還需要根據線上的實際情況，依照日志監控以及性能統計日志，來觀測系統性能問題，一旦發現問題，就要對日志進行分析并及時修複問題。

有哪些參考因素可以展現系統的性能？

上面我們講到了在項目研發的各個階段性能調優是如何介入的，其中多次講到了性能名額，那麼性能名額到底有哪些呢？

在我們了解性能名額之前，我們先來了解下哪些計算機資源會成為系統的性能瓶頸。

CPU：有的應用需要大量計算，他們會長時間、不間斷地占用 CPU 資源，導緻其他資源無法争奪到 CPU 而響應緩慢，進而帶來系統性能問題。例如，代碼遞歸導緻的無限循環，正則表達式引起的回溯，JVM 頻繁的 FULL GC，以及多線程程式設計造成的大量上下文切換等，這些都有可能導緻 CPU 資源繁忙。

記憶體：Java 程式一般通過 JVM 對記憶體進行配置設定管理，主要是用 JVM 中的堆記憶體來存儲 Java 建立的對象。系統堆記憶體的讀寫速度非常快，是以基本不存在讀寫性能瓶頸。但是由于記憶體成本要比磁盤高，相比磁盤，記憶體的存儲空間又非常有限。是以當記憶體空間被占滿，對象無法回收時，就會導緻記憶體溢出、記憶體洩露等問題。

磁盤 I/O：磁盤相比記憶體來說，存儲空間要大很多，但磁盤 I/O 讀寫的速度要比記憶體慢，雖然目前引入的 SSD 固态硬碟已經有所優化，但仍然無法與記憶體的讀寫速度相提并論。

網絡：網絡對于系統性能來說，也起着至關重要的作用。如果你購買過雲服務，一定經曆過，選擇網絡帶寬大小這一環節。帶寬過低的話，對于傳輸資料比較大，或者是并發量比較大的系統，網絡就很容易成為性能瓶頸。

異常：Java 應用中，抛出異常需要建構異常棧，對異常進行捕獲和處理，這個過程非常消耗系統性能。如果在高并發的情況下引發異常，持續地進行異常處理，那麼系統的性能就會明顯地受到影響。

資料庫：大部分系統都會用到資料庫，而資料庫的操作往往是涉及到磁盤 I/O 的讀寫。大量的資料庫讀寫操作，會導緻磁盤 I/O 性能瓶頸，進而導緻資料庫操作的延遲性。對于有大量資料庫讀寫操作的系統來說，資料庫的性能優化是整個系統的核心。

鎖競争：在并發程式設計中，我們經常會需要多個線程，共享讀寫操作同一個資源，這個時候為了保持資料的原子性（即保證這個共享資源在一個線程寫的時候，不被另一個線程修改），我們就會用到鎖。鎖的使用可能會帶來上下文切換，進而給系統帶來性能開銷。JDK1.6 之後，Java 為了降低鎖競争帶來的上下文切換，對 JVM 内部鎖已經做了多次優化，例如，新增了偏向鎖、自旋鎖、輕量級鎖、鎖粗化、鎖消除等。而如何合理地使用鎖資源，優化鎖資源，就需要你了解更多的作業系統知識、Java 多線程程式設計基礎，積累項目經驗，并結合實際場景去處理相關問題。了解了上面這些基本内容，我們可以得到下面幾個名額，來衡量一般系統的性能。