如何合理估算主机配置需求( 五 ) _内存

GC的日志的输出也很重要：
-Xloggc:/dev/xxx/gc.log -XX:+PrintGCDateStamps -XX:+PrintGCDetails
GC的日志实际上对系统性能影响不大，打日志对排查GC问题很重要。
一份通用的JVM参数模板一般来说，大企业或者架构师团队，都会为项目的业务系统定制一份较为通用的JVM参数模板，但是许多小企业和团队可能就疏于这一块的设计，如果老板某一天突然让你负责定制一个新系统的JVM参数，你上网去搜大量的JVM调优文章或博客，结果发现都是零零散散的、不成体系的JVM参数讲解，根本下不了手，这个时候你就需要一份较为通用的JVM参数模板了，不能保证性能最佳，但是至少能让JVM这一层是稳定可控的，
在这里给大家总结了一份模板：
基于4C8G系统的+CMS回收器模板（响应优先），新生代大小根据业务灵活调整！
-Xms4g-Xmx4g-Xmn2g-Xss1m-XX:SurvivorRatio=8-XX:MaxTenuringThreshold=10-XX:+UseConcMarkSweepGC-XX:CMSInitiatingOccupancyFraction=70-XX:+UseCMSInitiatingOccupancyOnly-XX:+AlwaysPreTouch-XX:+HeapDumpOnOutOfMemoryError-verbose:gc-XX:+PrintGCDetails-XX:+PrintGCDateStamps-XX:+PrintGCTimeStamps-Xloggc:gc.log
如果是GC的吞吐优先，推荐使用G1，基于8C16G系统的G1回收器模板：
G1收集器自身已经有一套预测和调整机制了，因此我们首先的选择是相信它，
即调整-XX:=N参数，这也符合G1的目的——让GC调优尽量简单！
同时也不要自己显式设置新生代的大小（用-Xmn或-XX:参数），
如果人为干预新生代的大小，会导致目标时间这个参数失效。
-Xms8g-Xmx8g-Xss1m-XX:+UseG1GC-XX:MaxGCPauseMillis=150-XX:InitiatingHeapOccupancyPercent=40-XX:+HeapDumpOnOutOfMemoryError-verbose:gc-XX:+PrintGCDetails-XX:+PrintGCDateStamps-XX:+PrintGCTimeStamps-Xloggc:gc.log
G1参数
描述
默认值
XX:=N
最大GC停顿时间。柔性目标，JVM满足90%，不保证100% 。
200
-XX:=n
当整个堆的空间使用百分比超过这个值时，就会融发MixGC
45
针对-XX:来说，参数的设置带有明显的倾向性：调低↓：延迟更低，但频繁，MixGC回收老年代区减少，增大Full GC的风险。调高↑：单次回收更多的对象，但系统整体响应时间也会被拉长。
针对来说，调参大小的效果也不一样：调低↓：更早触发MixGC，浪费cpu 。调高↑：堆积过多代回收，增大的风险。
调优总结
系统在上线前的综合调优思路：
1、业务预估：根据预期的并发量、平均每个任务的内存需求大小，然后评估需要几台机器来承载，每台机器需要什么样的配置。
2、容量预估：根据系统的任务处理速度，然后合理分配Eden、区大小，老年代的内存大小。
3、回收器选型：响应优先的系统，建议采用+CMS回收器；吞吐优先、多核大内存(heap size≥8G)服务，建议采用G1回收器。
4、优化思路：让短命对象在阶段就被回收（同时回收后的存活对象
5、到目前为止，总结到的调优的过程主要基于上线前的测试验证阶段，所以我们尽量在上线之前，就将机器的JVM参数设置到最优！
JVM调优只是一个手段，但并不一定所有问题都可以通过JVM进行调优解决，大多数的Java应用不需要进行JVM优化，我们可以遵循以下的一些原则：
通过以上原则，我们发现，其实最有效的优化手段是架构和代码层面的优化，而JVM优化则是最后不得已的手段，也可以说是对服务器配置的最后一次“压榨” 。
什么是ZGC？
ZGC （Z）是一款由公司研发的，以低延迟为首要目标的一款垃圾收集器。