GC收集器ParNew&CMS
JVM内存模型
JVM参数设置
-Xss：每个线程的栈大小
-Xms：初始堆大小，默认物理内存的1/64
-Xmx：最大堆大小，默认物理内存的1/4
-Xmn：新生代大小
-XX:NewSize：设置新生代初始大小
-XX:NewRatio：默认2表示新生代占年老代的1/2，占整个堆内存的1/3。
-XX:SurvivorRatio：默认8表示一个survivor区占用1/8的Eden内存，即1/10的新生代内存。
关于元空间的JVM参数有两个：-XX:MetaspaceSize=N和 -XX:MaxMetaspaceSize=N
-XX：MaxMetaspaceSize： 设置元空间最大值， 默认是-1， 即不限制， 或者说只受限于本地内存大小。
-XX：MetaspaceSize： 指定元空间触发Fullgc的初始阈值(元空间无固定初始大小)， 以字节为单位，默认是21M，达到该值就会触发full gc进行类型卸载， 同时收集器会对该值进行调整： 如果释放了大量的空间， 就适当降低该值； 如果释放了很少的空间， 那么在不超过-XX：MaxMetaspaceSize（如果设置了的话） 的情况下， 适当提高该值。这个跟早期jdk版本的-XX:PermSize参数意思不一样，-XX:PermSize代表永久代的初始容量。
由于调整元空间的大小需要Full GC，这是非常昂贵的操作，如果应用在启动的时候发生大量Full GC，通常都是由于永久代或元空间发生了大小调整，基于这种情况，一般建议在JVM参数中将MetaspaceSize和MaxMetaspaceSize设置成一样的值，并设置得比初始值要大，对于8G物理内存的机器来说，一般我会将这两个值都设置为256M。
垃圾收集算法
分代收集理论
当前虚拟机的垃圾收集都采用分代收集算法，只是根据对象存活周期的不同将内存分为几块。
一般将java堆分为新生代和老年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。
例如：在新生代中，每次收集都会有大量对象(近99%)死去，所以可以选择复制算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。
而老年代的对象存活几率是比较高的，而且没有额外的空间对它进行分配担保，所以我们必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。
标记-复制算法
为了解决效率问题，“复制”收集算法出现了。它可以将内存分为大小相同的两块，每次使用其中的一块。
当这一块的内存使用完后，就将还存活的对象复制到另一块去，然后再把使用的空间一次清理掉。
这样就使每次的内存回收都是对内存区间的一半进行回收。
标记-清除算法
算法分为“标记”和“清除”阶段：标记存活的对象， 统一回收所有未被标记的对象(一般选择这种)；
也可以反过来，标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象 。
问题：
- 效率问题
- 空间问题
标记-整理算法
根据老年代的特点特出的一种标记算法，标记过程仍然与“标记-清除”算法一样，
但后续步骤不是直接对可回收对象回收，而是让所有存活的对象向一端移动，然后直接清理掉端边界以外的内存。
垃圾收集器
如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。
现在为止还没有最好的垃圾收集器出现，没有万能的垃圾收集器，我们需要的就是根据具体应用场景选择适合自己的垃圾收集器。
1.1 Serial收集器(-XX:+UseSerialGC -XX:+UseSerialOldGC)
Serial（串行）收集器是最基本、历史最悠久的垃圾收集器了。这个收集器是一个单线程收集器了。
它的 “单线程” 的意义不仅仅意味着它只会使用一条垃圾收集线程去完成垃圾收集工作，更重要的是它在进行垃圾收集工作的时候必须暂停其他所有的工作线程（ "Stop The World" ），直到它收集结束。
新生代采用复制算法，老年代采用标记-整理算法。
优势：简单高效，单线程没有任何线程开销
缺点：回收过程中应用程序暂停
Serial Old收集器是Serial收集器的老年代版本，它同样是一个单线程收集器。
它主要有两大用途：一种用途是在JDK1.5以及以前的版本中与Parallel Scavenge收集器搭配使用，另一种用途是作为CMS收集器的后备方案。
1.2 Parallel Scavenge收集器(-XX:+UseParallelGC(年轻代),-XX:+UseParallelOldGC(老年代))
Parallel收集器其实就是Serial收集器的多线程版本，除了使用多线程进行垃圾收集外，其余行为（控制参数、收集算法、回收策略等等）和Serial收集器类似。默认的收集线程数跟cpu核数相同，当然也可以用参数(-XX:ParallelGCThreads)指定收集线程数，但是一般不推荐修改。
Parallel Scavenge收集器关注点是吞吐量（高效率的利用CPU）。CMS等垃圾收集器的关注点更多的是用户线程的停顿时间（提高用户体验）。所谓吞吐量就是CPU中用于运行用户代码的时间与CPU总消耗时间的比值。 Parallel Scavenge收集器提供了很多参数供用户找到最合适的停顿时间或最大吞吐量，如果对于收集器运作不太了解的话，可以选择把内存管理优化交给虚拟机去完成也是一个不错的选择。
新生代采用复制算法，老年代采用标记-整理算法。
Parallel Old收集器是Parallel Scavenge收集器的老年代版本。
使用多线程和“标记-整理”算法。在注重吞吐量以及CPU资源的场合，都可以优先考虑 Parallel Scavenge收集器和Parallel Old收集器(JDK8默认的新生代和老年代收集器)。
1.3 ParNew收集器(-XX:+UseParNewGC)
ParNew收集器其实跟Parallel收集器很类似，区别主要在于它可以和CMS收集器配合使用。
新生代采用复制算法，老年代采用标记-整理算法。
1.4 CMS收集器(-XX:+UseConcMarkSweepGC(old))
CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。它非常符合在注重用户体验的应用上使用，它是HotSpot虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。
从名字中的Mark Sweep这两个词可以看出，CMS收集器是一种 “标记-清除”算法实现的，它的运作过程相比于前面几种垃圾收集器来说更加复杂一些。整个过程分为四个步骤：
初始标记： 暂停所有的其他线程(STW)，并记录下gc roots直接能引用的对象，速度很快。
并发标记： 并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程， 这个过程耗时较长但是不需要停顿用户线程， 可以与垃圾收集线程一起并发运行。因为用户程序继续运行，可能会有导致已经标记过的对象状态发生改变。
重新标记： 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短。主要用到三色标记里的增量更新算法(见下面详解)做重新标记。
并发清理： 开启用户线程，同时GC线程开始对未标记的区域做清扫。这个阶段如果有新增对象会被标记为黑色不做任何处理(见下面三色标记算法详解)。
并发重置：重置本次GC过程中的标记数据。
它是一款优秀的垃圾收集器，主要优点：并发收集、低停顿。
但是它有下面几个明显的缺点：
- 对CPU资源敏感（会和服务抢资源）；
- 无法处理浮动垃圾(在并发标记和并发清理阶段又产生垃圾，这种浮动垃圾只能等到下一次gc再清理了)；
- 它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生，当然通过参数-XX:+UseCMSCompactAtFullCollection可以让jvm在执行完标记清除后再做整理
- 执行过程中的不确定性，会存在上一次垃圾回收还没执行完，然后垃圾回收又被触发的情况，特别是在并发标记和并发清理阶段会出现，一边回收，系统一边运行，也许没回收完就再次触发full gc，也就是"concurrent mode failure"，此时会进入stop the world，用serial old垃圾收集器来回收
三色标记算法
这个算法就是把 GC 中的对象划分成三种情况：
白色：还没有搜索过的对象（白色对象会被当成垃圾对象）
灰色：正在搜索的对象
黑色：搜索完成的对象（不会当成垃圾对象，不会被GC）
上面说的这个问题就是可以用下图来表示：
假设有 A -> B -> C， A 是 GC Roots 关联的对象，那么首先会把 GC Roots 标记，也就是 A 标记成灰色（证明现在正在搜索 A 相关的），然后搜索 A 的引用，也就是 B，那么搜索了 B，把 B 变成了灰色，那么 A 就搜索完成了。（此时注意，现在是不管 C 的，因为 C 不是 A 的引用，现在只管 A 的引用是什么）。此时把 A 相关的搜索完了，那么 A 就变成了黑色，证明 A 已经 ok 了。
（Ps：浮动垃圾就是说，此时 A 又不用了，那么 A 是没办法回收的，因为 A 已经标记了）
此时准备要搜索 B 了。
刚好，此时，用户线程要执行了，用户线程把原来 A -> B -> C 的引用改成了 A -> C，同时 B 不再引用C。
然后又到 GC 线程执行了。
GC 线程发现 B 没有引用的对象了（因为用户线程已经把 B -> C 去掉了），那么 B 就相当于搜索完成了，变成黑色了。
最后C还是白色的呢，白色的是不会搜索，当做垃圾处理的。
CMS的相关核心参数
- -XX:+UseConcMarkSweepGC：启用cms
- -XX:ConcGCThreads：并发的GC线程数
- -XX:+UseCMSCompactAtFullCollection：FullGC之后做压缩整理（减少碎片）
- -XX:CMSFullGCsBeforeCompaction：多少次FullGC之后压缩一次，默认是0，代表每次FullGC后都会压缩一次
- -XX:CMSInitiatingOccupancyFraction: 当老年代使用达到该比例时会触发FullGC（默认是92，这是百分比）
- -XX:+UseCMSInitiatingOccupancyOnly：只使用设定的回收阈值(-XX:CMSInitiatingOccupancyFraction设定的值)，如果不指定，JVM仅在第一次使用设定值，后续则会自动调整
- -XX:+CMSScavengeBeforeRemark：在CMS GC前启动一次minor gc，降低CMS GC标记阶段(也会对年轻代一起做标记，如果在minor gc就干掉了很多对垃圾对象，标记阶段就会减少一些标记时间)时的开销，一般CMS的GC耗时 80%都在标记阶段
- -XX:+CMSParallellnitialMarkEnabled：表示在初始标记的时候多线程执行，缩短STW
- -XX:+CMSParallelRemarkEnabled：在重新标记的时候多线程执行，缩短STW;
JVM内存参数大小该如何设置
假设日均百万交易系统
对于8G内存，一般是分配4G内存给JVM，正常的JVM参数配置如下：
|
-Xms3072M -Xmx3072M -Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:SurvivorRatio=8 |
|---|
这样设置可能会由于动态对象年龄判断原则导致频繁full gc
调优1、JVM参数设置
默认比例情况下 年亲代占比小，触发minor gc频率过高，短时间快速触发达到15次进入老年代
|
-Xms3072M -Xmx3072M -Xmn2048M -Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:SurvivorRatio=8 |
|---|
这样就降低了因为对象动态年龄判断原则导致的对象频繁进入老年代的问题
调优2、老年代CMS的参数如何设置可以思考下，首先我们想下当前这个系统有哪些对象可能会长期存活躲过5次以上minor gc
|
-Xms3072M -Xmx3072M -Xmn2048M -Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=5 -XX:PretenureSizeThreshold=1M |
|---|
对于对象年龄应该为多少才移动到老年代比较合适，上例一次minor gc要间隔二三十秒，大多数对象一般在几秒内就会变为垃圾，完全可以将默认的15岁改小一点，比如改为5，
那么意味着对象要经过5次minor gc才会进入老年代，整个时间也有一两分钟了，如果对象这么长时间都没被回收，完全可以认为这些对象是会存活的比较长的对象，可以移动到老年代，而不是继续一直占用survivor区空间。
结合系统看下有没有什么大对象生成，预估下大对象的大小，一般来说设置为1M就差不多了，很少有超过1M的大对象，这些对象一般就是你系统初始化分配的缓存对象，比如大的缓存List，Map之类的对象。
调优3、对于碎片整理，因为都是1小时或几小时才做一次FullGC，是可以每做完一次就开始碎片整理，或者两到三次之后再做一次也行
|
-Xms3072M -Xmx3072M -Xmn2048M -Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=5 -XX:PretenureSizeThreshold=1M -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=92 -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=3 |
|---|
要点：就是尽可能让对象都在新生代里分配和回收，尽量别让太多对象频繁进入老年代，避免频繁对老年代进行垃圾回收，同时给系统充足的内存大小，避免新生代频繁的进行垃圾回收
