2019-12-23 14:36:01 佚名

Zeng-Liping

很多同学觉得JVM调优就是简单调整几个JVM内存几个参数，我认为这个观点是非常片面的。JVM调优有很多门槛，不只是修改几个参数那个简单。

其实我想回答如何进行JVM调优，但是可能和题主的问题稍微有些出入。但是我想通过我对JVM的理解帮助到更多这方面知识欠缺的童鞋。

关注必回！

我认为JVM调优可以从以下几个方面考虑：

对JVM内存模型有一定认识是能够对JVM调优的基本门槛，下面我简单介绍一下jvm内存模型，对这部分知识还有不明确的可以阅读我jvm详解的文章。

jvm内存可以简单分为堆，栈和元空间。题主的调优主要针对堆内存，当然也有栈。但是前者居多。
jvm的精明之处！垃圾回收机制，jvm根据内存使用情况，根据引用计数法和根目录遍历的方式结合age对堆内对象的生命周期进行管理，当然因为一个对象的创建在堆栈中都分配内存空间(引用在栈中，对象本身在堆中)，所以垃圾回收机制对堆和栈都效果！
分代垃圾回收机制，通过分代更合理的掌控对象的生命周期。
根据业务需要合理的进行GC以达到最优内存使用率。

分析JVM内存的增长因子，快速定位大块老赖对象

如果在程序运行期间，内存突然上升，并且在一定时间没有下降趋势，那么说明，有一大波对象逃过了垃圾回收，我们都知道，新生代垃圾回收是频繁的，但是新生代内存空间有限，内存持续上升，说明大部分对象已经进入老年带，根据引用计数和不可达算法，快速定位问题，留意近期的哪些改动会产生大量持续被引用对象，或者仅仅是持续产生大量对象，因为gc往往是阻塞的，短时间内gc掉大量对象对应用程序也会造成伤害，倒置线程长时间等待以致假死。

在这个时候猜测往往是效率最高的解决方案！大胆的预测问题并去验证它。如果猜测短时间内没有定位问题，那么通过top命令查找线程一步一步的找吧，也很快的，因为手机码字，这块儿就不细说了，有不清楚的私信！

JAVA虚拟机启动过程监控。

一个项目启动是JVM会将用到的类文件加载进内存，加载所有配置，加载所有bean对象。在这个过程中内存是不断增加的，可以通过jvm-

monitor.sh

。想了解JVM虚拟机启动的可以先看看自己公司项目的启动日志，可窥一二。

脚本进行内存监控，具体脚本内容比较冗长，在问答中不便贴出来了，有需要的童鞋直接私信我。

调整JVM堆栈内存分配大小，合理规避业务中内存溢出等问题

理论不多说，直接给出结论：

堆内存中，老年代：新生代比例=2:1；
新生代中，Eden：SurvivorA：SurvivorB=8:1:1；
-Xms:初始化堆大小；Xmx：最大堆大小；
-XX：NewSize=x，设置年轻代大小；-XX NewRatio=x 年轻代和老年代比例。

JVM调优工具的使用，快速定位内存问题利器

遇到

1、java.lang.OutOfMemoryError: PermGen space

2、java.lang.OutOfMemoryError: Java heap space 两种异常，通过大胆猜测未能解决问题的，可以通过LInux命令查找到问题代码块。常用命令简单整理如下（需要实战的可以私信我）：

top，通过top命令，快速定位占用内存较大的java进程。
jmap -histo:live [pid] ，查看当前java进程中活跃对象的数目和占用内存大小。
jmap -dump:live,format=b,file=xxx.xxx [pid] 导出指定pid的java进程的内存占用情况，以便通过内存分析工具进行分析，具体的内存分析工具包括HeapSnapShot、HeapViewer、MAT等。门槛都不高，能够帮助我们快速定位出问题症结。
java本身也提供好几款内存监控分析插件，位于jdk的bin目录下：具体使用方法本人多年前在csdn上有文章详解，这里不允许贴链接，也就不多说了。

本人从事软件工作多年，一路走来也不断积累不断学习，整理了一些java开发相关的资料，也包含JVM调优，需要的可以在下方留言或者留下邮箱（不是圈粉，所以可以不用关注）。

我是狂客说技术，总想着把自己掌握的东西整理一下分享出来，怎奈时间有限，可能文中也有不当的地方，欢迎大家指出，也欢迎大家点我关注。

狂客说技术

JVM性能调优涉及到方方面面的取舍，往往是牵一发而动全身，需要全盘考虑各方面的影响。但也有一些基础的理论和原则，理解这些理论并遵循这些原则会让你的性能调优任务将会更加轻松。为了更好的理解本篇所介绍的内容。你需要已经了解和遵循以下内容:

1、已了解jvm 垃圾收集器2、已了解jvm 性能监控常用工具3、能够读懂gc日志4、确信不为了调优而调优，jvm调优不能解决一切性能问题

如果对这些不了解不建议读本篇文章。

本篇文章基于jvm性能调优，结合jvm的各项参数对应用程序调优，主要内容有以下几个方面：

1、jvm调优的一般流程2、jvm调优所要关注的几个性能指标3、jvm调优需要掌握的一些原则4、调优策略&示例

一、性能调优的层次

为了提升系统性能，我们需要对系统的各个角度和层次来进行优化，以下是需要优化的几个层次。

从上面我们可以看到，除了jvm调优以外，还有其他几个层面需要来处理，所以针对系统的调优不是只有jvm调优一项，而是需要针对系统来整体调优，才能提升系统的性能。本篇只针对jvm调优来讲解，其他几个方面，后续再介绍。

在进行jvm调优之前，我们假设项目的架构调优和代码调优已经进行过或者是针对当前项目是最优的。这两个是jvm调优的基础，并且架构调优是对系统影响最大的，我们不能指望一个系统架构有缺陷或者代码层次优化没有穷尽的应用，通过jvm调优令其达到一个质的飞跃，这是不可能的。

另外，在调优之前，必须得有明确的性能优化目标，然后找到其性能瓶颈。之后针对瓶颈的优化，还需要对应用进行压力和基准测试，通过各种监控和统计工具，确认调优后的应用是否已经达到相关目标。

二、jvm调优流程

调优的最终目的都是为了令应用程序使用最小的硬件消耗来承载更大的吞吐。jvm的调优也不例外，jvm调优主要是针对垃圾收集器的收集性能优化，令运行在虚拟机上的应用能够使用更少的内存以及延迟获取更大的吞吐量。当然这里的最少是最优的选择，而不是越少越好。

1、性能定义

要查找和评估器性能瓶颈，首先要知道性能定义，对于jvm调优来说，我们需要知道以下三个定义属性，依作为评估基础:

吞吐量：重要指标之一，是指不考虑垃圾收集引起的停顿时间或内存消耗，垃圾收集器能支撑应用达到的最高性能指标。
延迟：其度量标准是缩短由于垃圾啊收集引起的停顿时间或者完全消除因垃圾收集所引起的停顿，避免应用运行时发生抖动。
内存占用：垃圾收集器流畅运行所需要的内存数量。

这三个属性中，其中一个任何一个属性性能的提高，几乎都是以另外一个或者两个属性性能的损失作代价，不可兼得，具体某一个属性或者两个属性的性能对应用来说比较重要，要基于应用的业务需求来确定。

2、性能调优原则

在调优过程中，我们应该谨记以下3个原则，以便帮助我们更轻松的完成垃圾收集的调优，从而达到应用程序的性能要求。

1. MinorGC回收原则：每次minor GC 都要尽可能多的收集垃圾对象。以减少应用程序发生Full GC的频率。2. GC内存最大化原则：处理吞吐量和延迟问题时候，垃圾处理器能使用的内存越大，垃圾收集的效果越好，应用程序也会越来越流畅。3. GC调优3选2原则: 在性能属性里面，吞吐量、延迟、内存占用，我们只能选择其中两个进行调优，不可三者兼得。

3、性能调优流程

以上就是对应用程序进行jvm调优的基本流程，我们可以看到，jvm调优是根据性能测试结果不断优化配置而多次迭代的过程。在达到每一个系统需求指标之前，之前的每个步骤都有可能经历多次迭代。有时候为了达到某一方面的指标，有可能需要对之前的参数进行多次调整，进而需要把之前的所有步骤重新测试一遍。

另外调优一般是从满足程序的内存使用需求开始的，之后是时间延迟的要求，最后才是吞吐量的要求，要基于这个步骤来不断优化，每一个步骤都是进行下一步的基础，不可逆行之。以下我们针对每个步骤进行详细的示例讲解。

在JVM的运行模式方面，我们直接选择server模式，这也是jdk1.6以后官方推荐的模式。

在垃圾收集器方面，我们直接采用了jdk1.6-1.8 中默认的parallel收集器（新生代采用parallelGC,老生代采用parallelOldGC）。

三、确定内存占用

在确定内存占用之前，我们需要知道两个知识点：

应用程序的运行阶段
jvm内存分配

1、运行阶段

应用程序的运行阶段，我可以划分为以下三个阶段:

1、初始化阶段 : jvm加载应用程序，初始化应用程序的主要模块和数据。2、稳定阶段:应用在此时运行了大多数时间，经历过压力测试的之后，各项性能参数呈稳定状态。核心函数被执行，已经被jit编译预热过。3、总结阶段:最后的总结阶段，进行一些基准测试，生成响应的策报告。这个阶段我们可以不关注。

确定内存占用以及活跃数据的大小，我们应该是在程序的稳定阶段来进行确定，而不是在项目起初阶段来进行确定，如何确定，我们先看以下jvm的内存分配。

2、jvm内存分配&参数

jvm堆中主要的空间，就是以上新生代、老生代、永久代组成,整个堆大小=新生代大小 + 老生代大小 + 永久代大小。具体的对象提升方式，这里不再过多介绍了，我们看下一些jvm命令参数，对堆大小的指定。如果不采用以下参数进行指定的话，虚拟机会自动选择合适的值，同时也会基于系统的开销自动调整。

在设置的时候，如果关注性能开销的话，应尽量把永久代的初始值与最大值设置为同一值，因为永久代的大小调整需要进行FullGC 才能实现。

3、计算活跃数据大小

计算活跃数据大小应该遵循以下流程:

如前所述，活跃数据应该是基于应用程序稳定阶段时，观察长期存活与对象在java堆中占用的空间大小。

计算活跃数据时应该确保以下条件发生：

1.测试时，启动参数采用jvm默认参数，不人为设置。2.确保Full GC 发生时，应用程序正处于稳定阶段。

采用jvm默认参数启动，是为了观察应用程序在稳定阶段的所需要的内存使用。

如何才算稳定阶段？

一定得需要产生足够的压力，找到应用程序和生产环境高峰符合状态类似的负荷，在此之后达到峰值之后，保持一个稳定的状态，才算是一个稳定阶段。所以要达到稳定阶段，压力测试是必不可少的，具体如何如何对应用压力测试，本篇不过多说明,后期会有专门介绍的篇幅。

在确定了应用出于稳定阶段的时候，要注意观察应用的GC日志，特别是Full GC 日志。

GC日志指令: -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:<filename>GC日志是收集调优所需信息的最好途径，即便是在生产环境，也可以开启GC日志来定位问题，开启GC日志对性能的影响极小，却可以提供丰富数据。/<filename>

必须得有FullGC 日志，如果没有的话，可以采用监控工具强制调用一次，或者采用以下命令，亦可以触发

jmap -histo:live pid

在稳定阶段触发了FullGC我们一般会拿到如下信息:

从以上gc日志中，我们大概可以分析到，在发生fullGC之时，整个应用的堆占用以及GC时间，当然了，为了更加精确，应该多收集几次，获取一个平均值。或者是采用耗时最长的一次FullGC来进行估算。

在上图中，fullGC之后，老年代空间占用在93168kb（约93MB），我们以此定为老年代空间的活跃数据。

其他堆空间的分配，基于以下规则来进行。

基于以上规则和上图中的FullGC信息，我们现在可以规划的该应用堆空间为：

java 堆空间: 373Mb (=老年代空间93168kb*4)新生代空间:140Mb(=老年代空间93168kb*1.5)永久代空间:5Mb(=永久代空间3135kb*1.5)老年代空间: 233Mb=堆空间-新生代看空间=373Mb-140Mb

对应的应用启动参数应该为:

四、延迟调优

在确定了应用程序的活跃数据大小之后，我们需要再进行延迟性调优，因为对于此时堆内存大小，延迟性需求无法达到应用的需要，需要基于应用的情况来进行调试。

在这一步进行期间，我们可能会再次优化堆大小的配置，评估GC的持续时间和频率、以及是否需要切换到不同的垃圾收集器上。

1、系统延迟需求

在调优之前，我们需要知道系统的延迟需求是那些，以及对应的延迟可调优指标是那些。

应用程序可接受的平均停滞时间: 此时间与测量的Minor GC持续时间进行比较。
可接受的Minor GC频率：Minor GC的频率与可容忍的值进行比较。
可接受的最大停顿时间: 最大停顿时间与最差情况下FullGC的持续时间进行比较。
可接受的最大停顿发生的频率：基本就是FullGC的频率。

以上中，平均停滞时间和最大停顿时间，对用户体验最为重要，可以多关注。

基于以上的要求，我们需要统计以下数据:

MinorGC的持续时间；

统计MinorGC的次数；
FullGC的最差持续时间；
最差情况下，FullGC的频率；

2、优化新生代的大小

比如如上的gc日志中，我们可以看到Minor GC的平均持续时间=0.069秒，MinorGC 的频率为0.389秒一次。

如果，我们系统的设置的平均停滞时间为50ms，当前的69ms明显是太长了，就需要调整。我们知道新生代空间越大，Minor GC的GC时间越长，频率越低。如果想减少其持续时长，就需要减少其空间大小。如果想减小其频率，就需要加大其空间大小。

为了降低改变新生代的大小对其他区域的最小影响。在改变新生代空间大小的时候，尽量保持老年代空间的大小。

比如此次减少了新生代空间10%的大小，应该保持老年代和持代的大小不变化，第一步调优后的参数如下变化:

3、优化老年代的大小

同上一步一样，在优化之前，也需要采集gc日志的数据。此次我们关注的是FullGC的持续时间和频率。

上图中，我们可以看到

如果没有FullGC的日志，有办法可以评估么？

我们可以通过对象提升率进行计算。

对象提升率

比如上述中启动参数中，我们的老年代大小=233Mb。

那么需要多久才能填满老年代中这233Mb的空闲空间取决于新生代到老年代的提升率。

每次提升老年代占用量=每次MinorGC 之后 java堆占用情况减去 MinorGC后新生代的空间占用对象提升率=平均值（每次提升老年代占用量) 除以老年代空间

有了对象提升率，我们就可以算出填充满老年代空间需要多少次minorGC，大概一次fullGC的时间就可以计算出来了。

比如:

上图中:

老年代每次minorGC提升率

我们可以测算出：

FullGC的预期最差频率时长可以通过以上两种方式估算出来，可以调整老年代的大小来调整FullGC的频率，当然了，如果FullGC持续时间过长，无法达到应用程序的最差延迟要求，就需要切换垃圾处理器了。具体如何切换，下篇再讲，比如切换为CMS，针对CMS的调优方式又有会细微的差别。

五、吞吐量调优

经过上述漫长调优过程，最终来到了调优的最后一步，这一步对上述的结果进行吞吐量测试，并进行微调。

吞吐量调优主要是基于应用程序的吞吐量要求而来的，应用程序应该有一个综合的吞吐指标，这个指标基于真个应用的需求和测试而衍生出来的。当有应用程序的吞吐量达到或者超过预期的吞吐目标，整个调优过程就可以圆满结束了。

如果出现调优后依然无法达到应用程序的吞吐目标，需要重新回顾吞吐要求，评估当前吞吐量和目标差距是否巨大，如果在20%左右，可以修改参数，加大内存，再次从头调试，如果巨大就需要从整个应用层面来考虑，设计以及目标是否一致了，重新评估吞吐目标。

对于垃圾收集器来说，提升吞吐量的性能调优的目标就是就是尽可能避免或者很少发生FullGC 或者Stop-The-World压缩式垃圾收集（CMS），因为这两种方式都会造成应用程序吞吐降低。尽量在MinorGC 阶段回收更多的对象，避免对象提升过快到老年代。

六、最后

欢迎大家关注我的主页，作为一名架构师，我每天都会分享一些有关Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化这些成为架构师必备的知识体系。

点击我的头条，私信【java】还可以领取免费的学习资源和前辈的面试经验和面试题，相信对于已经工作或遇到技术瓶颈的码友，会有你需要的内容。

据Plumbr公司对特定垃圾收集器使用情况进行了一次调查研究，研究数据使用了84936个案例。在明确指定垃圾收集器的13%的案例中，并发收集器（CMS）使用次数最多；但大多数案例没有选择最佳垃圾收集器。这个比例占用在87%左右。

JVM调优是一个系统而又复杂的工作，目前jvm下的自动调整已经做的比较优秀，基本的一些初始参数都可以保证一般的应用跑的比较稳定了，对部分团队来说，程序性能可能优先级不高，默认垃圾收集器已经够用了。调优要基于自己的情况而来。

Java高并发框架

首先，所有的调优或优化都要有一个目的指标，也就是现在是什么样，要达到什么样，不能为了调优而调优！

其次，在有目标指标参数后，可以通过一些命令如jstat、jinfo等查看一些参数及JVM信息，确认这些配置参数后，可以获取JVM的堆转储快照文件，即dump文件，通过编辑器查看分析日志信息或一些可视化工具来分析性能的瓶颈，通过分析得出一些可能需要调整的参数，如堆大小、垃圾收集器参数，调整这么参数，观察运行情况，或再次分析dump文件。

希望对你有所帮助！

Java实战技术

堆大小设置

JVM 中最大堆大小有三方面限制：相关操作系统的数据模型（32-bt还是64-bit）限制；系统的可用虚拟内存限制；系统的可用物理内存限制。32位系统下，一般限制在1.5G~2G；64为操作系统对内存无限制。我在Windows Server 2003 系统，3.5G物理内存，JDK5.0下测试，最大可设置为1478m。