JAVA垃圾收集器详解

1.基于HotSpot虚拟机1.6版Update22,包含的虚拟机如下
新生代收集器（采取复制算法）：
Serial：
（1）单线程收集器（只会只用一个CPU或一条手机线程去完成垃圾收集工作，
并且在进行垃圾收集的时候，必须暂停其他所有的工作线程“Stop The World”:这一点用户体验恶劣）
（2）优点：在单个CPU环境下，简单而高效
缺点：用户体验差（比如每工作1小时暂停响应5分钟）

parNew：
（1）Serial的多线程版本（在低CPU的情况下，效果没有Serial效果好），能与CMS搭配使用

Parallel Scavenge:
（1）并行多线程收集器
（2）目标：达到可控制的吞吐量。（停顿时间越短就越适合需要与用户交互的程序，良好的响应速度
能够提升用户体验；而高吞吐量则可以最高效率地利用CPU时间，尽快完成程序的运行任务，
主要适合在后台运算而不需要太多的交互的任务）
两个参数用于精确控制吞吐量：最大垃圾收集停顿时间：-XX:MaxGCPauseMillis (大于0的ms)
设置吞吐量大小：-XX:GCTimeRatio (>0 && < 100)
-XX:_+UseAdaptiveSizePolicy 自动调控，设置上 面的参数之一即可

老年代收集器：
SerialOld(MSC)：
（1）单线程收集器
（2）标记整理算法
（3）在jdk1.5与Parallel Scavenge搭配使用，作为CMS收集器的后备预案

Parallel Old：
（1）多线程
（2）标记整理算法
（3）jdk1.6之后：与parallel Scavenge搭配使用，“吞吐量优先“收集器终于有了名副其实的组合

CMS（concMarkSweep）:
（1）目标：尽可能缩短垃圾收集时用户线程的停顿时间。
（2）标记清除算法
（3）过程：初始标记->并发标记->重新标记->并发清除
（4）对CPU资源十分敏感。默认启动回收线程数：(CPU数量+3)/4
当cpu在4个以上时，并发回收时垃圾收集线程最多占用不超过25%的CPU资源，
但是当cpu不足4个的时候，CMS对用户程序的影响可能会很大。
（5）无法清理浮动垃圾
（6）标记清除算法：收集结束时会产生大量的空间碎片。

---

G1(Garbage First):
（1）基于标记整理算法
（2）非常精确地控制停顿，即能让使用者明确指定在一个长度为M毫秒的时间判断内，
消耗在垃圾收集上的时间不得超过N毫秒，这几乎是实时java(RTSJ)的垃圾收集器的特征了
（3）新生代，老年代都可以使用

如下图所示：两个收集器之间存在连线，就说经他们之间可以搭配使用

-Xms 最小堆，-Xmx最大堆
当最小堆占满后，会尝试进行GC，如果GC之后还不能得到足够的内存(GC未必会收集到所有当前可用内存)，分配新的对象，那么就会扩展堆，如果-Xmx设置的太小，扩展堆就会失败，导致OutOfMemoryError错误提示。

-Xss128k： 设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。

本机的垃圾收集器：Parallel Scavenge + SerialOld

线上jvm设置
java
-Denv=PRO
-server
-Xms4g （最小堆的大小， 也就是当你的虚拟机启动后， 就会分配这么大的堆内存给你）
-Xmx4g （是最大堆的大小 ）
-Xmn2g (设置年轻代大小为2G)
-XX:MaxDirectMemorySize=512m (设置java堆外内存的峰值)
-XX:MetaspaceSize=128m 设置类元空间大小
-XX:MaxMetaspaceSize=512m 设置最大的本地内存类元空间可用于垃圾回收
-XX:-UseBiasedLocking 使用偏向锁
-XX:-UseCounterDecay
-XX:AutoBoxCacheMax=10240
-XX:+UseConcMarkSweepGC 使用cms垃圾回收器
-XX:CMSInitiatingOccupancyFraction=75 (是指设定CMS在对内存占用率达到75%的时候开始GC(因为CMS会有浮动垃圾,所以一般都较早启动GC)😉
-XX:+UseCMSInitiatingOccupancyOnly (只是用设定的回收阈值(上面指定的75%),如果不指定,JVM仅在第一次使用设定值,后续则自动调整.)
-XX:MaxTenuringThreshold=6
-XX:+ExplicitGCInvokesConcurrent
-XX:+ParallelRefProcEnabled
-XX:+PerfDisableSharedMem
-XX:+AlwaysPreTouch (在调用main函数之前，使用所有可用的内存分页。这个选项可以用来测试长时间运行的系统，所有的内存都已被分配。默认这个选项 是关闭的，也就是不会使用所有的内存分页。 )
-XX:-OmitStackTraceInFastThrow 省略异常栈信息从而快速抛出(如果检测到在代码里某个位置连续多次抛出同一类型异常的话，C2会决定用Fast Throw方式来抛出异常，而异常Trace即详细的异常栈信息会被清空。这种异常抛出速度非常快，因为不需要在堆里分配内存，也不需要构造完整的异常栈信息)
-XX:MaxTenuringThreshold=2 在新生代中对象存活次数(经过Minor GC的次数)后仍然存活，就会晋升到旧生代。
-XX:+ExplicitGCInvokesConcurrent （当调用System.gc()的时候， 执行并行gc。默认是不开启的，只有使用-XX:+UseConcMarkSweepGC选项的时候才能开启这个选项。）
-XX:+ParallelRefProcEnabled （1.如果应用有很多的Reference or finalizable objects，那么可以使用-XX:+ParallelRefProcEnabled来减少duration）(2.支持并发引用处理)
-XX:+HeapDumpOnOutOfMemoryError dump出当前的内存堆转储快照。
-XX:HeapDumpPath=/home/devjava/logs/ 文件是一个二进制文件,它保存了某一时刻JVM堆中对象使用情况
-Xloggc:/home/devjava/logs/lifecircle-usercore-gc.log gc日志
-XX:+PrintGCApplicationStoppedTime 打印gc一共停顿了多长时间
-XX:+PrintGCDateStamps 打印gc时间戳
-XX:+PrintGCDetails 打印gc详细信息
-jar /home/devjava/lifecircle-usercore/app/lifecircle-usercore.jar

参数详解：
-XX:+AlwaysPreTouch
JAVA进程启动的时候,虽然我们可以为JVM指定合适的内存大小,但是这些内存操作系统并没有真正的分配给JVM,而是等JVM访问这些内存的时候,才真正分配,这样会造成以下问题。
1、GC的时候,新生代的对象要晋升到老年代的时候,需要内存,这个时候操作系统才真正分配内存,这样就会加大young gc的停顿时间;
2、可能存在内存碎片的问题。