//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();
}
}</pre>
代碼中提交了兩個作業（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]
基于日志中的信息，我們可以開始改善性能。并請牢記三個不同的目標：
- 確保 GC pause（垃圾回收暫停）的最壞情況不要超過預期的臨界值。
- 確保應用程序線程停滯時間不超過預先確定的閥值。
- 降低基礎架構成本，同時確保我們仍可以實現合理的延遲和吞吐量目標。
</ol>
為此，以三個不同的配置各運行了10分鐘，在下表中總結了三個差距較大的結果：
| 堆 |
GC算法 |
有效工作 |
長暫停 |
</tr>
</tbody>
| -Xmx12g |
-XX:+UseConcMarkSweepGC |
89.8% |
560 ms |
</tr>
| -Xmx12g |
-XX:+UseParallelGC |
91.5% |
1,104 ms |
</tr>
| -Xmx8g |
-XX:+UseConcMarkSweepGC |
66.3% |
1,610 ms |
</tr>
</tbody>
</table>
實驗中，設置不同的 GC 算法和不同的堆大小，運行相同的代碼，然后測量垃圾回收暫停的持續時間和吞吐量。實驗細節和結果的解釋都在我們的垃圾回收手冊中。看看手冊中的一些例子，修改一些簡單的配置造成延遲、吞吐量等各方面的性能完全不同。
注意：為了保持示例盡可能簡單，只有數量有限的輸入參數被改變，例如沒有對不同數量的核心（CPU core）或不同堆布局 進行測試。
原文鏈接： javacodegeeks 翻譯： ImportNew.com - 光光頭去打醬油
譯文鏈接： http://www.importnew.com/16223.html
本文由用戶
jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！
sesese色