Java 性能優化的七個方向

瞭解了優化目標後，那接下來應該從哪些方面入手呢？本文主要側重於理論分析，我們從整體上看一下 Java 性能優化都有哪些可以遵循的規律。本文主講理論。關於實踐，後續的文章會用較多的案例來細化本文的知識點，適合反覆思考和歸納。

概述

性能優化根據優化的類別，分爲業務優化和技術優化。業務優化產生的效果也是非常大的，但它屬於產品和管理的範疇。同作爲程序員，在平常工作中，我們面對的優化方式，主要是通過一系列的技術手段，來完成對既定的優化目標。這一系列的技術手段，我大體歸納爲如圖以下 7 類：

可以看到，優化方式集中在對計算資源和存儲資源的規劃上。優化方法中有多種用空間換時間的方式，但只照顧計算速度，而不考慮複雜性和空間問題，也是不可取的。我們要做的，就是在照顧性能的前提下，達到資源利用的最優狀態。

接下來，我簡要介紹一下這 7 個優化方向。如果你感覺比較枯燥，那也沒關係，我們本文的目的，就是讓你的腦海裏有一個總分的概念，以及對理論基礎有一個整體的認識。

1、複用優化

在寫代碼的時候，你會發現有很多重複的代碼可以提取出來，做成公共的方法。這樣，在下次用的時候，就不用再費勁寫一遍了。

這種思想就是複用。上面的描述是編碼邏輯上的優化，對於數據存取來說，有同樣的複用情況。無論是在生活中還是編碼中，重複的事情一直在發生，如果沒有複用，工作和生活就會比較累。

在軟件系統中，談到數據複用，我們首先想到的就是緩衝和緩存。注意這兩個詞的區別，它們的意義是完全不同的，很多同學很容易搞混，在這裏簡單地介紹一下。

與之類似的，是對於對象的池化操作，比如數據庫連接池、線程池等，在 Java 中使用得非常頻繁。由於這些對象的創建和銷燬成本都比較大，我們在使用之後，也會將這部分對象暫時存儲，下次用的時候，就不用再走一遍耗時的初始化操作了。

2、 計算優化

並行執行

現在的 CPU 發展速度很快，絕大多數硬件，都是多核。要想加快某個任務的執行，最快最優的解決方式，就是讓它並行執行。並行執行有以下三種模式。

第一種模式是多機，採用負載均衡的方式，將流量或者大的計算拆分成多個部分，同時進行處理。比如，Hadoop 通過 MapReduce 的方式，把任務打散，多機同時進行計算。

第二種模式是採用多進程。比如 Nginx，採用 NIO 編程模型，Master 統一管理 Worker 進程，然後由 Worker 進程進行真正的請求代理，這也能很好地利用硬件的多個 CPU。

第三種模式是使用多線程，這也是 Java 程序員接觸最多的。比如 Netty，採用 Reactor 編程模型，同樣使用 NIO，但它是基於線程的。Boss 線程用來接收請求，然後調度給相應的 Worker 線程進行真正的業務計算。

像 Golang 這樣的語言，有更加輕量級的協程（Coroutine），協程是一種比線程更加輕量級的存在，但目前在 Java 中還不太成熟，就不做過多介紹了，但本質上，它也是對於多核的應用，使得任務並行執行。

變同步爲異步

再一種對於計算的優化，就是變同步爲異步，這通常涉及編程模型的改變。同步方式，請求會一直阻塞，直到有成功，或者失敗結果的返回。雖然它的編程模型簡單，但應對突發的、時間段傾斜的流量，問題就特別大，請求很容易失敗。

異步操作可以方便地支持橫向擴容，也可以緩解瞬時壓力，使請求變得平滑。同步請求，就像拳頭打在鋼板上；異步請求，就像拳頭打在海綿上。你可以想象一下這個過程，後者肯定是富有彈性的，體驗更加友好。

惰性加載

最後一種，就是使用一些常見的設計模式來優化業務，提高體驗，比如單例模式、代理模式等。舉個例子，在繪製 Swing 窗口的時候，如果要顯示比較多的圖片，就可以先加載一個佔位符，然後通過後臺線程慢慢加載所需要的資源，這就可以避免窗口的僵死。

3、結果集優化

接下來介紹一下對結果集的優化。舉個比較直觀的例子，我們都知道 XML 的表現形式是非常好的，那爲什麼還有 JSON 呢？除了書寫要簡單一些，一個重要的原因就是它的體積變小了，傳輸效率和解析效率變高了，像 Google 的 Protobuf，體積就更小了一些。雖然可讀性降低，但在一些高併發場景下（如 RPC），能夠顯著提高效率，這是典型的對結果集的優化。

這是由於我們目前的 Web 服務，都是 C/S 模式。數據從服務器傳輸到客戶端，需要分發多份，這個數據量是急劇膨脹的，每減少一小部分存儲，都會有比較大的傳輸性能和成本提升。

像 Nginx，一般都會開啓 GZIP 壓縮，使得傳輸的內容保持緊湊。客戶端只需要一小部分計算能力，就可以方便解壓。由於這個操作是分散的，所以性能損失是固定的。

瞭解了這個道理，我們就能看到對於結果集優化的一般思路，你要儘量保持返回數據的精簡。一些客戶端不需要的字段，那就在代碼中，或者直接在 SQL 查詢中，就把它去掉。

對於一些對時效性要求不高，但對處理能力有高要求的業務。我們要吸取緩衝區的經驗，儘量減少網絡連接的交互，採用批量處理的方式，增加處理速度。

結果集合很可能會有二次使用，你可能會把它加入緩存中，但依然在速度上有所欠缺。這個時候，就需要對數據集合進行處理優化，採用索引或者 Bitmap 位圖等方式，加快數據訪問速度。

4、資源衝突優化

我們在平常的開發中，會涉及很多共享資源。這些共享資源，有的是單機的，比如一個 HashMap；有的是外部存儲，比如一個數據庫行；有的是單個資源，比如 Redis 某個 key 的 Setnx；有的是多個資源的協調，比如事務、分佈式事務等。

現實中的性能問題，和鎖相關的問題是非常多的。大多數我們會想到數據庫的行鎖、表鎖、Java 中的各種鎖等。在更底層，比如 CPU 命令級別的鎖、JVM 指令級別的鎖、操作系統內部鎖等，可以說無處不在。

只有併發，才能產生資源衝突。也就是在同一時刻，只能有一個處理請求能夠獲取到共享資源。解決資源衝突的方式，就是加鎖。再比如事務，在本質上也是一種鎖。

按照鎖級別，鎖可分爲樂觀鎖和悲觀鎖，樂觀鎖在效率上肯定是更高一些；按照鎖類型，鎖又分爲公平鎖和非公平鎖，在對任務的調度上，有一些細微的差別。

對資源的爭用，會造成嚴重的性能問題，所以會有一些針對無鎖隊列之類的研究，對性能的提升也是巨大的。

5、算法優化

算法能夠顯著提高複雜業務的性能，但在實際的業務中，往往都是變種。由於存儲越來越便宜，在一些 CPU 非常緊張的業務中，往往採用空間換取時間的方式，來加快處理速度。

算法屬於代碼調優，代碼調優涉及很多編碼技巧，需要使用者對所使用語言的 API 也非常熟悉。有時候，對算法、數據結構的靈活使用，也是代碼優化的一個重要內容。比如，常用的降低時間複雜度的方式，就有遞歸、二分、排序、動態規劃等。

一個優秀的實現，比一個拙劣的實現，對系統的影響是非常大的。比如，作爲 List 的實現，LinkedList 和 ArrayList 在隨機訪問的性能上，差了好幾個數量級；又比如，CopyOnWriteList 採用寫時複製的方式，可以顯著降低讀多寫少場景下的鎖衝突。而什麼時候使用同步，什麼時候是線程安全的，也對我們的編碼能力有較高的要求。

這部分的知識，就需要我們在平常的工作中注意積累，後面的課時中，也會挑比較重要的知識點穿插講解。

6、高效實現

在平時的編程中，儘量使用一些設計理念良好、性能優越的組件。比如，有了 Netty，就不用再選擇比較老的 Mina 組件。而在設計系統時，從性能因素考慮，就不要選 SOAP 這樣比較耗時的協議。再比如，一個好的語法分析器（比如使用 JavaCC），其效率會比正則表達式高很多。

總之，如果通過測試分析，找到了系統的瓶頸點，就要把關鍵的組件，使用更加高效的組件進行替換。在這種情況下，適配器模式是非常重要的。這也是爲什麼很多公司喜歡在現有的組件之上，再抽象一層自己的；而當在底層組件進行切換的時候，上層的應用並無感知。

7、JVM 優化

因爲 Java 是運行在 JVM 虛擬機之上，它的諸多特性，就要受到 JVM 的制約。對 JVM 虛擬機進行優化，也能在一定程度上能夠提升 JAVA 程序的性能。如果參數配置不當，甚至會造成 OOM 等比較嚴重的後果。

目前被廣泛使用的垃圾回收器是 G1，通過很少的參數配置，內存即可高效回收。CMS 垃圾回收器已經在 Java 14 中被移除，由於它的 GC 時間不可控，有條件應該儘量避免使用。

JVM 性能調優涉及方方面面的取捨，往往是牽一髮而動全身，需要全盤考慮各方面的影響。所以瞭解 JVM 內部的一些運行原理，還是特別重要的，它有益於我們加深對代碼更深層次的理解，幫助我們書寫出更高效的代碼。

小結

以上就是代碼優化的 7 個大方向，我們通過簡要的介紹，讓大家對性能優化的內容有了大體的瞭解。這 7 大方向是代碼優化的最主要方向，當然，性能優化還包含數據庫優化、操作系統優化、架構優化等其他一些內容，這些不是我們的重點，在後面的文章中，我們也只做簡要的介紹。

作者：農民工老王

來源：tomcat.blog.csdn.net/article/details/123361799

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/0tBxP-6ONlUxrSaE_zDjog

猜你喜歡