主JVM的理论基础在前一章“解释原JVM”中已经梳理过:Java程序运行在Java虚拟机上，JVM管理整个程序的内存分配和使用，负责对象的整个生命周期。 这部分内容是广大Java开发者所熟悉的，我在采访或者读者阅读博客的过程中也有过一些印象。但是，当我们转向实际项目时，比如核心的JVM参数有哪些，如何根据项目评估一套合适的JVM参数，项目上线后如何根据业务优化JVM配置，如何分析处理频繁的GC等实际问题，基本上是杂乱无章的。如果说大部分盲目上网找JVM优化的文章只说参数调优不基于后台，基本上盲人摸象抓不到关键问题的话，这篇文章是对JVM实战和优化的系统梳理，也是对最近整个学习和使用JVM的总结。首先是上一章的大纲图:实战调优思维导图一、JVM内存相关参数1。JVM内存参数的权衡首先，JVM最重要也是最核心的参数是评估内存和分配。第一步是指定堆内存的大小，这在系统联机时是必需的。-Xms初始堆大小，-Xmx最大堆大小，在后端Java服务中一般指定为系统内存的一半，会占用服务器的系统资源，太小则不能充分发挥JVM的最佳性能。 其次，你需要指定-Xmn new generation的大小。这个参数是非常关键和灵活的。虽然sun官方推荐3/8的大小，但这取决于业务场景。对于无状态或轻态服务(现在最常见的业务系统如Web应用)，一般来说，新一代甚至可以给出3/4的堆内存。对于有状态业务(如IM业务、网关接入层等系统)，新一代可以按照1/3的默认比例设置。 如果服务是有状态的，那就意味着会有更多的本地缓存和会话状态信息内存驻留，所以需要为老年设置更多的空间来存储这些对象。 最后设置-Xss堆栈的内存大小，设置单线程的堆栈大小。默认值与JDK版本和系统相关。一般默认值为512~1024kb。 如果一个后端服务有几百个常驻线程，那么堆栈内存也会占用几百m。 JVM内存参数2。如何设置JVM参数如果在IDEA中调试JVM参数，只需打开项目的配置，设置VM选项:IDEA调试JVM如果在Linux环境中调试JVM参数，需要启动Java进程。添加到启动命令:[root @ local ~]# Java-xmx 512m-xms 512m-xmn 256m-xss1m–jar hello . jar服务启动后，关于jvm参数的信息会打印在日志的第一行:可以验证启动后的jvm参数是否可以设置成功！2.新系统上线时如何规划容量？1.例行总结任何新的业务系统上线前都需要对JVM的服务器配置和内存参数进行估算。这个容量和资源规划不仅仅是系统架构师随便估算的，需要根据系统所处的业务场景进行估算，推导出系统运行模型，评估JVM性能和GC频率等指标。 下面是我结合大牛的经验和自己的实践总结出来的一个建模步骤:计算业务系统创建的对象每秒会占用多少内存空间，然后计算集群下各个系统每秒的内存空间(对象创建速度)。设置一个机器配置，估算新一代的空间，比较不同新一代尺寸下MinorGC触发的频率。 为了避免频繁的GC，我们可以重新估计需要多少台机器配置，部署多少台机器，给JVM多少内存空间，给新一代多少空间。 按照这样的配置，我们基本可以算出整个系统的运行模式，每秒钟有多少对象被创建，1s后变成垃圾。新一代系统运行多久会触发GC？ 2.套路练习——以登录系统为例。有些同学看到这些步骤还是觉得不好意思，说的也是同样的话。在实际项目中还是不知道怎么做！这么说吧，我们不练假法。这里我们以登录系统为例模拟推演过程:假设每天有100个登录请求，登录高峰在上午，预计高峰期为每秒100个登录请求。 假设部署了三台服务器，每台机器每秒解决30个登录请求。假设一个登录请求需要一秒钟解决，在新一代JVM中每秒钟会产生30个登录对象。一秒钟后，这些对象就会变成垃圾。 一个登录请求对象假设20个字段，一个对象估计500字节，30次登录占用大约15kb。考虑RPC和DB操作，一次操作可以将网络通信、库写入和缓存写入扩展到20-50次，1s左右可以生成数百个k-1M的数据。 假设部署2C4G机器，分配2G堆内存，新一代也就几百米。按照1s1M的垃圾生成速度，每几百秒就会触发一次MinorGC。 假设部署4C8G机器，分配4G堆内存，新一代分配2G，那么触发MinorGC需要几个小时。 这里大致可以推断，一个每天100w请求的登录系统，按照4C8G的三实例集群配置，分配4G堆内存和2G新一代JVM，就可以保证系统的一个正常负载。 基本上一个新系统的资源都已经评估过了，所以构建一个新系统需要多少容量，每个实例需要多少配置，一个集群配置多少个实例等等，都不是拍脑袋拍胸脯就能决定的。 三、垃圾收集器的选择1。吞吐量或响应时间首先介绍两个概念:吞吐量和低延迟吞吐量= CPU在客户端应用中的运行时间/(CPU在客户端应用中的运行时间+CPU的垃圾收集时间)响应时间=平均GC时间。通常，吞吐量优先级或响应优先级是JVM中的一个两难问题。 随着堆内存的增加，gc一次能解决的数量变大，吞吐量更大；但是gc一次的时间会比较长，导致后面队列中的线程等待时间比较长；相反，堆内存小的话，gc一次性短，排队等待的线程等待时间短，延迟降低，但一次性请求数少(不是绝对一致)。 是吞吐量优先还是响应优先，是一个需要权衡的问题。 2.垃圾收集器设计考虑事项JVM不允许在GC中同时收集垃圾和创建新对象(就像你不能同时清理和扔垃圾一样) JVM需要暂停时间来停止世界，STW会导致系统短暂暂停，无法解决任何请求；新一代采集频率高，性能第一，常用复制算法；老化频率低，空间敏感，避免复制模式。 所有垃圾收集器的目标都是降低GC的频率，缩短时间，减少GC对系统的影响！3.目前，CMS和G1的主流垃圾收集器配置是新一代的ParNew，旧时代的CMS组合，或者完全的G1垃圾收集器。从未来的趋势来看，G1是官方维护者和更受尊敬的垃圾收集者。 推迟敏感的推荐CMS根据业务系统；大型内存服务，需要高吞吐量，使用G1回收！下面分别说明两种回收器的工作机理和应用场景。CMS回收器1。CMS垃圾回收器CMS的工作机制主要是针对老的回收器，新一代采用新的回收器。工作流程就是上面说的经典复制算法，循环回收分三块进行，但是通过多线程加快了MinorGC的速度。 年龄总是被标记为清除的，默认情况下，排序算法将在FullGC算法清除内存碎片之后完成。 CMS优势:并发收集，关注“低延迟” STW没有发生在最耗时的两个阶段，需要STW的阶段都很快完成了。 缺点:1。CPU消费；2.漂浮垃圾；3.内存碎片化应用场景:注重服务器的响应速度，要求系统停顿时间最短。 2.登录系统的测试前配置和调优场景。以之前的登录系统为例，根据之前的容量估算例程，引入性能测试环节，测试1s内登录界面按到60M的对象的生成速度。假设只配置4C8G机器配置，采用ParNew+CMS的组合回收器，堆内存分配4g，默认线程栈1M。初始配置如下:-xms4g–xmx4g–xmn 1536m-xss1m-xx:+useconcmarkswepgc划分Eden和Surviror大小。例如，根据默认的分配规则-XX:SurvivorRatio=8，基于CMS的JVM运行模型大致计算如下:基于CMS的JVM运行模型基本上可以看出，Eden区域在20S后就会满，此时无法分配对象，会触发MinorGC。假设这次GC后S1加载了100M，20S后会再次触发MinorGC，S1地区多余的100M活对象+100M无法顺利放入S2地区，会触发JVM的动态年龄机制，将一批100M对象推到老年，并保持运行一段时间。 3.基于CMS的优化思路，首先采用增加生存区容量的策略:新生代规划2g，保持E:S1:S2=8:1:1，Eden=1.6G，S=200M。 60M/S的速率，25s触发MinorGC，收集的垃圾超过200M触发老年，大大降低了对象进入老年的概率，短命的对象在几次minorGC后被释放。 此时JVM配置如下:-xms4g–xmx4g–xmn2g-xss1m-xx:survivor ratio = 8-xx:+useconcmarksweepgc，然后降级晋升老年，默认为15——逃离minor GC 15次即可进入老年；值可以适当调低到5~10，让长寿对象尽快各就各位，而不是新生代折腾占空间，可以优化每个MinorGC的时间消耗。 -xms4g–xmx4g–xmn2g-xss1m-xx:survivor ratio = 8-xx:maxtenuringthreshold = 15-xx:+useconcmarksweepgc有选择地优化旧龄的参数:比如默认情况下旧龄会在标记清理后排序。还可以在CMS添加GC的频率或者持续时间上做一些权衡，以下是响应优先的参数调优:响应优先配置，那么最后我们可以得到一个更适合自己业务系统的，基于CMS回收器的JVM的参数:-xms4g–xmx4g–xmn2g-xss1m-XX:survivor ratio = 8-XX:maxtenuringthreshold = 5-XX:+useconcmmarksweepgc-XX:cmsintingoccupancyfracture = 70-XX:+use 1。CMS initiating occupation only-XX:+ALWAYSPRETOUCH v . G1垃圾收集器1。CMS collector的不足服务需要在启动前指定新世代和旧龄大小，启动后无法动态调整！无论是新一代还是老一代，都必须分配一个独立连续的整体内存空间！所有针对老年的操作都必须扫描整个老年空间，同样的老年对象，堆空间越大，扫描时间越长！2.G1回收商G1回收商的设计思想自然适合大型内存服务器。首先，G1将堆内存空间分割成多个大小相等的区域，默认情况下区域数量为2048。使用4g堆内存，每个区域的大小是2M。 区域动态地属于旧时代或新时代。一秒钟被分配给新时代。回收之后就变成空置了，下一秒可能就被划分到老年区了。 在G1回收器中不需要预先设定新生代和老纪的大小，但在新生代仍然区分伊甸园和幸存者区。 JVM参数的调优复杂度大大降低，只要配置-XX:MaxGCPauseMillis=n(ms)，设置最大GC暂停时间，剩下的交给G1回收器。 G1将自动跟踪每个可回收区域的大小和预计时间。最后，在真正的垃圾收集过程中，尽量把垃圾收集控制在设定的时间范围内，在有限的时间内回收更多的对象。 G1回收商模式，因此，从综合的角度来看，G1侧重于高吞吐量，尤其是多核和大内存服务(如Kafka/ElasticSearch)。 3.G1的工作机制:新生代回收:对象优先分配Eden的区域，JVM不断分配更多的区域给新生代，直到新生代占总堆大小的60%，触发MinorGC。 进入老年对象的条件不变:达到晋升年龄；动态年龄确定；大对象的混合回收:当陈年的区域占堆内存的45%时，触发MixGC，新生代和陈年的区域会分阶段重复回收。 当Full GC:MixGC发现没有新的区域块可用于分配复制的幸存对象时，立即触发Full GC，停止系统程序，在单线程中进行标记、清理和整理，释放一批区域。这个过程非常缓慢。 触发G1 GC 4的几次机会。G1收集器，G1的核心调优参数，已经有了一套预测和调整机制，所以我们的第一选择是相信它，也就是调整-XX:MaxGCPauseMillis=N参数，这也符合G1的目的——让GC调优尽量简单！同时，不要自己显式设置新生代的大小(用-Xmn或-XX:NewRatio参数)。如果人们干预新生代的大小，目标时间的这个参数就会失效。 G1参数描述对于-XX:MaxGCPauseMillis，参数的设置有一个显著的倾向:lower ↓: lower delay，但是MinorGC频繁，MixGC回收的老龄区减少，增加了满GC的风险。 Increase ↑:一次回收更多对象，但系统整体响应时间也会拉长。 对于initializingheapoccupancypercent来说，调整参数大小的效果也是不一样的:lower ↓:提前触发MixGC，浪费cpu。 增加↑:累积多代恢复区域，增加FullGC的风险。 5.5的应用。卡夫卡星团中的G1调谐。比如log平台的Kafka cluster每秒向内存写入300M数据，broker节点配置为16C32G，假设堆内存为16g，新一代分配8g，假设每秒生成对象约100M，那么差不多一分钟就会生成一次MinorGC。在CMS机制下，需要等到Eden满了之后才一次性清理掉8g左右的垃圾对象，会有一个秒级的STW暂停。 -xms16g–xmx 16g–xmn8g-xss1m-xx:+useconcmarksweepgc假设使用G1回收器，适当降低最大耗时，设置MaxGCPauseMillis为100ms，适当降低堆利用率阈值，G1会在允许的响应时间内自动、批量收集垃圾，保证每个STW的时间不会太长。 -xms16g-xmx 16g-xss1m-xx:+use 1 GC-xx:maxgcpausemillis = 100-xx:initiating heap upancypercent = 40，所以联机kafka和ES集群容易出现32~64g的大内存，如果要求CMS回收一整块十几个甚至几十个垃圾对象，对系统绝对不利。一般来说，对于8g堆内存以上的大内存服务器，更推荐G1回收器！不及物动词调谐摘要1。系统上线前的全面调优思路。业务预估:根据每个任务的预期并发量和平均内存需求，然后评估需要多少台机器来承载，每台机器需要什么样的配置。 容量估计:根据系统的任务速度，然后适当分配Eden，Surivior区域大小，以及老年的内存大小。 回收器选型:优先响应的系统推荐ParNew+CMS回收器；对于吞吐量优先、多核大内存(堆大小≥8G)服务，推荐使用G1回收器。 优化思路:让短寿命对象在MinorGC阶段回收(同时回收的存活对象<存活面积50%，可以控制保留在新生代)，长寿命对象要尽快进入老年，不要在新生代来回复制；尽量减少全GC的频率，避免FGC系统的影响。 到目前为止总结的调优过程主要是基于上线前的测试认证阶段，所以我们尽量在上线前将机器的JVM参数设置到最佳！2.通用JVM参数模板。一般来说，大型企业或者架构师团队会为项目的业务系统定制一个通用的JVM参数模板，但是很多小型企业和团队可能会忽略这一块的设计。如果有一天老板突然让你定制一个新系统的JVM参数，你可以在网上搜一大堆JVM调优的文章或者博客。结果是对JVM参数零散的、不系统的解释，你根本做不到。这时候你就需要一个通用的JVM参数模板，虽然不能保证最好的性能，但至少可以让JVM层稳定可控。我这里给大家总结了两个模板:par new+基于4C8G系统的CMS回收器模板(响应优先级)，新一代大小可以根据业务灵活调整！-Xms4g-Xmx4g-Xmn2g-Xss1m-XX:survivor ratio = 8-XX:MaxTenuringThreshold = 10-XX:+useconmarksweepgc-XX:CMS initiating occupancyfraction = 70-XX:+usecms initiating OccupancyOnly-XX:+AlwaysPreTouch-XX:+HeapDumpOnOutOfMemoryError-verbose:GC-XX:+printgc details-XX:+PrintGCDateStamps-XX:+printgcstimestamps-Xloggc:GC . log G1 在这篇文章的最后，我再多说几句。虽然本文的主题是JVM实战和调优，但是要知道JVM调优只是一种手段，并不能确定所有的问题都可以通过JVM调优。大部分Java应用不需要JVM调优，我们可以遵循以下几条准则:在上线之前，首先要考虑将机器的JVM参数设置到最优；减少创建对象的数量(代码级)；减少全局变量和大型对象(代码级)；优先进行架构调优和代码调优，JVM优化是最后手段(代码、架构层面)；分析GC的情况，优化代码，不如优化JVM参数(代码级)；通过以上标准我们发现，其实最有效的优化手段就是架构和代码层面的优化，JVM优化是最后一招，也可以说是服务器配置的最后“压榨”。 参考列表1。周志明，深入理解Java虚拟机，第3版，2。刘超，Java性能调优，3。极客时间，2。二哥丑胖子，4。消防队长，5.Orale.Java平台，标准版工具参考关注微信官方账号获取更多学习资料。