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

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

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

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

1、復用優化

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

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

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

緩沖（Buffer），常見于對數據的暫存，然后批量傳輸或者寫入。多使用順序方式，用來緩解不同設備之間頻繁地、緩慢地隨機寫，緩沖主要針對的是寫操作。

緩存（Cache），常見于對已讀取數據的復用，通過將它們緩存在相對高速的區域，緩存主要針對的是讀操作。

與之類似的，是對于對象的池化操作，比如數據庫連接池、線程池等，在 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大方向是代碼優化的最主要方向，當然，性能優化還包含數據庫優化、操作系統優化、架構優化等其他一些內容，這些不是我們的重點，在后面的文章中，我們也只做簡要的介紹。