系統性能優化十大絕招

軟體設計開發某種意義上是“取”與“舍”的藝術。

關於性能方面，就像建築設計成抗震9度需要額外的成本一樣，高性能軟體系統也意味著更高的實現成本，有時候與其他質量屬性甚至會衝突，比如安全性、可擴展性、可觀測性等等。

大部分時候我們需要的是：在業務遇到瓶頸之前，利用常見的技術手段將系統優化到預期水平。

那麼，性能優化有哪些技術方向和手段呢？

性能優化通常是“時間”與“空間”的互換與取捨。

本篇分兩個部分，在上篇，講解六種通用的“時間”與“空間”互換取捨的手段：

在下篇，介紹四種進階性的內容，大多與提升並行能力有關：

索引的原理是拿額外的存儲空間換取查詢時間，增加了寫入數據的開銷，但使讀取數據的時間複雜度一般從O(n)降低到O(logn)甚至O(1)。

索引不僅在資料庫中廣泛使用，前後端的開發中也在不知不覺運用。

在數據集比較大時，不用索引就像從一本沒有目錄而且內容亂序的新華字典查一個字，得一頁一頁全翻一遍才能找到；

用索引之後，就像用拼音先在目錄中先找到要查到字在哪一頁，直接翻過去就行了。

書籍的目錄是典型的樹狀結構，那麼軟體世界常見的索引有哪些數據結構，分別在什麼場景使用呢？

資料庫主鍵之爭：自增長 vs UUID。主鍵是很多資料庫非常重要的索引，尤其是MySQL這樣的RDBMS會經常面臨這個難題：是用自增長的ID還是隨機的UUID做主鍵？

自增長ID的性能最高，但不好做分庫分表後的全局唯一ID，自增長的規律可能泄露業務信息；而UUID不具有可讀性且太占存儲空間。

爭執的結果就是找一個兼具二者的優點的折衷方案：

再回到資料庫中的索引，建索引要註意哪些點呢？

資料庫之外，在代碼中也能應用索引的思維，比如對於集合中大量數據的查找，使用Set、Map、Tree這樣的數據結構，其實也是在用哈希索引或樹狀索引，比直接遍歷列表或數組查找的性能高很多。

緩存優化性能的原理和索引一樣，是拿額外的存儲空間換取查詢時間。緩存無處不在，設想一下我們在瀏覽器打開這篇文章，會有多少層緩存呢？

這裡列舉的僅僅是一部分常見的緩存，就有多種多樣的形式：從廉價的磁碟到昂貴的CPU高速緩存，最終目的都是用來換取寶貴的時間。

既然緩存那麼好，那麼問題就來了：緩存是“銀彈”嗎？

不，Phil Karlton 曾說過：

電腦科學中只有兩件困難的事情：緩存失效和命名規範。

緩存的使用除了帶來額外的複雜度以外，還面臨如何處理緩存失效的問題。

除了通常意義上的緩存外，對象重用的池化技術，也可以看作是一種緩存的變體。

常見的諸如JVM，V8這類運行時的常量池、資料庫連接池、HTTP連接池、線程池、Golang的sync.Pool對象池等等。

在需要某個資源時從現有的池子里直接拿一個，稍作修改或直接用於另外的用途，池化重用也是性能優化常見手段。

說完了兩個“空間換時間”的，我們再看一個“時間換空間”的辦法——壓縮。

壓縮的原理消耗計算的時間，換一種更緊湊的編碼方式來表示數據。

為什麼要拿時間換空間？時間不是最寶貴的資源嗎？

舉一個視頻網站的例子，如果不對視頻做任何壓縮編碼，因為帶寬有限，巨大的數據量在網路傳輸的耗時會比編碼壓縮的耗時多得多。

對數據的壓縮雖然消耗了時間來換取更小的空間存儲，但更小的存儲空間會在另一個維度帶來更大的時間收益。

這個例子本質上是“操作系統內核與網路設備處理負擔 vs 壓縮解壓的CPU/GPU負擔”的權衡和取捨。

我們在代碼中通常用的是無損壓縮，比如下麵這些場景：

資訊理論告訴我們，無損壓縮的極限是信息熵。進一步減小體積只能以損失部分信息為代價，也就是有損壓縮。

那麼，有損壓縮有哪些應用呢？

除了有損/無損壓縮，但還有一個辦法，就是壓縮的極端——從根本上減少數據或徹底刪除。

能減少的就減少：

能刪除的就刪除：

畢竟有位叫做 Kelsey Hightower 的大佬曾經說過：

不寫代碼，是編寫安全可靠的應用程式的最佳方式。什麼都不寫；哪裡都不部署。

預取通常搭配緩存一起用，其原理是在緩存空間換時間基礎上更進一步，再加上一次“時間換時間”，也就是：用事先預取的耗時，換取第一次載入的時間。

當可以猜測出以後的某個時間很有可能會用到某種數據時，把數據預先取到需要用的地方，能大幅度提升用戶體驗或服務端響應速度。

是否用預取模式就像自助餐餐廳與廚師現做的區別，在自助餐餐廳可以直接拿做好的菜品，一般餐廳需要坐下來等菜品現做。

那麼，預取在哪些實際場景會用呢？

天上不會掉餡餅，預取也是有副作用的。

正如烤箱預熱需要消耗時間和額外的電費，在軟體代碼中做預取/預熱的副作用通常是啟動慢一些、占用一些閑時的計算資源、可能取到的不一定是後面需要的。

削峰填谷的原理也是“時間換時間”，谷時換峰時。

削峰填谷與預取是反過來的：預取是事先花時間做，削峰填谷是事後花時間做。就像三峽大壩可以抗住短期巨量洪水，事後雨停再慢慢開閘防水。軟體世界的“削峰填谷”是類似的，只是不是用三峽大壩實現，而是用消息隊列、非同步化等方式。

常見的有這幾類問題，我們分別來看每種對應的解決方案：

批量處理同樣可以看成“時間換時間”，其原理是減少了重覆的事情，是一種對執行流程的壓縮。以個別批量操作更長的耗時為代價，在整體上換取了更多的時間。

批量處理的應用也非常廣泛，我們還是從前端開始講：

批量處理如此好用，那麼問題來了，每一批放多大最合適呢？

這個問題其實沒有定論，有一些個人經驗可以分享。

總之，多大一批可以確保單批響應時間不太長的同時讓整體性能最高，是需要在實際情況下做基準測試的，不能一概而論。而批量處理的副作用在於：處理邏輯會更加複雜，尤其是一些涉及事務、併發的問題；需要用數組或隊列用來存放緩衝一批數據，消耗了額外的存儲空間。

前面我們總結了六種普適的性能優化方法，包括索引、壓縮、緩存、預取、削峰填谷、批量處理，簡單講解了每種技術手段的原理和實際應用。

在開啟最後一篇前，我們先需要搞清楚：

在程式運行期間，時間和空間都耗在哪裡了？

人眨一次眼大約100毫秒，而現代1核CPU在一眨眼的功夫就可以執行數億條指令。

現代的CPU已經非常厲害了，頻率已經達到了GHz級別，也就是每秒數十億個指令周期。

即使一些CPU指令需要多個時鐘周期，但由於有流水線機制的存在，平均下來大約每個時鐘周期能執行1條指令，比如一個3GHz頻率的CPU核心，每秒大概可以執行20億到40億左右的指令數量。

程式運行還需要RAM，也可能用到持久化存儲，網路等等。隨著新的技術和工藝的出現，這些硬體也越來越厲害，比如CPU高速緩存的提升、NVMe固態硬碟相對SATA盤讀寫速率和延遲的飛躍等等。這些硬體具體有多強呢？

有一個非常棒的網站“Latency Numbers Every Programmer Should Know”，可以直觀地查看從1990年到現在，高速緩存、記憶體、硬碟、網路時間開銷的具體數值。

下圖是2020年的截圖，的確是“每個開發者應該知道的數字”。

這裡有幾個非常關鍵的數據：

看到不同硬體之間數量級的差距，就很容易理解性能優化的一些技術手段了。

比如一次網路傳輸的時間，是主存訪問的5000倍，明白這點就不難理解寫for迴圈發HTTP請求，為什麼會被扣工資了。

放大到我們容易感知的時間範圍，來理解5000倍的差距：如果一次主存訪問是1天的話，一趟區域網數據傳輸就要13.7年。

如果要傳輸更多網路數據，每兩個網路幀之間還有固定的間隔（Interpacket Gap），在間隔期間傳輸Idle信號，數據鏈路層以此來區分兩個數據包，具體數值在鏈接Wiki中有，這裡截取幾個我們熟悉的網路來感受一下：

不過，單純看硬體的上限意義不大，從代碼到機器指令中間有許多層抽象，僅僅是在TCP連接上發一個位元組的數據包，從操作系統內核到網線，涉及到的基礎設施級別的軟硬體不計其數。到了應用層，單次操作耗時雖然沒有非常精確的數字，但經驗上的範圍也值得參考：

在電腦歷史上，非易失存儲技術的發展速度超過了摩爾定律。除了嵌入式設備、資料庫系統等等，現在大部分場景已經不太需要優化持久化存儲的空間占用了，這裡主要講的是另一個相對稀缺的存儲形式 —— RAM，或者說主存/記憶體。

以JVM為例，在堆裡面有很多我們創建的對象（Object）。

如果在32G以上記憶體的機器上，禁用了對象指針壓縮，對象指針會變成8位元組，包括Header中的Klass指針，這也就不難理解為什麼堆記憶體超過32G，JVM的性能直線下降了。

舉個例子，一個有8個int類型成員的對象，需要占用48個位元組（12+32+4），如果有十萬個這樣的Object，就需要占用4.58MB的記憶體了。這個數字似乎看起來不大，而實際上一個Java服務的堆記憶體裡面，各種各樣的對象占用的記憶體通常比這個數字多得多，大部分記憶體耗在char[]這類數組或集合型數據類型上。

舉個例子，一個有8個int類型成員的對象，需要占用48個位元組（12+32+4），如果有十萬個這樣的Object，就需要占用4.58MB的記憶體了。這個數字似乎看起來不大，而實際上一個Java服務的堆記憶體裡面，各種各樣的對象占用的記憶體通常比這個數字多得多，大部分記憶體耗在char[]這類數組或集合型數據類型上。

堆記憶體之外，又是另一個世界了。

從操作系統進程的角度去看，也有不少耗記憶體的大戶，不管什麼Runtime都逃不開這些空間開銷：每個線程需要分配MB級別的線程棧，運行的程式和數據會緩存下來，用到的輸入輸出設備需要緩衝區……

代碼“寫出來”的記憶體占用，僅僅是冰山之上的部分，真正的記憶體占用比“寫出來”的要更多，到處都存在空間利用率的問題。

比如，即使我們在Java代碼中只是寫了 response.getWriter().print(“OK”)，給瀏覽器返回2位元組，網路協議棧的層層封裝，協議頭部不斷增加的額外數據，讓最終返回給瀏覽器的位元組數遠超原始的2位元組，像IP協議的報頭部就至少有20個位元組，而數據鏈路層的一個乙太網幀頭部至少有18位元組。

如果傳輸的數據過大，各層協議還有最大傳輸單元MTU的限制，IPv4一個報文最大隻能有64K比特，超過此值需要分拆發送併在接收端組合，更多額外的報頭導致空間利用率降低（IPv6則提供了Jumbogram機制，最大單包4G比特，“浪費”就減少了）。

這部分的“浪費”有多大呢？下麵的鏈接有個表格，傳輸1460個位元組的載荷，經過有線到無線網路的轉換，至少再添120個位元組，**空間利用率<92.4%**。

這種現象非常普遍，使用抽象層級越高的技術平臺，平臺提供高級能力的同時，其底層實現的“信息密度”通常越低。

像Java的Object Header就是使用JVM的代價，而更進一步使用動態類型語言，要為靈活性付出空間的代價則更大。哈希表的自動擴容，強大的反射能力等等，背後也付出了空間的代價。

再比如，二進位數據交換協議通常比純文本協議更加節約空間。但多數廠家我們仍然用JSON、XML等純文本協議，用信息的冗餘來換取可讀性。即便是二進位的數據交互格式，也會存在信息冗餘，只能通過更好的協議和壓縮演算法，儘量去逼近壓縮的極限 —— 信息熵。

理解了時間和空間的消耗在哪後，還不能完全解釋軟體為何傾向於耗盡硬體資源。有一條定律可以解釋，正是它錘爆了摩爾定律。

它就是安迪-比爾定律。

安迪指的是Intel前CEO安迪·葛洛夫，比爾指的是比爾·蓋茨。

這句話的意思就是：軟體發展比硬體還快，總能吃得下硬體。

20年前，在最強的電腦也不見得可以玩賽車游戲；

10年前，個人電腦已經可以玩畫質還可以的3D賽車游戲了；

現在，自動駕駛+5G雲駕駛已經快成為現實。

在這背後，是無數的硬體技術飛躍，以及吃掉了這些硬體的各類軟體。

因此，即使現代的硬體水平已經強悍到如此境地，性能優化仍然是有必要的。

軟體日益複雜，抽象層級越來越高，就越需要底層基礎設施被充分優化。

對於大部分開發者而言，高層代碼逐步走向低代碼化、可視化，“一行代碼”能產生的影響也越來越大，寫出低效代碼則會吃掉更多的硬體資源。

本篇也是本系列最硬核的一篇，本人技術水平有限，可能存在疏漏或錯誤之處，望斧正。仍然選取了《火影忍者》的配圖和命名方式幫助理解：

（註：這些“中二”的首碼僅是用《火影》中的一些術語，形象地描述技術方案）

讓硬體資源都在處理真正有用的邏輯計算，而不是做無關的事情或空轉。

從晶體管到集成電路、驅動程式、操作系統、直到高級編程語言的層層抽象，每一層抽象帶來的更強的通用性、更高的開發效率，多是以損失運行效率為代價的。

但我們可以在用高級編程語言寫代碼的時候，在保障可讀性、可維護性基礎上用運行效率更高、更適合運行時環境的方式去寫，減少額外的性能損耗《Effective XXX》、《More Effective XXX》、《高性能XXX》這類書籍所傳遞的知識和思想。

落到技術細節，下麵用四個小節來說明如何減少“無用功”、避免空轉、榨乾硬體。

1）聚焦

減少系統調用與上下文切換，讓CPU聚焦。

可以看看兩個 stackoverflow 上的帖子：

大部分互聯網應用服務，耗時的部分不是計算，而是I/O。

減少I/O wait， 各司其職，專心乾I/O，專心乾計算，epoll批量撈任務，（refer: event driven）

利用DMA減少CPU負擔 - 零拷貝 NewI/O Redis SingleThread (even 6.0), Node.js

避免不必要的調度 - Context Switch

CPU親和性，讓CPU更加聚焦

2）蛻變

用更高效的數據結構、演算法、第三方組件，讓程式本身蛻變。

從邏輯短路、Map代替List遍歷、減少鎖範圍、這樣的編碼技巧，到應用FisherYates、Dijkstra這些經典演算法，註意每一行代碼細節，量變會發生質變。更何況某個演算法就足以讓系統性能產生一兩個數量級的提升。

3）適應

因地制宜，適應特定的運行環境

在瀏覽器中主要是優化方向是I/O、UI渲染引擎、JS執行引擎三個方面。

I/O越少越好，能用WebSocket的地方就不用Ajax，能用Ajax的地方就不要刷整個頁面；

UI渲染方面，減少重排和重繪，比如Vue、React等MVVM框架的虛擬DOM用額外的計算換取最精簡的DOM操作；

JS執行引擎方面，少用動態性極高的寫法，比如eval、隨意修改對象或對象原型的屬性。

前端的優化有個神器：Light House，在新版本Chrome已經嵌到開發者工具中了，可以一鍵生成性能優化報告，按照優化建議改就完了。

與瀏覽器環境頗為相似的Node.js環境：

Java

Linux

利用語言特性和運行時環境 - 比如寫出利於JIT的代碼

減少記憶體的分配和回收，少對列表做增加或刪除

對於RAM有限的嵌入式環境，有時候時間不是問題，反而要拿時間換空間，以節約RAM的使用。

4）運籌

把眼界放寬，跳出程式和運行環境本身，從整體上進行系統性分析最高性價比的優化方案，分析潛在的優化切入點，以及能夠調配的資源和技術，運籌帷幄。

其中最簡單易行的幾個辦法，就是花錢，買更好或更多的硬體基礎設施，這往往是開發人員容易忽視的，這裡提供一些妙招：

第一點非常重要，軟體性能遵循木桶原理，一定要找到瓶頸在哪個硬體資源，把錢花在刀刃上。

如果是服務端帶寬瓶頸導致的性能問題，升級再多核CPU也是沒有用的。

我有一次性能優化案例：把一個跑複雜業務的Node.js伺服器從AWS的m4類型換成c4類型，記憶體只有原來的一半，但CPU使用率反而下降了20%，同時價格還比之前更便宜，一石二鳥。

這是因為Node.js主線程的計算任務只有一個CPU核心在乾，通過CPU Profile的火焰圖，可以定位到該業務的瓶頸在主線程的計算任務上，因此提高單核頻率的作用是立竿見影的。而該業務對記憶體的消耗並不多，套用一些定製v8引擎記憶體參數的方案，起不了任何作用。

畢竟這樣的例子不多，大部分時候還是要多花錢買更高配的伺服器的，除了這條花錢能直接解決問題的辦法，剩下的辦法難度就大了：

5）小結

有些手段，是憑空換出來更多的空間和時間了嗎？

天下沒有免費的午餐，即使那些看起來空手套白狼的優化技術，也需要額外的人力成本來做，副作用可能就是專家級的髮際線吧。還好很多複雜的性能優化技術我也不會，所以我本人髮際線還可以。

這一小節總結了一些方向，有些技術細節非常深，這裡也無力展開。不過，即使榨幹了單機性能，也可能不足以支撐業務，這時候就需要分散式集群出場了，因此後面介紹的3個技術方向，都與並行化有關。

本節的水平擴容以及下麵一節的分片，可以算整體的性能提升而不是單點的性能優化，會因為引入額外組件反而降低了處理單個請求的性能。

但當業務規模大到一定程度時，再好的單機硬體也無法承受流量的洪峰，就得水平擴容了，畢竟”眾人拾柴火焰高”。

在這背後的理論基礎是，硅基半導體已經接近物理極限，隨著摩爾定律的減弱，阿姆達爾定律的作用顯現出來：

水平擴容必然引入負載均衡

水平擴容針對無狀態組件，分片針對有狀態組件。二者原理都是提升並行度，但分片的難度更大。

負載均衡也不再是簡單的加權輪詢了，而是進化成了各個分片的協調器

有些業務場景，比如庫存業務，按照正常的邏輯去實現，水平擴容帶來的提升非常有限，因為需要鎖住庫存，扣減，再解鎖庫存。

票務系統也類似，為了避免超賣，需要有一把鎖禁錮了橫向擴展的能力。

不管是單機還是分散式微服務，鎖都是制約並行度的一大因素。比如上篇提到的秒殺場景，庫存就那麼多，系統超賣了可能導致非常大的經濟損失，但用分散式鎖會導致即使服務擴容了成千上萬個實例，最終無數請求仍然阻塞在分散式鎖這個串列組件上了，再多水平擴展的實例也無用武之地。

避免競爭Race Condition 是最完美的解決辦法。

上篇說的應對秒殺場景，預取庫存就是減輕競態條件的例子，雖然取到伺服器記憶體之後仍然有多線程的鎖，但鎖的粒度更細了，併發度也就提高了。

以ROI的視角看軟體開發，初期人力成本的投入，後期的維護成本，計算資源的費用等等，選一個合適的方案而不是一個性能最高的方案。

本篇結合個人經驗總結了常見的性能優化手段，這些手段只是冰山一角。在初期就設計實現出一個完美的高性能系統是不可能的，隨著軟體的迭代和體量的增大，利用壓測，各種工具（profiling，vmstat，iostat，netstat），以及監控手段，逐步找到系統的瓶頸，因地制宜地選擇優化手段才是正道。

有利必有弊，得到一些必然會失去一些，有一些手段要慎用。Linux性能優化大師Brendan Gregg一再強調的就是：切忌過早優化、過度優化。

持續觀測，做80%高投入產出比的優化。

除了這些設計和實現時可能用到的手段，在技術選型時選擇高性能的框架和組件也非常重要。

另外，部署基礎設施的硬體性能也同樣，合適的伺服器和網路等基礎設施往往會事半功倍，比如雲服務廠商提供的各種字母開頭的instance，網路設備帶寬的速度和穩定性，磁碟的I/O能力等等。

多數時候我們應當使用更高性能的方案，但有時候甚至要故意去違背它們。最後，以《Effective Java》第一章的一句話結束本文吧。

本文來自博客園，作者：古道輕風，轉載請註明原文鏈接：https://www.cnblogs.com/88223100/p/Top-Ten-Ways-to-Optimize-System-Performance.html