[jvm垃圾回收机制]Java垃圾回收调优教程及实例

时间:2019-11-23  来源:其它  阅读:

Java 垃圾回收调优和其它性能优化活动相比,首先你要确保自己足够了解整个应用的情况以及调优预期的结果,而不是单单满足于应用的某一部分调优。一般情况下,遵循以下过程比较容易:

    明确自己的性能目标。
    测试。
    测量调优结果。
    与目标进行比较。
    改变方法并再次测试。

性能调优目标要是可确定且可测量的,这非常重要。这些目标包括延迟、吞吐量和容量,想要了解更多,我推荐看看垃圾回收手册(Garbage Collection Handbook)中相应的章节。让我们看看在实践中如何设定并达到这样的调优目标。为了这个目的,让我们来看一个示例代码:

//imports skipped for brevity
public class Producer implements Runnable {
 
  private static ScheduledExecutorService executorService = Executors.newScheduledThreadPool(2);
 
  private Deque deque;
  private int objectSize;
  private int queueSize;
 
  public Producer(int objectSize, int ttl) {
    this.deque = new ArrayDeque();
    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 日志并使用以下参数:
1
    
-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(垃圾回收暂停)的最坏情况不要超过预期的临界值。
    确保应用程序线程停滞时间不超过预先确定的阀值。
    降低基础架构成本,同时确保我们仍可以实现合理的延迟和吞吐量目标。

为此,以三个不同的配置各运行了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)或不同堆布局进行测试。




一次Java垃圾收集调优实战


1 资料

    JDK5.0垃圾收集优化之--Don't Pause(花钱的年华)  
    编写对GC友好,又不泄漏的代码(花钱的年华)  
    JVM调优总结  
    JDK 6所有选项及默认值  

2 GC日志打印

  GC调优是个很实验很伽利略的活儿,GC日志是先决的数据参考和最终验证:

-XX:+PrintGCDetails -XX:+PrintGCTimeStamps(GC发生的时间) -XX:+PrintGCApplicationStoppedTime(GC消耗了多少时间) -XX:+PrintGCApplicationConcurrentTime(GC之间运行了多少时间)

 
3 收集器选择


CMS收集器:暂停时间优先

   配置参数:-XX:+UseConcMarkSweepGC
   已默认无需配置的参数:-XX:+UseParNewGC(Parallel收集新生代) -XX:+CMSPermGenSweepingEnabled(CMS收集持久代) -XX:UseCMSCompactAtFullCollection(full gc时压缩年老代)

   初始效果:1g堆内存的新生代约60m,minor gc约5-20毫秒,full gc约130毫秒。
Parallel收集器:吞吐量优先

    配置参数: -XX:+UseParallelGC -XX:+UseParallelOldGC(Parallel收集年老代,从JDK6.0开始支持)

    已默认无需配置的参数: -XX:+UseAdaptiveSizePolicy(动态调整新生代大小)

    初始效果:1g堆内存的新生代约90-110m(动态调整),minor gc约5-20毫秒,full gc有无UseParallelOldGC 参数分别为1.3/1.1秒,差别不大。

    另外-XX:MaxGCPauseMillis=100 设置minor gc的期望最大时间,JVM会以此来调整新生代的大小,但在此测试环境中对象死的太快,此参数作用不大。
4 调优实战

      Parallel收集高达1秒的暂停时间基本不可忍受,所以选择CMS收集器。

      在被压测的Mule 2.0应用里,每秒都有大约400M的海量短命对象产生:

    因为默认60M的新生代太小了,频繁发生minor gc,大约0.2秒就进行一次。
    因为CMS收集器中MaxTenuringThreshold(生代对象撑过过多少次minor gc才进入年老代的设置)默认0,存活的临时对象不经过Survivor区直接进入年老代,不久就占满年老代发生full gc。

     对这两个参数的调优,既要改善上面两种情况,又要避免新生代过大,复制次数过多造成minor gc的暂停时间过长。

    使用-Xmn调到1/3 总内存。观察后设置-Xmn500M,新生代实际约460m。(用-XX:NewRatio设置无效,只能用 -Xmn)。
    添加-XX:+PrintTenuringDistribution 参数观察各个Age的对象总大小,观察后设置-XX:MaxTenuringThreshold=5。

      优化后,大约1.1秒才发生一次minor gc,且速度依然保持在15-20ms之间。同时年老代的增长速度大大减缓,很久才发生一次full gc,

      参数定稿:

 -server -Xms1024m -Xmx1024m -Xmn500m -XX:+UseConcMarkSweepGC   -XX:MaxTenuringThreshold=5  -XX:+ExplicitGCInvokesConcurrent

 

最后服务处理速度从1180 tps 上升到1380 tps,调整两个参数提升17%的性能还是笔很划算的买卖。


另外,JDK6 Update 7自带了一个VisualVM工具,内里就是之前也有用过的Netbean Profiler,类似JConsole一样使用,可以看到线程状态,内存中对象以及方法的CPU时间等调优重要参考依据。

[jvm垃圾回收机制]Java垃圾回收调优教程及实例

http://m.bbyears.com/luyouqishezhi/80846.html

推荐访问:jvm 垃圾回收算法
相关阅读 猜你喜欢
本类排行 本类最新