初衷：

隨著互聯網的發展，高可靠、高并發以及降本增效，已成為各大公司面臨的現實挑戰，性能優化需求愈發迫切，大到分布式系統，小到代碼塊的算法優化，都已經成為你日常工作中必須要面對的事情。對于開發者而言，性能優化也從加分項變為一個熱門技能，缺乏相關知識將很難在面試或工作中脫穎而出。

該篇主要從理論分析入手來介紹性能優化的衡量指標，及其理論方法和注意點。

指標是我們衡量很多事物，以及做出行為決策的重要參考。例如在生活中，當你打算買汽車時，會關注很多指標，比如動力性、燃油經濟性、制動性、操縱穩定性、平順性、通過性、排放與噪聲等，而這些指標也都有相關的測試和參數，同時也會對這些指標進行一一參考。

這個道理大家都懂，但一旦到了性能優化上，卻往往因為缺乏理論依據而選擇了錯誤的優化方向，陷入了盲猜的窘境。在衡量一項優化是否能達到目的之時，不能僅靠感覺，它同樣有一系列的指標來衡量你的改進。如果在改動之后，性能不升反降，那就不能叫性能優化了。

所謂性能，就是使用有限的資源在有限的時間內完成工作。最主要的衡量因素就是時間，所以很多衡量指標，都可以把時間作為橫軸。

加載緩慢的網站，會受到搜索排名算法的懲罰，從而導致網站排名下降。 因此加載的快慢是性能優化是否合理的一個非常直觀的判斷因素，但性能指標不僅僅包括單次請求的速度，它還包含更多因素。

接下來看一下，都有哪些衡量指標能夠幫我們進行決策。

衡量指標有哪些？

1. 吞吐量和響應速度

分布式的高并發應用并不能把單次請求作為判斷依據，它往往是一個統計結果。其中最常用的衡量指標就是吞吐量和響應速度，而這兩者也是考慮性能時非常重要的概念。要理解這兩個指標的意義，我們可以類比為交通環境中的十字路口。

在交通非常繁忙的情況下，十字路口是典型的瓶頸點，當紅綠燈放行時間非常長時，后面往往會排起長隊。

從我們開車開始排隊，到車經過紅綠燈，這個過程所花費的時間，就是響應時間。

當然，我們可以適當地調低紅綠燈的間隔時間，這樣對于某些車輛來說，通過時間可能會短一些。但是，如果信號燈頻繁切換，反而會導致單位時間內通過的車輛減少，換一個角度，我們也可以認為這個十字路口的車輛吞吐量減少了。

像我們平常開發中經常提到的，QPS 代表每秒查詢的數量，TPS 代表每秒事務的數量，HPS 代表每秒的 HTTP 請求數量等，這都是常用的與吞吐量相關的量化指標。

在性能優化的時候，我們要搞清楚優化的目標，到底是吞吐量還是響應速度。 有些時候，雖然響應速度比較慢，但整個吞吐量卻非常高，比如一些數據庫的批量操作、一些緩沖區的合并等。雖然信息的延遲增加了，但如果我們的目標就是吞吐量，那么這顯然也可以算是比較大的性能提升。

一般情況下，我們認為：

• 響應速度是串行執行的優化，通過優化執行步驟解決問題；
• 吞吐量是并行執行的優化，通過合理利用計算資源達到目標。

我們平常的優化主要側重于響應速度，因為一旦響應速度提升了，那么整個吞吐量自然也會跟著提升。

但對于高并發的互聯網應用來說，響應速度和吞吐量兩者都需要。這些應用都會標榜為高吞吐、高并發的場景，用戶對系統的延遲忍耐度很差，我們需要使用有限的硬件資源，從中找到一個平衡點。

2. 響應時間衡量

既然響應時間這么重要，我們就著重看一下響應時間的衡量方法。

（1）平均響應時間

我們最常用的指標，即平均響應時間(AVG)，該指標能夠體現服務接口的平均處理能力。它的本質是把所有的請求耗時加起來，然后除以請求的次數。舉個最簡單的例子，有 10 個請求，其中有 2 個 1ms、3 個 5ms、5 個 10ms，那么它的平均耗時就是(21+35+5*10)/10=6.7ms。

除非服務在一段時間內出現了嚴重的問題，否則平均響應時間都會比較平緩。因為高并發應用請求量都特別大，所以長尾請求的影響會被很快平均，導致很多用戶的請求變慢，但這不能體現在平均耗時指標中。

為了解決這個問題，另外一個比較常用的指標，就是百分位數(Percentile)。

（2）百分位數

這個也比較好理解。我們圈定一個時間范圍，把每次請求的耗時加入一個列表中，然后按照從小到大的順序將這些時間進行排序。這樣，我們取出特定百分位的耗時，這個數字就是 TP 值。可以看到，TP 值(Top Percentile)和中位數、平均數等是類似的，都是一個統計學里的術語。

它的意義是，超過 N% 的請求都在 X 時間內返回。比如 TP90 = 50ms，意思是超過 90th 的請求，都在 50ms 內返回。

這個指標也是非常重要的，它能夠反映出應用接口的整體響應情況。比如，某段時間若發生了長時間的 GC，那它的某個時間段之上的指標就會產生嚴重的抖動，但一些低百分位的數值卻很少有變化。

我們一般分為 TP50、TP90、TP95、TP99、TP99.9 等多個段，對高百分位的值要求越高，對系統響應能力的穩定性要求越高。

在這些高穩定性系統中，目標就是要干掉嚴重影響系統的長尾請求。這部分接口性能數據的收集，我們會采用更加詳細的日志記錄方式，而不僅僅靠指標。比如，我們將某個接口，耗時超過 1s 的入參及執行步驟，詳細地輸出在日志系統中。

3. 并發量

并發量是指系統同時能處理的請求數量，這個指標反映了系統的負載能力。

在高并發應用中，僅僅高吞吐是不夠的，它還必須同時能為多個用戶提供服務。并發高時，會導致很嚴重的共享資源爭用問題，我們需要減少資源沖突，以及長時間占用資源的行為。

針對響應時間進行設計，一般來說是萬能的。因為響應時間減少，同一時間能夠處理的請求必然會增加。值得注意的是，即使是一個秒殺系統，經過層層過濾處理，最終到達某個節點的并發數，大概也就五六十左右。我們在平常的設計中，除非并發量特別低，否則都不需要太過度關注這個指標。

4. 秒開率

在移動互聯網時代，尤其對于 App 中的頁面，秒開是一種極佳的用戶體驗。如果能在 1 秒內加載完成頁面，那用戶可以獲得流暢的體驗，并且不會產生更多的焦慮感。

通常而言，可以根據業務情況設定不同的頁面打開標準，比如低于 1 秒內的數據占比是秒開率。業界優秀的公司，比如手淘，其頁面的秒開率基本可達到 80% 以上。

5. 正確性

說一個比較有意思的事情。我們有個技術團隊，在進行測試的時候，發現接口響應非常流暢，把并發數增加到 20 以后，應用接口響應依舊非常迅速。

但等應用真正上線時，卻發生了重大事故，這是因為接口返回的都是無法使用的數據。

其問題原因也比較好定位，就是項目中使用了熔斷。在壓測的時候，接口直接超出服務能力，觸發熔斷了，但是壓測并沒有對接口響應的正確性做判斷，造成了非常低級的錯誤。

所以在進行性能評估的時候，不要忘記正確性這一關鍵要素。

有哪些理論方法？

性能優化有很多理論方法，比如木桶理論、基礎測試、Amdahl 定律等。下面我們簡單地講解一下最常用的兩個理論。

1. 木桶理論

一只木桶若想要裝最多的水，則需要每塊木板都一樣長而且沒有破損才行。如果有一塊木板不滿足條件，那么這只桶就無法裝最多的水。

能夠裝多少水，取決于最短的那塊木板，而不是最長的那一塊。

木桶效應在解釋系統性能上，也非常適合。組成系統的組件，在速度上是良莠不齊的。系統的整體性能，就取決于系統中最慢的組件。

比如，在數據庫應用中，制約性能最嚴重的是落盤的 I/O 問題，也就是說，硬盤是這個場景下的短板，我們首要的任務就是補齊這個短板。

2. 基準測試、預熱

基準測試(Benchmark)并不是簡單的性能測試，是用來測試某個程序的最佳性能。

應用接口往往在剛啟動后都有短暫的超時。在測試之前，我們需要對應用進行預熱，消除 JIT 編譯器等因素的影響。而在 Java 里就有一個組件，即 JMH，就可以消除這些差異。

注意點

1. 依據數字而不是猜想

有些同學對編程有很好的感覺，能夠靠猜測列出系統的瓶頸點，這種情況固然存在，但卻非常不可取。復雜的系統往往有多個影響因素，我們應將性能分析放在第一位，把性能優化放在次要位置，直覺只是我們的輔助，但不能作為下結論的工具。

進行性能優化時，我們一般會把分析后的結果排一個優先級（根據難度和影響程度），從大處著手，首先擊破影響最大的點，然后將其他影響因素逐一擊破。

有些優化會引入新的性能問題，有時候這些新問題會引起更嚴重的性能下降，你需要評估這個連鎖反應，確保這種優化確實需要，同時需要使用數字去衡量這個過程，而不是靠感覺猜想。

2. 個體數據不足信

你是否有這樣的經歷：某個知名網站的訪問速度真慢，光加載就花費了 x 秒。其實，僅憑一個人的一次請求，就下了“慢”這個結論，是不合適的，而在我們進行性能評估的時候，也往往會陷入這樣的誤區。

這是因為個體請求的小批量數據，可參考價值并不是非常大。響應時間可能因用戶的數據而異，也可能取決于設備和網絡條件。

合理的做法，是從統計數據中找到一些規律，比如上面所提到的平均響應時間、TP 值等，甚至是響應時間分布的直方圖，這些都能夠幫我們評估性能質量。

3. 不要過早優化和過度優化

雖然性能優化有這么多好處，但并不代表我們要把每個地方都做到極致，性能優化也是要有限度的。程序要運行地正確，要比程序運行得更快還要困難。

計算機科學的鼻祖"Donald Knuth" 曾說：“過早的優化是萬惡之源”，就是這個道理。

如果一項改進并不能產生明顯的價值，那我們為什么還要花大力氣耗在上面呢？比如，某個應用已經滿足了用戶的吞吐量需求和響應需求，但有的同學熱衷于 JVM 的調優，依然花很大力氣在參數測試上，這種優化就屬于過度優化。

時間要花在刀刃上，我們需要找到最迫切需要解決的性能點，然后將其擊破。比如，一個系統主要是慢在了數據庫查詢上，結果你卻花了很大的精力去優化 Java 編碼規范，這就是偏離目標的典型情況。

一般地，性能優化后的代碼，由于太過于追求執行速度，讀起來都比較晦澀，在結構上也會有很多讓步。很顯然，過早優化會讓這種難以維護的特性過早介入到你的項目中，等代碼重構的時候，就會花更大的力氣去解決它。

正確的做法是，項目開發和性能優化，應該作為兩個獨立的步驟進行，要做性能優化，要等到整個項目的架構和功能大體進入穩定狀態時再進行。

4. 保持良好的編碼習慣

我們上面提到，不要過早地優化和過度優化，但并不代表大家在編碼時就不考慮這些問題。

比如，保持好的編碼規范，就可以非常方便地進行代碼重構；使用合適的設計模式，合理的劃分模塊，就可以針對性能問題和結構問題進行聚焦、優化。

在追求高性能、高質量編碼的過程中，一些好的習慣都會積累下來，形成人生道路上優秀的修養和品質，這對我們是大有裨益的。

小結

我們簡單地了解了衡量性能的一些指標，比如常見的吞吐量和響應速度，還探討了一些其他的影響因素，比如并發量、秒開率、容錯率等。

同時，我們也談到了木桶理論和基準測試等兩種過程方法，并對性能測試中的一些誤區和注意點進行了介紹，現在你應該對如何描述性能有了更好的理解。像一些專業的性能測試軟件，如 JMeter、LoadRunner 等，就是在這些基礎性能指標上進行的擴展。我們在平常的工作中，也應該盡量使用專業術語，這樣才能對系統性能進行正確評估。

了解了優化指標后，有了行動導向，那接下來該從哪些方面入手呢？ Java 性能優化是否有可以遵循的規律呢？