http://blog.csdn.net/zhoutao198712/article/details/7791969   
本节的目标是做一些优化以满足对应用对延迟的需求。这次需要几个步骤，包括完善Java堆大小的配置，评估垃圾回收占用的时间和频率，也许还要尝试切换到不同的垃圾回收器，以及由于使用了不同的垃圾回收器，需要重新优化Java堆空间大小。
这一步有如下可能的结果：
1、应用的延迟需求被满足了。如果这一步的优化操作满足了应用的延迟需求，你可以继续下一步优化（优化吞吐量）。
2、应用的延迟需求未被满足。如果这一步的优化操作未能满足延迟需求，你可能需要重新看看延迟需求是否合理或者修改应用程序。一些可能的问题可以帮助改善应用的延迟问题：
a、优化Java堆以及修改应用以减少对象的分配和对象的长时间存活。
b、修改JVM的部署结构，让每一个JVM做更少的工作。
上面的两个步骤都可以减少JVM的对象分配，因此减少垃圾回收的频率。
这一步从查看垃圾回收对应用的延迟的影响开始，基于前面一节“决定内存消耗”计算出来的Java堆大小。
下面列出了评估垃圾回收对延迟的影响需要进行的几个事情：
1、测量MinorGC的时间。
2、测量MinorGC的频率。
3、测量FullGC的时间。
4、测量FullGC的频率。
测量垃圾回收的时间的和频率对于改善Java堆大小配置来说是非常重要的。MinorGC的时间和频率的测量结果可以用来改善young代的空间大小。测量最坏情况下FullGC的时间和频率可以用来决定old代的大小，以及是否需要切换成吞吐量垃圾回收器（通过使用-XX:+UseParalleOldGC或者-XX:+UseParallelGC）或者并发垃圾回收器（CMS，通过使用-XX:+UseConcMarkSweepGC）。在使用吞吐量垃圾回收器的时候，如果垃圾回收的延迟和频率太高以导致应用的延迟需求无法满足的时候才切换到CMS，如果选择了切换，需要对CMS垃圾回收器进行优化，后面会详细介绍这个问题。
接下来详细介绍前面提到的各种情况。
  需求
下面列举了几个这一步优化操作需求，它们来源于应用的系统需求：
1、可以接收的平均暂停时间。平均暂停时间需求用于和MinorGC消耗的时间比较。
2、可以接收的MinorGC的频率。其实频道对于应用负责人来说，没有平均延迟时间重要。
3、应用负责人能够接受的最大延迟时间。这个时间受到FullGC的影响。
4、应用负责人能够接收的最大延迟的频率，即FullGC的频率。其实，大多数时间应用管理员还是更加关心应用的的最大延迟时间超过了最大延迟的频率。
一旦确定了需求，这些垃圾回收器的时间消耗和频率都可以通过垃圾回收日志收集到。先把垃圾回收器设置为吞吐量垃圾回收器（设置-XX:+UseParallelOldeGC或者-XX:+UseParallelGC）。通过反复测试，可以让young代和old代满足上面的要求。下面2节介绍如何优化young代和old代空间大小来观察MinorGC和最坏情况的FullGC的消耗时间和频率。
改善young代的大小
确定young代的大小是通过评估垃圾回收的统计信息以及观察MinorGC的消耗时间和频率，下面举例说明如何通过垃圾回收的统计信息来确定young代的大小。
尽管MinorGC消耗的时间和young代里面的存活的对象数量有直接关系，但是一般情况下，更小young代空间，更短的MinorGC时间。如果不考虑MinorGC的时间消耗，减少young代的大小会导致MinorGC变得更加频繁，由于更小的空间，用玩空间会用更少的时间。同理，提高young代的大小会降低MinorGC的频率。
当测试垃圾回收数据的时候，发现MinorGC的时间太长了，正确的做法就是减少young代的空间大小。如果MinorGC太频繁了就增加young代的空间大小。
   
上图是一个展示了MinorGC的例子，这个例子是运行在如下的HotSpot VM命令参数下的。
[html] view plaincopy
  1. -Xms6144m -Xmx6144m -Xmn2048m -XX:PermSize=96m -XX:MaxPermSize=96m -XX:+UserParallelOldGC
上图显示了MinorGC平均的消耗时间是0.05秒，平均的频率是2.147秒1次。当计算MinorGC的消耗时间和频率的时候，越多的数据参与计算，准确性会越高。并且应用要处于稳定运行状态下来收集MinorGC信息也是非常重要的。
下一步是比较MinorGC的平均时间和系统对延迟的要求，如果MinorGC的平均时间大于了系统的要求，减少young代的空间大小，然后继续测试，再收集数据以及重新评估。
如果MinorGC的频率大于了系统的要求，就增加young代的空间大小，然后继续测试，再收集以及重新评估。
也许需要数次重复才能够让系统达到延迟要求。当你改变young代的空间大小的时候，尽量保持old代的空间大小不要改变。
从上图的垃圾回收信息来看，如果应用的延迟要求是40毫秒的话，观察到的MinorGC的延迟是58毫秒，比系统的要求高出了不少。上面例子使用的命令选项是
[html] view plaincopy
  1. -Xms6144m -Xmx6144m -Xmn2048m -XX:PermSize=96m -XX:MaxPermSize=96m -XX:+UserParallelOldGC
意味着old代的空间大小是4096M，减小young代的空间大小的10%而且要保持old代的空间大小不变，可以使用如下选项。
[html] view plaincopy
  1. -Xms5940m -Xmx5940m -Xmn1844m -XX:PermSize=96 -XX:MaxPermSize=96 -XX:+UserParallelOldGC
注意的是young代的空间大小从2048M减少到1844M，整个Java堆的大小从6144M减少到5940M，两者都是减少了204m。
无论是young的空间调大还是调小，都需要重新收集垃圾回收信息和重新计算MinorGC的平均时间和频率，以达到应用的延迟要求，可能需要几个轮回来达到这个要求。
为了说明了增加young代的大小以降低MinorGC的频率，我们下面举一个例子。如果系统要求的频率是5秒一次，这个上面的例子中是2.147秒一次，也就是说它用了2.147秒，填充满了2048M空间，如果需要5秒一次的频率，那么就需要5/2.147倍的空间，即2048*5/2.147等于4700M。因此young代的空间需要调整到4700M。下面是一个示例来说明配置这个：
[html] view plaincopy
  1. -Xms8796m -Xmx8796m -Xmn4700m -XX:PermSize=96m -XX:MaxPermSize=96m -XX:+UsePrallelOldGC
注意是-Xms和-Xmx也同步调整了。
另外一些调整young代的空间需要注意的事项：
1、old代的空间一定不能小于活动对象的大小的1.5倍。
2、young代的空间至少要有Java堆大小的10%，太小的Java空间会导致过于频繁的MinorGC。
3、当提高Java堆大小的时候，不要超过JVM可以使用的物理内存大小。如果使用过多的物理内存，会导致使用交换区，这个会严重影响性能。
如果在仅仅是MinorGC导致了延迟的情况下，你无法通过调整young代的空间来满足系统的需求，那么你需要重 新修改应用程序、修改JVM部署模型把应用部署到多个JVM上面（通常得要多机器了）或者重新评估系统的需求。
如果通过调整MinorGC能够满足应用的延迟需求，接下来就可以调整old代了，以达到最坏情况下的延迟和延迟频率的需求。下一节详细说明这个问题。
完善old代的大小
这一节的目标是评估由于FullGC引起的最差暂停时间和频率。
同前面一个节“完善young代大小”一样，垃圾回收的统计信息是必须的，在稳定状态下，FullGC的时间表明了应用最差的延迟，如果发生了多个FullGC，计算多个FullGC的平均消耗时间，更多数据能够更好的评估。
计算两次不同的FullGC之间的时间差，可以提供出FullGC的频率，下图用一个列子来说明两个FullGC：
   
如果没有FullGC，可以人为的去干预，前面说过，可以使用VisualVM来触发FullGC。另外，评估FullGC的频率需要知道对象的转移率，这个转移率说明对象从young代转移到old代。接下来的介绍如何评估转移率。
接下有个几个MinorGC的例子，他们被用来评估FullGC的频率。
[html] view plaincopy
  1. 2010-12-05T14:40:29.564-0800: [GC
  2. [PSYoungGen: 2045989K->249795K(2097152K)]
  3. 3634533K->1838430K(6291456K), 0.0543798 secs]
  4. [Times: user=0.38 sys=0.01, real=0.05 secs]
[html] view plaincopy
  1. 2010-12-05T14:40:31.949-0800: [GC
  2. [PSYoungGen: 2047896K->247788K(2097152K)]
  3. 3655319K->1859216K(6291456K), 0.0539614 secs]
  4. [Times: user=0.35 sys=0.01, real=0.05 secs]
[html] view plaincopy
  1. 2010-12-05T14:40:34.346-0800 [GC
  2. [PSYoungGen: 2045889K->248993K(2097152K)]
  3. 3677202K->1881099K(6291456K), 0.0532377 secs]
  4. [Times: user=0.39 sys=0.01, real=0.05 secs]
[html] view plaincopy
  1. 2010-12-05T14:40:36.815-0800 [GC
  2. [PSYoungGen: 2047094K->247765K(2097152K)]
  3. 3696985K->1900882K(6291456K), 0.0543332 secs]
  4. [Times: user=0.37 sys=0.01, real=0.05 secs]
从上面的例子可以看出：
1、Java堆的大小是6291456K或6144M
2、young代的大小是2097152K或2048M
3、old代的大小是6144M-2048M = 4096M
在这个例子中，活动对象的大小差不多是1370M。那么old代还有2726M剩余空间（4096M-1370M=2726M）。
填充完成2736M空间需要多长时间是由young代向old代的转移率决定的。这个转移率的计算通过查看每次MinorGC后old代的占用空间的增长情况以及MinorGC发生的时间。old代的空间占用是MinorGC之后Java堆中对象大小减去young代的大小，通过这个公式计算，可以看出在这个例子中每次MinorGC之后，old代的空间占用情况是：
1588635K，第一个MinorGC
1611428K，第二次MinorGC
1632106K，第三次MinorGC
1653117K，第四次MinorGC
每次的增量分别是
22793K，第一次和第二次的增量
20678K，第二次和第三次的增量
21011K，第三次和第四次的增量
平均每次MinorGC转移大概201494K或者叫21M。
如果剩余的空间都是按照设个转移率来转移到old代的话，且知道MinorGC的频率是每2.147秒一次。因此，这个转移率是201494K/2.147s差不多10M/s,那么一共的空间是2736M空间需要273.6s差不多4.5分钟一次。
因此，通过前面的案例分析，应用的最差延迟的频率是4.5分钟。这个评估可以通过让应用处于稳定运行状态超过4.5分钟来验证。
如果评估和观察的FullGC的频率高于了应用对最坏延迟频率的要求，那么可以提高old代的空间大小。如果改变old代的大小，保持young代的空间恒定，在优化young代的时候也说这个问题，两者应该独立优化，以保证有高效。
如果这步已经达到了你最坏延迟的要求，那么这一步调优延迟就算已经完成了，就可以进入下一步去调优“吞吐量”了。
如果你未能达到了应用对最坏延迟时间和频率的性能要求，由于FullGC的执行时间太长了，然后你可以把垃圾回收器切换CMS（concurrent garbage collection）。CMS有能力让垃圾回收尽量是多线程的，即让程序保持在运行状态。要使用CMS可以通过下面这条命令选项:-XX:+UseConcMarkSweepGC。
后面详细说明如何调优CMS。

转载于:https://www.cnblogs.com/bendantuohai/p/4734347.html

一步步优化JVM五：优化延迟或者响应时间(1)相关推荐

  1. 性能优化专题 - JVM 性能优化 - 04 - GC算法与调优

    目录导航 前言 Garbage Collect(垃圾回收) 如何确定一个对象是垃圾? 引用计数法 可达性分析 垃圾收集算法 标记-清除(Mark-Sweep) 复制(Copying) 标记-整理(Ma ...

  2. 一步步优化JVM六：优化吞吐量[转]

    2019独角兽企业重金招聘Python工程师标准>>> 原文:http://ganlv.iteye.com/blog/1571315 参考:http://www.myexceptio ...

  3. 第七篇：双管齐下，JVM内部优化与JVM性能调优

    文章目录 一.前言 二.编译时优化 2.1 Javac编译器 2.2 Java语法糖 2.2.1 泛型和泛型擦除 2.2.2 自动装箱.自动拆箱.遍历循环 2.2.3 条件编译 三.运行时优化(核心: ...

  4. JVM性能优化（一）

    作者 Eva Andreasson Java应用程序是运行在JVM上的,但是你对JVM技术了解吗?这篇文章(这个系列的第一部分)讲述了经典Java虚拟机是怎么样工作的,例如:Java一次编写的利弊,跨 ...

  5. 【JVM】优化参数+优化工具

    [JVM]优化参数+优化工具 (一)上线前评估的时候JVM设置合适的参数 [1]JVM参数 [2]典型JVM参数配置参考 [3]内存结构分析 (二)什么时候需要JVM调优?具体的指标? [1]如果使用 ...

  6. Kafka如何在千万级别时优化JVM GC问题？

    点击上方蓝色"程序猿DD",选择"设为星标" 回复"资源"获取独家整理的学习资料! 来源 | https://www.toutiao.com ...

  7. 面试官问：上亿数据量下，Kafka是如何优化JVM GC问题的？

    大家都知道Kafka是一个高吞吐的消息队列,是大数据场景首选的消息队列,这种场景就意味着发送单位时间消息的量会特别的大,那既然如此巨大的数据量,kafka是如何支撑起如此庞大的数据量的分发的呢? 今天 ...

  8. 45.JVM调优策略、常见问题：内存泄漏(年老代堆空间被占满、持久代被占满、堆栈溢出、线程堆栈满、系统内存被占满)优化方法：优化目标、优化GC步骤、优化总结；案例分析（公司系统参数、网上给的配置参数）

    45.JVM调优策略 45.1.常见问题 45.1.1.内存泄漏 45.1.1.1.年老代堆空间被占满 45.1.1.2.持久代被占满 45.1.1.3.堆栈溢出 45.1.1.4.线程堆栈满 45. ...

  9. 【Java架构师】JVM性能优化（一）JVM技术入门下

    JVM性能和"一次编译,到处运行"的挑战 我有新的消息告诉那些固执的认为Java平台本质上是缓慢的人.当Java刚刚做为企业级应用的时候,JVM被诟病的Java性能问题已经是十几年 ...

最新文章

  1. 实现多种方式对MYSQL进行备份
  2. Jmeter之控制线程执行到某个结果时退出执行（第二种解决方案）
  3. Fabric--CA 应用与配置
  4. sql server2008中怎样用sql语句创建数据库和数据表
  5. 如何在 C# 中使用 MSMQ
  6. Spring Boot2 集成 jasypt 3.0.4 配置文件敏感信息加密
  7. 生成jni的android.mk,Android Studio 3.5版本JNI生成SO文件详解
  8. linux模板机配置文件,制作Centos 7.4操作系统模板机
  9. k8s学习 ： 前端是如何连接到后端数据库的？
  10. MSDN 精简版 1.6
  11. web安全：X老师上课讲了Robots协议，小宁同学却上课打了瞌睡，赶紧来教教小宁Robots协议是什么吧
  12. note_10：surface laptop2遇到的问题和解决方案
  13. 网页里面的空格的代码怎么写
  14. 常用JSON工具类JsonUtil封装
  15. ADI Blackfin DSP处理器-BF533的开发详解59：DSP控制ADXL345三轴加速度传感器的应用2（含源码）
  16. [开源精品] C#.NET im 聊天通讯架构设计 -- FreeIM 支持集群、职责分明、高性能
  17. FFA-Net: Feature Fusion Attention Network for Single Image Dehazing
  18. Google Earth Engine(GEE)——全球影像数据正确下载方式和注意事项
  19. 武田通过与Moderna和日本政府合作，在日本扩大COVID-19疫苗供货
  20. 高等数学-学习笔记-汤讲义

热门文章

  1. 【转】Jquery -Ajax 入门练习 Jquery.Ajax 调用后台函数，获取DataTable Json,Asp.net
  2. httpclient通过POST来上传文件，而不是通过流的形式，并在服务端进行解析(通过htt......
  3. XML Schema用法
  4. Verilog中for语句的使用
  5. 深入浅出解释FFT（四）——fft分析信号频率和相位
  6. 将声音转为图片（二维矩阵）
  7. Joomla 2.5 中文语言包安装模板报错
  8. SharpWebMail介绍和安装(转)
  9. Python排序dict之list数组
  10. VM虚拟机的配置文件(.vmx)损坏修复