JVM GC 機制與性能優化 2 實例測試

Java 垃圾回收調優不一樣於任何其它性能優化活動。

首先你要確保本身足夠了解整個應用的狀況以及調優預期的結果，而不是單單知足於應用的某一部分調優。通常狀況下，遵循如下過程比較容易：

1. 明確本身的性能目標。
2. 測試。
3. 測量調優結果。
4. 與目標進行比較。
5. 改變方法並再次測試。

性能調優目標要是可肯定且可測量的，這很是重要。這些目標包括延遲、吞吐量和容量，想要了解更多，我推薦看看垃圾回收手冊（Garbage Collection Handbook）中相應的章節。讓咱們看看在實踐中如何設定並達到這樣的調優目標。爲了這個目的，讓咱們來看一個示例代碼：

//imports skipped for brevity
public class Producer implements Runnable {
 
  private static ScheduledExecutorService executorService = Executors.newScheduledThreadPool(2);
 
  private Deque<byte[]> deque;
  private int objectSize;
  private int queueSize;
 
  public Producer(int objectSize, int ttl) {
    this.deque = new ArrayDeque<byte[]>();
    this.objectSize = objectSize;
    this.queueSize = ttl * 1000;
  }
 
  @Override
  public void run() {
    for (int i = 0; i < 100; i++) {
      deque.add(new byte[objectSize]);
      if (deque.size() > queueSize) {
        deque.poll();
      }
    }
  }
 
  public static void main(String[] args) throws InterruptedException {
    executorService.scheduleAtFixedRate(new Producer(200 * 1024 * 1024 / 1000, 5), 0, 100, TimeUnit.MILLISECONDS);
    executorService.scheduleAtFixedRate(new Producer(50 * 1024 * 1024 / 1000, 120), 0, 100, TimeUnit.MILLISECONDS);
    TimeUnit.MINUTES.sleep(10);
    executorService.shutdownNow();
  }
}

代碼中提交了兩個做業（job），且每 100ms 運行一次。每一個做業模擬特定對象的生命週期：先建立對象，讓它們「存活」一段時間，而後忘記它們，讓 GC 回收內存。 運行這個示例時，開啓 GC 日誌並使用如下參數：

-XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps

咱們當即在日誌文件中看到 GC 的影響和下面這些類似：

2015-06-04T13:34:16.119-0200: 1.723: [GC (Allocation Failure) [PSYoungGen: 114016K->73191K(234496K)] 421540K->421269K(745984K), 0.0858176 secs] [Times: user=0.04 sys=0.06, real=0.09 secs] 
2015-06-04T13:34:16.738-0200: 2.342: [GC (Allocation Failure) [PSYoungGen: 234462K->93677K(254976K)] 582540K->593275K(766464K), 0.2357086 secs] [Times: user=0.11 sys=0.14, real=0.24 secs] 
2015-06-04T13:34:16.974-0200: 2.578: [Full GC (Ergonomics) [PSYoungGen: 93677K->70109K(254976K)] [ParOldGen: 499597K->511230K(761856K)] 593275K->581339K(1016832K), [Metaspace: 2936K->2936K(1056768K)], 0.0713174 secs] [Times: user=0.21 sys=0.02, real=0.07 secs]

基於日誌中的信息，咱們能夠開始改善性能。並請牢記三個不一樣的目標：

1. 確保 GC pause（垃圾回收暫停）的最壞狀況不要超過預期的臨界值。
2. 確保應用程序線程停滯時間不超過預先肯定的閥值。
3. 下降基礎架構成本，同時確保咱們仍能夠實現合理的延遲和吞吐量目標。

爲此，以三個不一樣的配置各運行了10分鐘，在下表中總結了三個差距較大的結果：

堆	GC算法	有效工做	長暫停
-Xmx12g	-XX:+UseConcMarkSweepGC	89.8%	560 ms
-Xmx12g	-XX:+UseParallelGC	91.5%	1,104 ms
-Xmx8g	-XX:+UseConcMarkSweepGC	66.3%	1,610 ms

實驗中，設置不一樣的 GC 算法和不一樣的堆大小，運行相同的代碼，而後測量垃圾回收暫停的持續時間和吞吐量。實驗細節和結果的解釋都在咱們的垃圾回收手冊中。看看手冊中的一些例子，修改一些簡單的配置形成延遲、吞吐量等各方面的性能徹底不一樣。

注意：爲了保持示例儘量簡單，只有數量有限的輸入參數被改變，例如沒有對不一樣數量的核心（CPU core）或不一樣堆佈局進行測試。

翻譯： ImportNew.com - 光光頭去打醬油