10種簡單的Java效能優化

你是否正打算優化hashCode()方法？是否想要繞開正規表示式？Lukas Eder介紹了很多簡單方便的效能優化小貼士以及擴充套件程式效能的技巧。

最近“全網域（Web Scale）”一詞被炒得火熱，人們也正在通過擴充套件他們的應用程式架構來使他們的系統變得更加“全網域”。但是究竟什麼是全網域？或者說如何確保全網域？

擴充套件的不同方面

全網域被炒作的最多的是擴充套件負載（Scaling load），比如支援單個使用者訪問的系統也可以支援10 個、100個、甚至100萬個使用者訪問。在理想情況下，我們的系統應該保持儘可能的“無狀態化（stateless）”。即使必須存在狀態，也可以在網路的不同處理終端上轉化並進行傳輸。當負載成為瓶頸時候，可能就不會出現延遲。所以對於單個請求來說，耗費50到100毫秒也是可以接受的。這就是所謂的橫向擴充套件（Scaling out）。

擴充套件在全網域優化中的表現則完全不同，比如確保成功處理一條資料的演算法也可成功處理10條、100條甚至100萬條資料。無論這種度量型別是是否可行，事件複雜度（大O符號）是最佳描述。延遲是效能擴充套件殺手。你會想盡辦法將所有的運算處理在同一臺機器上進行。這就是所謂的縱向擴充套件（Scaling up）。

如果天上能掉餡餅的話（當然這是不可能的），我們或許能把橫向擴充套件和縱向擴充套件組合起來。但是，今天我們只打算介紹下面幾條提升效率的簡單方法。

大O符號

Java 7的 ForkJoinPool 和Java8 的並行資料流（parallel Stream） 都對並行處理有所幫助。當在多核處理器上部署Java程式時表現尤為明顯，因所有的處理器都可以訪問相同的記憶體。

所以，這種並行處理較之在跨網路的不同機器上進行擴充套件，根本的好處是幾乎可以完全消除延遲。

但不要被並行處理的效果所迷惑！請謹記下面兩點：

• 並行處理會吃光處理器資源。並行處理為批處理帶來了極大的好處，但同時也是非同步伺服器（如HTTP）的噩夢。有很多原因可以解釋，為什麼在過去的幾十年中我們一直在使用單執行緒的Servlet模型。並行處理僅在縱向擴充套件時才能帶來實際的好處。
• 並行處理對演算法複雜度沒有影響。如果你的演算法的時間複雜度為 O(nlogn)，讓演算法在 c 個處理器上執行，事件複雜度仍然為 O(nlogn/c)， 因為 c 只是演算法中的一個無關緊要的常量。你節省的僅僅是時鐘時間（wall-clock time），實際的演算法複雜度並沒有降低。

降低演算法複雜度毫無疑問是改善效能最行之有效的辦法。比如對於一個 HashMap 例項的 lookup() 方法來說，事件複雜度 O(1) 或者空間複雜度 O(1) 是最快的。但這種情況往往是不可能的，更別提輕易地實現。

如果你不能降低演算法的複雜度，也可以通過找到演算法中的關鍵點並加以改善的方法，來起到改善效能的作用。假設我們有下面這樣的演算法示意圖：

該演算法的整體時間複雜度為 O(N3)，如果按照單獨訪問順序計算也可得出複雜度為 O(N x O x P)。但是不管怎樣，在我們分析這段程式碼時會發現一些奇怪的場景：

• 在開發環境中，通過測試資料可以看到：左分支（N->M->Heavy operation）的時間複雜度 M 的值要大於右邊的 O 和 P，所以在我們的分析器中僅僅看到了左分支。
• 在生產環境中，你的維護團隊可能會通過 AppDynamics、DynaTrace 或其它小工具發現，真正導致問題的罪魁禍首是右分支（N -> O -> P -> Easy operation or also N.O.P.E.）。

在沒有生產資料參照的情況下，我們可能會輕易的得出要優化“高開銷操作”的結論。但我們做出的優化對交付的產品沒有起到任何效果。

優化的金科玉律不外乎以下內容：

• 良好的設計將會使優化變得更加容易。
• 過早的優化並不能解決多有的效能問題，但是不良的設計將會導致優化難度的增加。

理論就先談到這裡。假設我們已經發現了問題出現在了右分支上，很有可能是因產品中的簡單處理因耗費了大量的時間而失去響應（假設N、O和 P 的值非常大）， 請注意文章中提及的左分支的時間複雜度為 O(N3)。這裡所做出的努力並不能擴充套件，但可以為使用者節省時間，將困難的效能改善推遲到後面再進行。

這裡有10條改善Java效能的小建議：

1、使用StringBuilder

StingBuilder 應該是在我們的Java程式碼中預設使用的，應該避免使用 + 操作符。或許你會對 StringBuilder 的語法糖（syntax sugar）持有不同意見，比如：

String x = "a" + args.length + "b";

將會被編譯為：

0  new java.lang.StringBuilder [16]
 3  dup
 4  ldc <String "a"> [18]
 6  invokespecial java.lang.StringBuilder(java.lang.String) [20]
 9  aload_0 [args]
10  arraylength
11  invokevirtual java.lang.StringBuilder.append(int) : java.lang.StringBuilder [23]
14  ldc <String "b"> [27]
16  invokevirtual java.lang.StringBuilder.append(java.lang.String) : java.lang.StringBuilder [29]
19  invokevirtual java.lang.StringBuilder.toString() : java.lang.String [32]
22  astore_1 [x]

但究竟發生了什麼？接下來是否需要用下面的部分來對 String 進行改善呢？

String x = "a" + args.length + "b";

if (args.length == 1)
    x = x + args[0];

現在使用到了第二個 StringBuilder，而且這個 StringBuilder 不會消耗堆中額外的記憶體，但卻給 GC 帶來了壓力。

StringBuilder x = new StringBuilder("a");
x.append(args.length);
x.append("b");

if (args.length == 1);
    x.append(args[0]);

小結

在上面的樣例中，如果你是依靠Java編譯器來隱式生成例項的話，那麼編譯的效果幾乎和是否使用了 StringBuilder 例項毫無關係。請記住：在  N.O.P.E 分支中，每次CPU的迴圈的時間到白白的耗費在GC或者為 StringBuilder 分配預設空間上了，我們是在浪費 N x O x P 時間。

一般來說，使用 StringBuilder 的效果要優於使用 + 操作符。如果可能的話請在需要跨多個方法傳遞引用的情況下選擇 StringBuilder，因為 String 要消耗額外的資源。JOOQ在生成複雜的SQL語句便使用了這樣的方式。在整個抽象語法樹（AST Abstract Syntax Tree）SQL傳遞過程中僅使用了一個 StringBuilder 。

更加悲劇的是，如果你仍在使用 StringBuffer 的話，那麼用 StringBuilder 代替 StringBuffer 吧，畢竟需要同步字串的情況真的不多。

2、避免使用正規表示式

正規表示式給人的印象是快捷簡便。但是在 N.O.P.E 分支中使用正規表示式將是最糟糕的決定。如果萬不得已非要在計算密集型程式碼中使用正規表示式的話，至少要將 Pattern 快取下來，避免反覆編譯Pattern。

static final Pattern HEAVY_REGEX =
    Pattern.compile("(((X)*Y)*Z)*");

如果僅使用到了如下這樣簡單的正規表示式的話：

String[] parts = ipAddress.split("//.");

這是最好還是用普通的 char[] 陣列或者是基於索引的操作。比如下面這段可讀性比較差的程式碼其實起到了相同的作用。

int length = ipAddress.length();
int offset = 0;
int part = 0;
for (int i = 0; i < length; i++) {
    if (i == length - 1 ||
            ipAddress.charAt(i + 1) == '.') {
        parts[part] =
            ipAddress.substring(offset, i + 1);
        part++;
        offset = i + 2;
    }
}

上面的程式碼同時表明了過早的優化是沒有意義的。雖然與 split() 方法相比較，這段程式碼的可維護性比較差。

挑戰：聰明的小夥伴能想出更快的演算法嗎？

小結

正規表示式是十分有用，但是在使用時也要付出代價。尤其是在 N.O.P.E 分支深處時，要不惜一切程式碼避免使用正規表示式。還要小心各種使用到正規表示式的JDK字串方法，比如 String.replaceAll() 或 String.split()。可以選擇用比較流行的開發庫，比如 Apache Commons Lang 來進行字串操作。

3、不要使用iterator()方法

這條建議不適用於一般的場合，僅適用於在 N.O.P.E 分支深處的場景。儘管如此也應該有所瞭解。Java 5格式的迴圈寫法非常的方便，以至於我們可以忘記內部的迴圈方法，比如：

for (String value : strings) {
    // Do something useful here
}

當每次程式碼執行到這個迴圈時，如果 strings 變數是一個 Iterable 的話，程式碼將會自動建立一個Iterator 的例項。如果使用的是 ArrayList 的話，虛擬機器會自動在堆上為物件分配3個整數型別大小的記憶體。

private class Itr implements Iterator<E> {
    int cursor;
    int lastRet = -1;
    int expectedModCount = modCount;
    // ...

也可以用下面等價的迴圈方式來替代上面的 for 迴圈，僅僅是在棧上“浪費”了區區一個整形，相當划算。

int size = strings.size();
for (int i = 0; i < size; i++) {
    String value : strings.get(i);
    // Do something useful here
}

如果迴圈中字串的值是不怎麼變化，也可用陣列來實現迴圈。

for (String value : stringArray) {
    // Do something useful here
}

小結

無論是從易讀寫的角度來說，還是從API設計的角度來說迭代器、Iterable介面和 foreach 迴圈都是非常好用的。但代價是，使用它們時是會額外在堆上為每個迴圈子建立一個物件。如果迴圈要執行很多很多遍，請注意避免生成無意義的例項，最好用基本的指標迴圈方式來代替上述迭代器、Iterable介面和 foreach 迴圈。

討論

一些與上述內容持反對意見的看法（尤其是用指標操作替代迭代器）詳見Reddit上的討論。

4、不要呼叫高開銷方法

有些方法的開銷很大。以 N.O.P.E 分支為例，我們沒有提到葉子的相關方法，不過這個可以有。假設我們的JDBC驅動需要排除萬難去計算 ResultSet.wasNull() 方法的返回值。我們自己實現的SQL框架可能像下面這樣：

if (type == Integer.class) {
    result = (T) wasNull(rs,
        Integer.valueOf(rs.getInt(index)));
}

// And then...
static final <T> T wasNull(ResultSet rs, T value)
throws SQLException {
    return rs.wasNull() ? null : value;
}

在上面的邏輯中，每次從結果集中取得 int 值時都要呼叫 ResultSet.wasNull() 方法，但是 getInt() 的方法定義為：

返回型別：變數值；如果SQL查詢結果為NULL，則返回0。

所以一個簡單有效的改善方法如下：

static final <T extends Number> T wasNull(
    ResultSet rs, T value
)
throws SQLException {
    return (value == null ||
           (value.intValue() == 0 && rs.wasNull()))
        ? null : value;
}

這是輕而易舉的事情。

小結

將方法呼叫快取起來替代在葉子節點的高開銷方法，或者在方法約定允許的情況下避免呼叫高開銷方法。

5、使用原始型別和棧

上面介紹了來自 jOOQ的例子中使用了大量的泛型，導致的結果是使用了 byte、 short、 int 和 long 的包裝類。但至少泛型在Java 10或者Valhalla專案中被專門化之前，不應該成為程式碼的限制。因為可以通過下面的方法來進行替換：

//儲存在堆上
Integer i = 817598;

……如果這樣寫的話：

// 儲存在棧上
int i = 817598;

在使用陣列時情況可能會變得更加糟糕：

//在堆上生成了三個物件
Integer[] i = { 1337, 424242 };

……如果這樣寫的話：

// 僅在堆上生成了一個物件
int[] i = { 1337, 424242 };

小結

當我們處於 N.O.P.E. 分支的深處時，應該極力避免使用包裝類。這樣做的壞處是給GC帶來了很大的壓力。GC將會為清除包裝類生成的物件而忙得不可開交。

所以一個有效的優化方法是使用基本資料型別、定長陣列，並用一系列分割變數來標識物件在陣列中所處的位置。

遵循LGPL協議的 trove4j 是一個Java集合類庫，它為我們提供了優於整形陣列 int[] 更好的效能實現。

例外

下面的情況對這條規則例外：因為 boolean 和 byte 型別不足以讓JDK為其提供快取方法。我們可以這樣寫：

Boolean a1 = true; // ... syntax sugar for:
Boolean a2 = Boolean.valueOf(true);

Byte b1 = (byte) 123; // ... syntax sugar for:
Byte b2 = Byte.valueOf((byte) 123);

其它整數基本型別也有類似情況，比如 char、short、int、long。

不要在呼叫構造方法時將這些整型基本型別自動裝箱或者呼叫 TheType.valueOf() 方法。

也不要在包裝類上呼叫構造方法，除非你想得到一個不在堆上建立的例項。這樣做的好處是為你為同事獻上一個巨坑的愚人節笑話。

非堆儲存

當然了，如果你還想體驗下堆外函式庫的話，儘管這可能參雜著不少戰略決策，而並非最樂觀的本地方案。一篇由Peter Lawrey和 Ben Cotton撰寫的關於非堆儲存的很有意思文章請點選： OpenJDK與HashMap——讓老手安全地掌握（非堆儲存！）新技巧。

6、避免遞迴

現在，類似Scala這樣的函數語言程式設計語言都鼓勵使用遞迴。因為遞迴通常意味著能分解到單獨個體優化的尾遞迴（tail-recursing）。如果你使用的程式語言能夠支援那是再好不過。不過即使如此，也要注意對演算法的細微調整將會使尾遞迴變為普通遞迴。

希望編譯器能自動探測到這一點，否則本來我們將為只需使用幾個本地變數就能搞定的事情而白白浪費大量的堆疊框架（stack frames）。

小結

這節中沒什麼好說的，除了在 N.O.P.E 分支儘量使用迭代來代替遞迴。

7、使用entrySet()

當我們想遍歷一個用鍵值對形式儲存的 Map 時，必須要為下面的程式碼找到一個很好的理由：

for (K key : map.keySet()) {
    V value : map.get(key);
}

更不用說下面的寫法：

for (Entry<K, V> entry : map.entrySet()) {
    K key = entry.getKey();
    V value = entry.getValue();
}

在我們使用 N.O.P.E. 分支應該慎用map。因為很多看似時間複雜度為 O(1) 的訪問操作其實是由一系列的操作組成的。而且訪問本身也不是免費的。至少，如果不得不使用map的話，那麼要用 entrySet() 方法去迭代！這樣的話，我們要訪問的就僅僅是Map.Entry的例項。

小結

在需要迭代鍵值對形式的Map時一定要用 entrySet() 方法。

9、使用EnumSet或EnumMap

在某些情況下，比如在使用配置map時，我們可能會預先知道儲存在map中鍵值。如果這個鍵值非常小，我們就應該考慮使用 EnumSet 或 EnumMap，而並非使用我們常用的 HashSet 或 HashMap。下面的程式碼給出了很清楚的解釋：

private transient Object[] vals;

public V put(K key, V value) {
    // ...
    int index = key.ordinal();
    vals[index] = maskNull(value);
    // ...
}

上段程式碼的關鍵實現在於，我們用陣列代替了雜湊表。尤其是向map中插入新值時，所要做的僅僅是獲得一個由編譯器為每個列舉型別生成的常量序列號。如果有一個全域性的map配置（例如只有一個例項），在增加訪問速度的壓力下，EnumMap 會獲得比 HashMap 更加傑出的表現。原因在於 EnumMap 使用的堆記憶體比 HashMap 要少 一位（bit），而且 HashMap 要在每個鍵值上都要呼叫 hashCode() 方法和 equals() 方法。

小結

Enum 和 EnumMap 是親密的小夥伴。在我們用到類似列舉（enum-like）結構的鍵值時，就應該考慮將這些鍵值用宣告為列舉型別，並將之作為 EnumMap 鍵。

9、優化自定義hasCode()方法和equals()方法

在不能使用EnumMap的情況下，至少也要優化 hashCode() 和 equals() 方法。一個好的 hashCode() 方法是很有必要的，因為它能防止對高開銷 equals() 方法多餘的呼叫。

在每個類的繼承結構中，需要容易接受的簡單物件。讓我們看一下jOOQ的 org.jooq.Table 是如何實現的？

最簡單、快速的 hashCode() 實現方法如下：

// AbstractTable一個通用Table的基礎實現：

@Override
public int hashCode() {

    // [#1938] 與標準的QueryParts相比，這是一個更加高效的hashCode()實現
    return name.hashCode();
}

name即為表名。我們甚至不需要考慮schema或者其它表屬性，因為表名在資料庫中通常是唯一的。並且變數 name 是一個字串，它本身早就已經快取了一個 hashCode() 值。

這段程式碼中註釋十分重要，因繼承自 AbstractQueryPart 的 AbstractTable 是任意抽象語法樹元素的基本實現。普通抽象語法樹元素並沒有任何屬性，所以不能對優化 hashCode() 方法實現抱有任何幻想。覆蓋後的 hashCode() 方法如下：

// AbstractQueryPart一個通用抽象語法樹基礎實現：

@Override
public int hashCode() {
    // 這是一個可工作的預設實現。
    // 具體實現的子類應當覆蓋此方法以提高效能。
    return create().renderInlined(this).hashCode();
}

換句話說，要觸發整個SQL渲染工作流程（rendering workflow）來計算一個普通抽象語法樹元素的hash程式碼。

equals() 方法則更加有趣：

// AbstractTable通用表的基礎實現：

@Override
public boolean equals(Object that) {
    if (this == that) {
        return true;
    }

    // [#2144] 在呼叫高開銷的AbstractQueryPart.equals()方法前，
    // 可以及早知道物件是否不相等。
    if (that instanceof AbstractTable) {
        if (StringUtils.equals(name,
            (((AbstractTable<?>) that).name))) {
            return super.equals(that);
        }

        return false;
    }

    return false;
}

首先，不要過早使用 equals() 方法（不僅在N.O.P.E.中），如果：

• this == argument
• this“不相容：引數

注意：如果我們過早使用 instanceof 來檢驗相容型別的話，後面的條件其實包含了argument == null。我在以前的部落格中已經對這一點進行了說明，請參考10個精妙的Java編碼最佳實踐。

在我們對以上幾種情況的比較結束後，應該能得出部分結論。比如jOOQ的 Table.equals() 方法說明是，用來比較兩張表是否相同。不論具體實現型別如何，它們必須要有相同的欄位名。比如下面兩個元素是不可能相同的：

• com.example.generated.Tables.MY_TABLE
• DSL.tableByName(“MY_OTHER_TABLE”)

如果我們能方便地判斷傳入引數是否等於例項本身（this），就可以在返回結果為 false 的情況下放棄操作。如果返回結果為 true，我們還可以進一步對父類（super）實現進行判斷。在比較過的大多數物件都不等的情況下，我們可以儘早結束方法來節省CPU的執行時間。

一些物件的相似度比其它物件更高。

在jOOQ中，大多數的表例項是由jOOQ的程式碼生成器生成的，這些例項的 equals() 方法都經過了深度優化。而數十種其它的表型別（衍生表 （derived tables）、表值函式（table-valued functions）、陣列表（array tables）、連線表（joined tables）、資料透視表（pivot tables）、公用表表示式（common table expressions）等，則保持 equals() 方法的基本實現。

10、考慮使用set而並非單個元素

最後，還有一種情況可以適用於所有語言而並非僅僅同Java有關。除此以外，我們以前研究的 N.O.P.E. 分支也會對了解從 O(N3) 到 O(n log n)有所幫助。

不幸的是，很多程式設計師的用簡單的、本地演算法來考慮問題。他們習慣按部就班地解決問題。這是命令式（imperative）的“是/或”形式的函式式程式設計風格。這種程式設計風格在由純粹指令式程式設計向面物件式程式設計向函數語言程式設計轉換時，很容易將“更大的場景（bigger picture）”模型化，但是這些風格都缺少了只有在SQL和R語言中存在的：

宣告式程式設計。

在SQL中，我們可以在不考慮演算法影響下宣告要求資料庫得到的效果。資料庫可以根據資料型別，比如約束（constraints）、鍵（key）、索引（indexes）等不同來採取最佳的演算法。

在理論上，我們最初在SQL和關係演算（relational calculus）後就有了基本的想法。在實踐中，SQL的供應商們在過去的幾十年中已經實現了基於開銷的高效優化器CBOs (Cost-Based Optimisers) 。然後到了2010版，我們才終於將SQL的所有潛力全部挖掘出來。

但是我們還不需要用set方式來實現SQL。所有的語言和庫都支援Sets、collections、bags、lists。使用set的主要好處是能使我們的程式碼變的簡潔明瞭。比如下面的寫法：

SomeSet INTERSECT SomeOtherSet

而不是

// Java 8以前的寫法
Set result = new HashSet();
for (Object candidate : someSet)
    if (someOtherSet.contains(candidate))
        result.add(candidate);

// 即使採用Java 8也沒有很大幫助
someSet.stream()
       .filter(someOtherSet::contains)
       .collect(Collectors.toSet());

有些人可能會對函數語言程式設計和Java 8能幫助我們寫出更加簡單、簡潔的演算法持有不同的意見。但這種看法不一定是對的。我們可以把命令式的Java 7迴圈轉換成Java 8的Stream collection，但是我們還是採用了相同的演算法。但SQL風格的表示式則是不同的：

SomeSet INTERSECT SomeOtherSet

上面的程式碼在不同的引擎上可以有1000種不同的實現。我們今天所研究的是，在呼叫 INTERSECT 操作之前，更加智慧地將兩個set自動的轉化為 EnumSet 。甚至我們可以在不需要呼叫底層的 Stream.parallel() 方法的情況下進行並行 INTERSECT 操作。

總結

在這篇文章中，我們討論了關於N.O.P.E.分支的優化。比如深入高複雜性的演算法。作為jOOQ的開發者，我們很樂於對SQL的生成進行優化。

• 每條查詢都用唯一的StringBuilder來生成。
• 模板引擎實際上處理的是字元而並非正規表示式。
• 選擇儘可能的使用陣列，尤其是在對監聽器進行迭代時。
• 對JDBC的方法敬而遠之。
• 等等。

jOOQ處在“食物鏈的底端”，因為它是在離開JVM進入到DBMS時，被我們電腦程式所呼叫的最後一個API。位於食物鏈的底端意味著任何一條線路在jOOQ中被執行時都需要 N x O x P 的時間，所以我要儘早進行優化。

我們的業務邏輯可能沒有N.O.P.E.分支那麼複雜。但是基礎框架有可能十分複雜（本地SQL框架、本地庫等）。所以需要按照我們今天提到的原則，用Java Mission Control 或其它工具進行復查，確認是否有需要優化的地方。