jvm配置模板(伪命题，但是必要）

为什么又是必要的

如果在一个初创公司（其实现在在哈啰也是这样的， 都是直接用发布系统提供的jvm参数模板）， 系统压力没那么大，大多数开发对 jvm 的调优并没有那么多经验， 这时候 新起一个服务 jvm怎么配置呢？copy 一下已有项目的jvm参数设置？ 让架构师或资深工程师凭经验来设置？

大多数人会无从下手，乱配 这个时候还不如有个 “比较通用”的，经过很多服务在线上检验的配置直接用来的稳妥，之后观察 gc情况针对性的来调优

怎么设置

现在互联网公司的机器配置 一般都是 4C8G 8C16G
服务的类型个人接触的比较多的是：
1. 业务处理类： 接口一串业务处理完就结束了 => 对象少、生命周期短 大多数的服务都属于此类
2. 数据查询类： redis缓存，有的并发比较高 会做本地缓存 => 生命周期长
3. 报表类： 一次查询一堆数据出来 => 对象多

对于“业务处理类” 服务，配置的目标是minor gc能回收掉大部分对象、不进入老年代 => 年轻代足够大、minor gc后存活对象不超过survivor区的 50%

观察过几个服务，minor gc后 还存活 几十到 100M左右的对象 => survivor 起码 300M 反推年轻代大小

参数配置

回收器选择

ParNew + CMS

4C 8G 机器堆比例

MEM_OPTS="-Xms5120m -Xmx5120m -Xmn1536m -XX:MaxMetaspaceSize=512m -XX:MetaspaceSize=512m"

8C 16G 机器堆比例

MEM_OPTS="-Xms7500m -Xmx7500m -Xmn3000m -Xss512k -XX:MaxMetaspaceSize=512m -XX:MetaspaceSize=512m"

其他通用配置

ENCODING_PARAM="-Dfile.encoding=UTF-8"

GC_OPTS="$GC_OPTS -XX:+UseConcMarkSweepGC 
-XX:+UseParNewGC 
-XX:+UseCMSCompactAtFullCollection 
-XX:CMSFullGCsBeforeCompaction=0 
-XX:CMSInitiatingOccupancyFraction=65     
-XX:CMSInitiatingOccupancyFraction=92    # 8G机器这个用这个
-XX:SurvivorRatio=8 
-XX:+UseCMSInitiatingOccupancyOnly
-XX:+CMSScavengeBeforeRemark       ## 在cms gc之前进行一次 minor gc 减少 remark的开销
-XX:+ParallelRefProcEnabled #并行处理 reference 加快final remak
-XX:+CMSClassUnloadingEnabled 
-XX:+DisableExplicitGC  ## 防止某些”大神“在代码里边执行 System.gc() 

-XX:+CMSParallelInitialMarkEnabled ## 初始标记 多线程并行   一般没必要，初始标记都很快
-XX:+ExplicitGCInvokesConcurrent 
-XX:ParallelGCThreads=$CPU_Count 
"

GC logging
GC_OPTS="$GC_OPTS -Xloggc:${PROJECT_DIR}/logs/gc.log"
GC_OPTS="$GC_OPTS -XX:+PrintGCDateStamps -XX:+PrintGCDetails"
GC_OPTS="$GC_OPTS -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${PROJECT_DIR}/logs/heapdump.hprof"

java $MEM_OPTS  $GC_OPTS   -jar  {jar包路径}