如何降低Java垃圾回收開銷

Tip #1: 預測集合的容量

# 所有標準的 Java 集合，包括自訂和擴展的實作(例如 Trove 和 Google 的 Guava),底層都使用了數組(原生資料類型或基於物件的類型)。因為數組一旦被分配，其大小就不可變，因此當添加元素到集合時，大多數情況下都會導致需要重新申請一個新的大容量數組替換老的數組（指集合底層實現使用的數組）。

即使沒有提供集合初始化的大小，大多數集合的實作都盡量優化重新分配數組的處理並且將其開銷平攤到最低。不過，在構造集合的時候就提供大小可以得到最佳的效果。

讓我們將下面的程式碼作為一個簡單的範例來分析一下:

public static List reverse(List & lt; ? extends T & gt; list) {

List result = new ArrayList();

for (int i = list.size() - 1; i & gt; = 0; i--) {

result.add(list.get(i));

}

return result;

}

This method allocates a new array, then fills it up with items from another list, only in reverse order. 這個方法分配了一個新的數組，然後用另一個list 中元素對該數組進行填充，只是元素的數組發生了變化。

這個處理方式可能會付出慘痛的效能代價，其最佳化的點在新增元素到新的 list 中這行程式碼。隨著每一次添加元素，list 都需要確保其底層數組擁有足夠的位置來容納新的元素。如果有空閒的位置，那麼只是簡單地將新元素儲存到下一個空閒的插槽。如果沒有的話，將分配一個新的底層數組，將其拷貝舊的數組內容分配到新的數組中，然後添加新的元素。這將導致多次分配數組，那些剩餘的舊數組最終被 GC 回收。

我們可以透過在建構集合時讓其底層的陣列知道它將儲存多少元素，從而避免這些多餘的分配

public static List reverse(List & lt; ? extends T & gt; list) {

List result = new ArrayList(list.size());

for (int i = list.size() - 1; i & gt; = 0; i--) {

result.add(list.get(i));

}

return result;

}

上面的程式碼透過 ArrayList 的建構器指定足夠大的空間來儲存 list.size() 個元素，在初始化時完成分配的執行，這意味著 List 在迭代的過程中無需再次分配記憶體。

Guava 的集合類別則更進一步，允許初始化集合時明確指定期望元素的個數或指定預測值。

1

2List result = Lists.newArrayListWithCapacity(list.size());

List result = Lists.newArrayListWithExpectedSize(list.size());

在上面的程式碼中，前者用於我們已經準確地知道集合將要儲存多少元素，而後者的分配方式考慮了錯誤預估的情況。

Tip #2:直接處理資料流

# 當處理資料流時，例如從一個檔案讀取資料或從網路下載數據，下面的程式碼是非常常見的：

# 1byte[] fileData = readFileToByteArray(new File("myfile.txt"));

# 所產生的位元組數組可能被解析 XML 文件、JSON 物件或協定緩衝訊息，以及一些常見的可選項。

當處理大檔案或檔案的大小無法預測時，上面的做法很是不明智的，因為當 JVM 無法指派一個緩衝區來處理真正檔案時，就會導致OutOfMemeoryErrors。

即使資料的大小是可管理的，當到垃圾回收時，使用上面的模式仍然會造成巨大的開銷，因為它在堆中分配了一塊非常大的區域來儲存檔案資料。

一種更好的處理方式是使用合適的 InputStream (例如在這個例子中使用 FileInputStream)直接傳遞給解析器，不再一次將整個檔案讀取到一個位元組數組中。所有主流的開源函式庫都提供對應的 API 來直接接受一個輸入流進行處理,例如:

FileInputStream fis = new FileInputStream(fileName);

MyProtoBufMessage msg = MyProtoBufMessage.parseFrom(fis);

Tip #3: 使用不可變的物件

# 不變性有太多的好處。甚至不用我贅述什麼。然而，有一個優點會對垃圾回收產生影響，應該要關心一下。

一個不可變物件的屬性在物件被建立後就不能被修改(在這裡的例子使用的是引用資料型別的屬性)，例如:

public class ObjectPair {

# private final Object first;

private final Object second;

public ObjectPair(Object first, Object second) {

# this.first = first;

# this.second = second;

# }

public Object getFirst() {

return first;

}

public Object getSecond() {

# return second;

}

}

將上面的類別實例化後會產生一個不可變物件—它的所有屬性用 final 修飾,建構完成後就不能改變了。

不可變性意味著所有被一個不可變容器所引用的對象，在容器構造完成前對象就已經被創建。就 GC 而言：這個容器年輕程度至少和其所持有的最年輕的引用一樣。這意味著當在年輕代執行垃圾回收的過程中，GC 因為不可變對象處於老年代而跳過它們，直到確定這些不可變對像在老年代中不被任何對象所引用時，才完成對它們的回收。

更少的掃描物件意味著對記憶體頁更少的掃描，越少的掃描記憶體頁就意味著更短的 GC 生命週期，也意味著更短的 GC 暫停和更好的總吞吐量。

Tip #4: 小心字串拼接

字串可能是在所有基於 JVM 應用程式中最常用的非原生資料結構。然而，由於其隱式地開銷負擔和簡便的使用，非常容易成為佔用大量記憶體的罪歸禍首。

這個問題很明顯不在於字串字面值，而是在運行時分配記憶體初始化產生的。讓我們快速看一下動態建構字串的範例：

public static String toString(T[] array) {

# String result = "[";

# for (int i = 0; i & lt; array.length; i ) {

# result = (array[i] == array ? "this" : array[i]);

if (i & lt; array.length - 1) {

result = ", ";

# }

}

result = "]";

return result;

}

這是個看似不錯的方法，接收一個字元陣列然後回傳一個字串。但這對於物件記憶體分配卻是災難性的。

很難看清這語法糖的背後，但幕後的實際情況是這樣的：

# public static String toString(T[] array) {

# String result = "[";

# for (int i = 0; i & lt; array.length; i ) {

# StringBuilder sb1 = new StringBuilder(result);

# sb1.append(array[i] == array ? "this" : array[i]);

result = sb1.toString();

if (i & lt; array.length - 1) {

StringBuilder sb2 = new StringBuilder(result);

# sb2.append(", ");

result = sb2.toString();

}

}

StringBuilder sb3 = new StringBuilder(result);

# sb3.append("]");

result = sb3.toString();

return result;

}

字串是不可變的，這意味著每發生一次拼接時，它們本身不會被修改，而是依序分配新的字串。此外，編譯器使用了標準的 StringBuilder 類別來執行這些拼接操作。這就會有問題了，因為每一次迭代，既隱式地分配了一個臨時字串，又隱式分配了一個臨時的 StringBuilder 物件來幫助建立最終的結果。

最佳的方式是避免上面的情況，使用 StringBuilder 和直接的追加，以取代本地拼接運算元(“ ”)。下面是一個例子:

public static String toString(T[] array) {

# StringBuilder sb = new StringBuilder("[");

# for (int i = 0; i & lt; array.length; i ) {

# sb.append(array[i] == array ? "this" : array[i]);

if (i & lt; array.length - 1) {

sb.append(", ");

}

}

sb.append("]");

return sb.toString();

# }

這裡，我們只在方法開始的時候分配了唯一的一個 StringBuilder。至此，所有的字串和 list 中的元素都被追加到單獨的一個StringBuilder中。最終使用 toString() 方法一次將其轉成字串返回。

Tip #5: 使用特定的原生類型的集合

Java 標準的集合庫簡單且支援泛型，允許在使用集合時對類型進行半靜態綁定。例如想要建立一個只存放字串的 Set 或儲存 Map這樣的 map，這種處理方式是很棒的。

真正的問題源自於當我們想要使用一個 list 儲存 int 類型，或是一個 map 儲存 double 類型作為 value。因為泛型不支援原生資料類型，因此另外的一種選擇是使用包裝類型來進行替換，這裡我們使用 List 。

這種處理方式是非常浪費的，因為一個 Integer 是一個完全的對象，一個物件的頭部佔用12個位元組以及其內部的所維護的 int 屬性，每個Integer 物件總共佔用16個位元組。這比起儲存相同個數的 int 類型的 list 而言，其消耗的空間是它的四倍！比這個更嚴重的問題在於，事實上因為 Integer 是真正的物件實例，因此它需要垃圾收集階段被垃圾收集器所考慮是否要回收。

為了處理這個問題，我們在 Takipi 中使用非常棒的 Trove 集合庫。 Trove 摒棄了部分泛型的特定性來支援特定的使用記憶體更有效率的原生類型的集合。例如，我們使用非常消耗效能的 Map,在 Trove 中有另一個特別的選擇方案，其形式為 TIntDoubleMap

TIntDoubleMap map = new TIntDoubleHashMap();

# map.put(5, 7.0);

map.put(-1, 9.999);

...

Trove 的底層實作使用了原生型別的數組，所以當操作集合的時候不會發生元素的裝箱(int->Integer)或拆箱(Integer->int), 沒有儲存對象，因為底層使用原生資料類型儲存。

以上是如何降低Java垃圾回收開銷的詳細內容。更多資訊請關注PHP中文網其他相關文章！