調優垃圾回收與任何其他性能調優活動沒有什么不同。

您需要確保了解當前的情況和期望的結果，而不是因為對應用程序的隨機部分進行調整而產生了誘惑。 通常，只需執行以下過程即可：

陳述您的績效目標

運行測試

測量

與目標比較

進行更改并返回運行測試

重要的是，可以設定和衡量目標的三個維度都與性能調整有關。 這些目標包括延遲，吞吐量和容量，理解，我建議您閱讀垃圾收集手冊中的相應章節。

讓我們看看我們如何開始研究設定和實現這些目標的實際情況。 為此，讓我們看一個示例代碼：

//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;}@Overridepublic 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();} }

該代碼將提交兩個作業，每100毫秒運行一次。 每個作業都模擬具有特定壽命的對象：它創建對象，讓它們離開預定的時間，然后忘記它們，從而使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]

根據日志中的信息，我們可以著眼于三個不同的目標來改善情況

確保最壞情況下的GC暫停不超過預定閾值

確保停止應用程序線程的總時間不超過預定閾值

降低基礎架構成本，同時確保我們仍然可以實現合理的延遲和/或吞吐量目標。

為此，上面的代碼在三種不同的配置上運行了10分鐘，導致下表總結了三種截然不同的結果：

堆 GC算法 有用的工作 最長的停頓

-Xmx12g	-XX：+ UseConcMarkSweepGC	89.8％	560毫秒
-Xmx12g	-XX：+ UseParallelGC	91.5％	1,104毫秒
-Xmx8g	-XX：+ UseConcMarkSweepGC	66.3％	1,610毫秒

實驗使用不同的GC算法和不同的堆大小運行相同的代碼，以測量有關延遲和吞吐量的垃圾收集暫停的持續時間。 有關實驗的詳細信息和結果的解釋，請參見《 垃圾收集手冊》 。 請看一下手冊中的示例，了解配置的簡單更改如何使示例在延遲，容量吞吐量方面完全不同。

請注意，為了使示例盡可能簡單，僅更改了有限數量的輸入參數，例如，實驗未在不同數量的內核或不同的堆布局上進行測試。

翻譯自: https://www.javacodegeeks.com/2015/06/gc-tuning-in-practice.html

總結

以上是生活随笔為你收集整理的实际中进行GC调整的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。