概述
Java内存运行时数据区的程序计数器、虚拟机栈、本地方法栈3个区域会随着线程而产生，随线程而消失。这几个区域分配多少内存时在类结构确定下来即已知的，在这几个区域内就不需要过多考虑如何回收内存的问题，当方法结束或者线程结束时，内存就自然跟随系统回收了。
Java堆和方法区这连个内存区域充满了不确定性：一个接口的多个实现类需要的内存可能不一样，一个方法在运行中索分配的内存也可能不一样，只有在程序的运行过程中，我们才知道程序会创建哪些对象，创建多少个对象，这部分的内存分配和回收时动态的。垃圾回收器和内存分配策略关注的也是这部分的内存分配和回收。
怎么判断对象已死
在堆中存在着Java中几乎所有的对象实例，垃圾回收器在对堆进行会搜狐前，第一件事情就是要确定这个对象中哪些时存活的，哪些是死去(即不可能被任何途径使用的对象)的。
找出对象是否存活的方式
引用计数算法
通俗的解释是：在对象中添加一个引用计数器，每当有一个地方引用它时，计数器的值加1；当引用失效时，计数器的值减1；当计数器的值为0时，表示这个对象就不可能再被使用。
但是这个算法是没有在Java的垃圾回收器中有使用的，对于一些例外的情况，这种算法不加特殊处理的情况下，是没有办法处理的。例如：Java对象的循环引用问题。
Java运行参数-XX:+PrintGCDetails -Xms10m -Xmx20m
-XX:+PrintGCDetails # 输出GC的详细信息
-Xms10m # 堆内存初始化大小
-Xmx20m # 堆内存最大大小
通过配置不同的Jvm启动堆内存测试发现，当堆内存初始化内存太小如：初始4最大10，在cmd命令行拆给窗口无法启动，通过IDEA却能启动。
可达性分析算法
判断原理：根据一系列的GC Root的集合，以其单个GC Root作为起始节点，从这个节点开始，根据引用关系向下搜索，搜索所走过的路径称为引用链，如果某个对象在整个GC Root引用链相连接(通过GC Root集合到达不了这个对象)，则证明此对象不可能再被使用。
在Java中，可固定作为GC Root的对象
- 虚拟机栈中引用的变量，如：当前正在运行的方法所使用的参数、局部变量、临时变量；
- 在方法区类中静态属性引用的对象(静态属性为对象)，如：类中的静态属性为Java对象；
- 方法区中常量引用的对象，如：字符串常量池里的引用；
- 本地方法栈所引用的对象；
- 所有被同步锁(synchronized)持有的对象；
Java对象引用强度
强引用 > 软引用 > 弱引用 > 虚引用
强引用：传统的创建Java对象的方式，如：Object obj = new Object();任何情况下，只要存在强引用关系，垃圾回收器永远不会回收掉被引用的对象。
软引用：描述一些还有用，但非必须的对象。只被软引用关联的对象，在系统要发生内存溢出异常前，会把这些对象列进回收范围进行第二次回收，如果这次回收之后还没有足够的内存，则抛出内存溢出异常。SoftReference。
弱引用：描述非必须对象，但其强度比软引用更弱一些，被弱引用关联的对象，只能生存到下一次垃圾回收器发生为止。当垃圾回收器开始工作，无论当前内存是否足够，都会回收掉只被弱引用该你了的对象。WeakReference。
虚引用：最弱的引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用唯一目的只是为了能够在这个对象被垃圾回收器回收时，收到一个系统通知。PhantomReference。
垃圾收集算法
分代收集理论
当前大多数的垃圾收集器，都遵循了分代收集的理论进行设计，这个理论建立在两个分代假说之上：
- 弱分代假说：绝大多数对象都是朝生熄灭的；
- 强分代假说：熬过多次垃圾收集过程的对象就越难消失。
设计准则：收集器应该将堆划分成不同的区域，然后将回收的对象依据其年龄(经历垃圾回收的次数)分配到不同的区域中存储。根据垃圾收集器每次只回收其中某一个或某些部分的区域，有这些Minor GC``Major GC``Full GC类型划分。
一般会将Java堆划分成新生代和老年代两个区域。在新生代中，每次垃圾收集都会有大量的对象清除，而每次回收后存活的少量对象，将会逐步晋升到老年代中存放。会有一个问题：新生代中的对象被老年代的对象引用(跨代引用)。
假设现在对一个新生代的区域内进行GC，但新生代中的对象有很大可能是被老年代的对象所引用的，为了找出该区域的存活对象，不得不在固定的GC Root集合之外，还需要遍历整个老年代的GC Root集合来确保可达性分析结果的准确性，反过来也是如此。
跨代引用假说：跨代引用相对于同代引用来说是极少数的。
会存在这样一直现象：存在互相引用的对象，它们都是同时存在或同时消亡的。例如：如果一个新生代的对象引用了老年代的对象，随着GC收集的次数增加，新生代的对象会晋升到老年代，到这时，跨代引用就消失了。
标记-清除算法
首先标记出所有需要回收的对象，在标记完成之后，统一回收所有被标记的对象，也可以反过来，标记出存活的对象，统一回收所有未标记的对象。过程如下图
缺点：
- 执行效率不稳定，如果Java堆中有大量的对象需要回收，这时就需要进行大量的标记和清除动作，导致标记和清除的两个过程都会随着对象数量增长而降低；
- 内存空间的碎片化，标记清除之后会产生大量的不连续的内存碎片，空间碎片太多导致程序运行时需要分配较大对象时无法找到足够的连续内存，不得不提前促发另一次垃圾收集动作。
标记-复制算法
为了解决标记清除算法面临大量可回收对象执行效率低的问题。可以将内存按容量划分为大小相对的两块，每次只使用其中一块，当这一块内存快使用完时，将存活的对象复制到另外一块内存中去，然后再把刚刚使用的内存一次性清除。
缺点：
- 可用内存缩小为原来一半；
- 当内存中都是大量存活的对象，这种算法会产生大量的内存复制的开销。
HotSpot虚拟机的Serial、ParNew收集器采用Appel式分区：把新生代分为一块较大的Eden空间和两个较小的Survivor空间，每次内存分配只使用Eden和其中一块Survivor空间。发生垃圾收集时，将Eden和Survivor中仍然存活对象一次性复制到另外一块Survivor上，然后直接清理掉Eden和已使用过的Survivor空间。HotSpot虚拟机Eden和Survivor默认大小比例是8:1，即每次新生代可用内存为新生代的90%。这里会面临一个问题，当回收之后的存活的对象大于10%新生代空间，就需要依赖其他内存区域(老年代)。
标记-整理算法
标记的过程和标记-清除算法过程一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向内存空间一端移动，然后清理掉边界以外的内存。
在老年代这种回收都有大量的存活对象，移动存活对象并更新所有引用的过程必须暂停用户线程(Stop The World)才能进行。
HotSpot算法分析
OopMap数据结构：一种用于描述对象内部指针布局和引用信息的数据结构。
记忆集：是一种用于记录非收集区域指向收集区域的指针集合的抽象数据结构。
三色标记：https://en.wikipedia.org/wiki/Tracing_garbage_collection#Tri-color_marking
- 白色：表示对象尚未被垃圾收集器访问过。可达性分析阶段，所有的对象都是白色的，分析结束后还是白色，即代表不可达。
- 黑色：表示对象已经被垃圾收集器访问过，且这个对象的所有引用都已经扫描过。黑色的对象表示已经扫描过，是存活的，如果有其他对象指向了黑色对象，无需重新扫描一遍。黑色对象不可能直接指向某个白色对象。
- 灰色：表示对象已经被垃圾收集器访问过，但这个对象至少存在一个引用还没有被扫描。
- 根节点枚举(GC Root扫描)：根节点枚举的过程中，要保证枚举的过程中的一致性，即在某个冻结的时间点上，不会出现对象引用还在发生变化的清空，要保证对象的引用关系不发生变化，最好的办法是暂停用户线程(Stop The World)。HotSpot为了更好的找到对象引用关系，使用了OopMap数据结构来达到这个目的。
- 安全点：在OopMap的协助下，可以快速准确的完成GC Root枚举，也会面临一个问题：可能导致引用关系变化，或者说OopMap内容变化的指令非常多，如果为每一条指令都生成一条对于OopMap，则需要大量的额外空间。所以在特定的位置记录OopMap等信息，这个位置被称为安全点。并不能让线程在任意位置都能停顿下来进行垃圾收集，二十强制要求到达安全点才能够暂停。安全点的选定既不能太少以至于让收集器等待过长，也不能太过频繁以至于增大运行时的内存负荷。安全点的特征：是否具有让程序长时间执行的，因为每条指令执行的时间都非常短暂，程序不太可能因为指令流长度太长而长时间执行，长时间执行最明显的特征就是指令序列的复用，例如：方法调用、循环调整、异常跳转等指令序列复用，所以只有具有这些功能的指令才会产生安全点。抢先式中断：发生垃圾收集时，首先把所有用户线程全部中断，如果发现用户线程中断的地方不在安全点上，则恢复这条线程执行，让它一会再重新中断，知道跑到安全点上。主动式中断：当垃圾收集需要中断线程时，不直接对线程操作，仅简单设置一个标志位，各个线程执行过程中会不停的主动轮询这个标志，，一但发现中断标志为真时就自己在最近的安全点上时主动中断挂起。
- 安全区域：当程序不执行就是没有分配处理器时间，典型的就是线程Sleep或者Blocked状态，这个时候线程无法响应虚拟机的中断请求，不能再走到安全的地方再中断挂起，虚拟机显然不可能等待线程重新激活被分配时间。这种情况就需要引入安全区域：指能够保证在某一代码片段之中，引用关系不再发生变化，因此，在这个区域中任意地方开始垃圾收集都是安全的。当用户线程执行到安全区域里的代码时，首先标识自己进入了安全区域，这段时间虚拟机发起垃圾收集就需要管里这些声明已经在安全区域内的线程。当线程要离开安全区域时，它要检查虚拟机是否已经完成根节点枚举，如果完成了，那线程就当什么也没有发生，继续执行，否则就一直等待，知道收到可以离开安全区域的信号为止。
- 记忆集与卡表：为解决跨代引用所带来的问题，垃圾收集器在新生代中建立了记忆集的数据结构，用以避免扫描整个老年代GC Root范围。收集器只需要通过记忆集判断出某一块非收集区域是否存在有指针指向收集区域的指针就可以了，并不需要了解这些跨代指针的全部细节。就可以只记录某些精度：字长精度(精确到机器字长，改字包含跨代指针)、对象精度(精确到对象，对象中有字段则含跨代指针)、卡精度(记录精确到一块内存区域，该区域内有对象则含有跨代指针)。卡精度所指即
卡表的方式实现记忆集，记忆集和卡表的关系可以理解为Map与HashMap的关系。卡表最简单的形式可以是一个字节数组，字节数组中的每一个元素都对应着与其标识的内存区域中一块特定大小的内存块(卡页)，卡页一般都是2的N次幂的字节数，一个卡页的内存中通常包含不止一个对象，只要卡页中有一个或多个对象即存在跨代指针，那就将卡表的数组元素的值标为1，没有则为0。在垃圾收集时，只要筛选出卡表中变脏的元素，就鞥你轻易得出哪些卡页内存块中包含跨代指针，把它们一并加入GC Root扫描即可。 - 写屏障：解决卡表如何维护，何时变脏、如何变脏等。变脏的条件：有其他分代区域中对象的引用了本区域对象，其对应的卡表元素就应该变脏，变脏时间原则上应该发生在引用类型字段赋值的那一刻。写屏障可以看作是虚拟机层面的引用类型赋值的AOP切面，可以分为写前屏障、写后屏障。需要处理伪
共享问题。 - 并发的可达性分析：当收集器在对象图中标记颜色，同时用户线程在修改引用关系，会出现两种情况：一种是原本要清理的对象错误标记为存活；另一种是存活的对象错误标记为清理。出现对象消失会有两个必要条件：赋值器中插入了一条或多条黑色对象到白色对象的新引用；赋值器删除了全部从灰色对象到该白色对象的直接或间接引用。解决这个问题只需破坏其中任意一个条件。增量更新：当黑色对象插入指向白色对象时，将这个新插入的引用记录下来，等待并发扫描结束之后，再将这些记录过的引用关系中的黑色对象为根，重新扫描一次。原始快照：当灰色对象要删除指向白色对象的引用关系时，将这个要删除的引用关系记录下来，再并发扫描结束之后，再将记录的引用对象为根，重新扫描一次。这里的记录操作都是虚拟机通过写屏障实现的。
垃圾收集器
Minor GC触发情况
Minor GC(Young GC)是指对新生代进行回收的垃圾收集过程。在Java虚拟机中，新生代被划分为Eden空间和两个Survivor空间（通常是S0和S1）。Minor GC主要用于回收Eden空间以及Survivor空间中的垃圾对象。
触发情况：
- Eden空间满：当Eden空间被填满时将触发Minor GC，Eden中存活的对象将被复制到Servivor空间。可能出现Eden存活对象占用内存大于Servivor空间，可能会留一部分在Servivor，一部分晋升老年代。
- 空间分配担保失败：当要进行一个Minor GC之前，虚拟机会检查当前老年代的可用空间是否足够容纳新生代的所有对象，如果不足以容量，可能会触发Full GC(Major GC)，进而触发Minor GC
Major GC 触发情况
Major GC通常在老年代进行，对整个堆进行回收.
触发条件：
- 老年代空间不足：当老年代的可用空间不足以容纳新生代晋升的对象，可能触发Major GC。这通常是新生代产生大量长寿命的对象，导致老年代空间不足。
- 元空间/永久代空间不足：1.8之后的元空间内存不足或1.8之前的永久代内存不足可能引发Full GC，进而引发Major GC。
- 调用System.gc()：并不一定保证100%触发。
- CMS收集器的Concurrent Mode Failere：使用CMS收集器，CMS运行期间预留的内存无法满足应用程序分配新对象的需要，则会促发Full GC。
启动参数：-Xmn1g -Xms4g -Xmx8g -XX:+UseParNewGC -XX:+PrintGCDetails
执行GC后的内存情况：
为什么最后一次Minor+Mojor GC最终的内存会比老年代+新生代还要小？
最后的几次Full GC应该有对内存的什么操作？
| 回收类型 | Eden | S0 | 老年代 | 最大堆 |
|---|---|---|---|---|
| Minor GC | 0 | 100 | 700 | 4000 |
| Minor GC | 0 | 100 | 1500 | 4000 |
| Minor GC | 0 | 100 | 2300 | 4000 |
| Minor+Major GC | 0 | 100 | 3200 | 4100 |
| Minor GC | 0 | 100 | 3900 | 62 |
| Minor GC | 0 | 100 | 4700 | 62 |
| Minor+Major GC | 0 | 100 | 5500 | 65 |
| Minor GC | 0 | 100 | 6300 | 8000 |
| Minor GC | 0 | 100 | 7300 | 8000 |
| Minor+Major GC | 800 | 100 | 7350 | 这次GC 新+老都比最终的大 |
| Full GC | 800 | 100 | 7300 | |
| Full GC | 800 | 100 | 7350 | |
| Full GC | 800 | 100 | 7350 | 之后堆内存不够 |
Serial收集器(标记复制)
这个收集器是一个单线程工作的收集器，在收集器收集垃圾的过程中，必须暂停其它所有工作线程，知道它结束。
优点：占用的额外内存小；单核处理器或处理器核心较少的环境下，没有线程交互的开销。
缺点：单线程收集，停顿时间长(内存大的情况下)。
ParNew收集器(Par标记复制)
该收集器是Serial收集器的多线程并行版本，除了同时多条线程进行垃圾收集外，其余的行为收集算法、STW、对象分配规则、回收策略等都与Serial收集器保持一致。
可配置参数：-XX:SurvivorRatio、-XX:PretenureSizeThreshold、-XX:HandlePromotionFailure。
在单核心处理器的环境中，ParNew收集器的效果绝对没有Serial收集器好。
ParNew搭配Serial Old(JDK 9删除)
ParNew可以搭配CMS
Parallel Scavenge收集器(PS标记复制)
新生代收集器
基于标记-复制算法实现的收集器，能够并行收集的多线程收集器。该收集器注重吞吐量：运行用户线程消耗的时间/(运行用户线程消耗的时间 + 运行垃圾收集器消耗的时间)。
-XX:MaxGCPauseMills控制最大垃圾收集时间，单位毫秒。
-XX:GCTimeRatio控制吞吐量，表示期望虚拟机消耗在GC上的时间不超过程序运行时间的1/(1+N)，N为正整数。默认值99。
-XX:+UseAdaptiveSizePolicy开关参数，激活表示不需要人工指定新生代(-Xmn)的内存大小、Eden和Survivor的比例、晋升老年代对象大小等细节参数。
Serial Old收集器(标记复制)
老年代收集器
单线程收集器，使用标记-复制算法。
可以搭配Serial收集器、Parallel Scavenge收集器使用。
是CMS收集器发生失败后的后备预案，在并发收集发生Convurrent Mode Failure时使用。
Parallel Old收集器(PS OLD标记复制)
是Parallecl Scavenge收集器的老年代版本，支持多线程并行收集，基于标记复制算法实现。
在Parallel Old收集器出现之前，Parallel Scavenge收集器结合老年代可使用的版本比较尴尬，其只能与Serial Old收集器合作，Serial Old收集器在服务端的性能较差，导致Parallel Scavenge的吞吐量也没有达到最大化的效果。在老年代的收集空间较大的情况下Parallel Scanenge + Serial Old的收集吞吐量不一定比ParNew + CMS的好。
CMS收集器(标记整理)
CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。
基于标记-清除算法实现，分为4个步骤：
- 初始标记(CMS initial mark)
- 并发标记(CMS concurrent mark)
- 重新标记(CMS remark)
- 并发清除(CMS concurrent sweep)
初始标记和重新标记这两个步骤，还是需要STW(Stop The World)。初始标记仅仅只是标记一下GC Root集合能直接关联到的对象。并发标记就是从GC Root集合中直接访问的对象开始遍历整个对象图的过程，过程耗时长但不需要停止用户线程，支持用户线程和回收线程并发执行。重新标记是修正并发标记期间，因为用户线程继续运作而导致的标记产生变动的那一部分对象的标记记录，这个阶段停顿的时间较初始标记长，但远比并发标记时间短。并发清除是清理掉标记阶段判断为死亡的对象，由于不需要移动存活对象，可以和用户线程并发执行。
缺点：
- 当处理器的核心数量不足4个时，该处理器的效率影响会较大。
- 三色标记会有一种情况是，对象应该是被标记死亡的，可是在这次并发过程中由于标记是在赋值之前已经扫描完成，导致该对象无法在当前处理中清理掉，这个就称为浮动垃圾。由于垃圾收集阶段用户线程还需要运行，那就需要预留足够的空间给用户线程使用，这就是得CMS收集器不能等到老年代空间几乎被填满才促发回收。在JDK5默认设置下，当老年代使用68%空间后会激活垃圾回收。-XX:CMSInitiatingOccu-pancyFraction值来提高触发的百分比，降低内存回收的频率。JDK6时，默认为92%。当阈值设置更高时，会面临新的问题，就是CMS运行期间预留的内存无法满足应用程序分配新对象的需要，就会出现并发失败(Conturrent Mode Failure)，启动后备预案：冻结用户线程，临时使用Serial Old收集器重新进行老年代的垃圾回收，这样停顿时间就长了。
- 产生碎片空间，当内存中的空间不能给一个大对象分配时，会促发Full GC。
Garbage First收集器
-XX:G1HeapRegionSize，设定Region区域大小。
-XX:MaxGCPauseMills，允许收集停顿的时间，默认值时200ms。
G1遵循分代收集理论设计，档期堆内存的区域与之前相比有非常明显的差异，G1将Java堆划分成多个大小相等的区域(Region)，每一个Region区域都可以扮演新生代的Eden、Survivor空间，或者老年代空间。
Region中存在一个特殊的Humongous区域，专门用来存储大对象。G1认为只要超过了Region容量一半的对象即可判断为大对象。没有Region区域的大小可以通过-XX:G1HeapRegionSize设定，取值1-32MB，且为2的幂次方。对于超过整个Region容量的超级大对象，将会被放在N个连续的Humongous Region之中。
可以分为4个阶段：
- 初始标记：标记一下GC Root集合能直接访问到的对象，并且修改TAMS(并发标记过程中新创建的对象存放的，表示不纳入回收访问)指针的值。需要停顿用户线程，耗时很短。
- 并发标记：从GC Root集合能访问到的对象对堆中的对象进行可达性分析，递归扫描出整个堆的对象图，找出需要回收的对象，这个可以与用户线程并发执行。当对象图扫描完成之后，还用重新处理一下STAB(快照解决并发对象消失问题)记录下的在并发下有引用变动的对象。
- 最终标记：对用户线程进行短暂停顿，用户处理STAB记录中的对象。
- 筛选回收：负责更新Region的统计数据，对各个Region的回收价值和成本进行排序，根据用户所期望的停顿时间来指定计划，可以自由选择任意多个Region构成回收集，然后把决定回收的Region区域存活的对象赋值到空的Region中，再清理掉整个旧的Region的全部空间。必须暂停用户线程。
阅读垃圾处理器日志
可以通过-Xlog参数配置日志打印的信息。
-Xlog[:[selector] [:[output] [:[decorators] [:output-options]]]]
| 日志输出相关参数 | 作用 |
|---|---|
| time | 当前日期和时间 |
| uptime | 虚拟机启动到现在经过的时间，以秒为单位 |
| timemillis | 当前时间的毫秒数，相当于System.currentTimeMillis() |
| uptimemillis | 虚拟机启动到现在经过的毫秒数 |
| timenanos | 当前时间的纳秒数，相当于System.nanoTime（） |
| uptimenanos | 虚拟机启动到现在经过的纳秒数 |
| pid | 进程ID |
| tid | 线程ID |
| level | 日志级别 |
| tags | 日志输出的标签集 |
GC日志启动参数
| JDK9之前日志参数 | JDK9之后配置 | 作用 |
|---|---|---|
| -XX:+PrintGC | -Xlog:gc | 查看GC基本信息 |
| -XX:+PrintGCDetails | -Xlog:gc* | 查看GC详细信息 |
| -XX:+PrintHeapAtGC | -Xlog:gc+heap=debug | GC前后堆、方法区可用内存变化 |
| -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime | -Xlog:safepoint | 用户线程并发时间以及停顿的时间 |
| -XX:+PrintAdaptiveSizePolicy | -Xlog:gc+ergo*=trace | 收集器自动调节的相关信息 |
| -XX:+PrintTenuringDistribution | -Xlog:gc+age=trace | 收集后剩余对象的年龄分布 |
| JDK9之前参数 | JDK9之后参数 |
|---|---|
| G1PrintHeapRegions | -Xlog:gc+region=trace |
| G1PrintRegionLivenessInfo | -Xlog:gc+liveness=trace |
| G1SummarizeConcMark | -Xlog:gc+marking=trace |
| G1SummarizeRSetStats | -Xlog:gc+remset*=trace |
| GCLogFileSize,NumberOfGCLogFiles,UseGCLogFileRotation | -Xlog:gc*:file=?::filecount=?,filesize=?kb |
| PrintAdaptiveSizePolicy | -Xlog:gc+ergo*=trace |
| PrintClassHistogramAfterFullGC | -Xlog:classhisto*=trace |
| PrintClassHistogramBeforeFullGC | -Xlog:classhisto*=trace |
| PrintGCApplicationConcurrentTime | -Xlog:safepoint |
| PrintGCApplicationStoppedTime | -Xlog:safepoint |
| PrintGCDateStamps | |
| PrintGCTaskTimeStamps | -Xlog:gc+task=trace |
| PrintHeapAtGC | -Xlog:gc+heap=debug |
| PrintHeapAtGCExtended | -Xlog:gc+heap=trace |
| PrintJNIGCStalls | -Xlog:gc+jni=debug |
| PrintOldPLAB | -Xlog:gc+plab=trace |
| PringtParallOldGCPhaseTimes | -Xlog:gc+phase=trace |
| PrintPLAB | -Xlog:gc+plab=trace |
| PrintPromotionFailure | -Xlog:gc+promotion=debug |
| PrintReferenceGC | -Xlog:gc+ref=debug |
| PrintStringDeduplicationStatistics | -Xlog:gc+stringdedup |
| PringtTaskqueue | -Xlog:gc+task+stats=trace |
| PringtTenuringDistribution | -Xlog:gc+age=trace |
| PrintTerminationStats | -Xlog:gc+task+stats=debug |
| PrintTLAB | -Xlog:gc+tlab=trace |
| TraceAdaptiveGCBoundary | -Xlog:heap+ergo=debug |
| j | -Xlog:gc+task=trace |
| TraceMetadataHumongousAllocation | -Xlog:gc+metaspace+alloc=debug |
| G1TraceConeRefinement | -Xlog:gc+refine=debug |
| G1TraceEagerReclaimHumongousObjects | -Xlog:gc+humongous=debug |
| G1TraceStringSymbolTableScrubbing | -Xlog:gc+stringtable=trace |
垃圾收集器相关参数
| 参数 | 作用 |
|---|---|
| UseSerialGC | 使用Serial+Serial Old收集器组合 |
| UseParNewGC | 使用ParNew+Serial Old收集器组合，JDK9弃用 |
| UseConcMarkSweepGC | 使用ParNew+CMS+Serial Old组合进行内存回收，出现Concurrent Mode Failure的后备收集器使用Serial Old |
| UseParallelGC | JDK9之前Serve端默认值，使用Parallel Scavenge+Parallel Old组合 |
| UseParallelOldGC | 使用Parallel Scavenge+Parallel Old组合 |
| ServivorRatio | Eden:Survivor区域之间的比例，默认8，及8:1 |
| PretenureSizeThreshold | 直接晋升老年代的对象大小 |
| MaxTenuringThreshold | 晋升到老年代的对象年龄，每个对象执行过异常Minor GC之后，年龄+1 |
| UseAdaptiveSizePolicy | 动态调整Java堆中各个区域的大小及进入老年代的年龄 |
| HandlePromotionFailure/PromotionFailureALot | 是否允许担保失败，即老年代的剩余空间不足以应付新生代Eden和Survivor区域对象都存活的情况 |
| ParallelGCThreads | 设置并行GC时进行内存回收的线程数 |
| GCTimeRatio | GC时间占比总时间的比例，默认99，即允许占用1%，仅在Parrallel Scavenge有效 |
| MaxGCPauseMillis | 设置GC最大停顿时间，Parrallel Scavenge有效 |
| CMSInitiatingOccupancyFraction | 设置CMS收集器在老年代空间被占用多少触发垃圾回收，默认68，仅CMS有效 |
| UseCMSCompactAtFullCollection | 设置完成一次CMS收集之后是否需要进行内存碎片整理 |
| CMSFullGCsBeforeCompaction | 设置在若干次CMS收集后，启动一次内存碎片整理 |
| UseG1GC | 使用G1收集器，Serve端默认值，JDK9之后生效 |
| G1HeapRegionSize | 设置Region大小，并非最终值 |
| MaxGCPauseMillis | G1收集过程目标时间，默认200ms |
| G1NewSizePercent | 新生代最小值，默认5% |
| G1MaxNewSizePercent | 新生代最大值，默认60% |
| ConcGCThreads | 并发标记、并发整理的执行线程数 |
| InitiatingHeapOccupancyPercent | 触发标记周期的java堆占用阈值，默认45% |
内存分配和回收策略
对象优先在Eden分配
Serial+Serial Old
-XX:+PrintGCDetails -Xms20M -Xmx20m -Xmn10m -XX:+UseSerialGC
JVM启动参数作用，打印GC详细信息，设置堆内存初始化空间和最大空间一样，都为20m；新生代堆内存初始化空间为10m；使用Serial+Serial Old组合收集器。
在代码执行过程中前面三个对象的空间都是够用的，知道c4对象创建时，发现内存不够，触发了Minor GC，这个时候由于Survivor的空间只有1MB，不足够容纳6MB多的c1,c2,c3这3个对象，使用分配担保机制将这3个对象都复制到了老年代。但是这里的最理想的状态，Survivor的from区的used应该是0%。这里不为空的情况下，可能是上一次垃圾回收，有一部分的对象是能够在Survivor的To区存活，所以就存放在了Servivor区。
DefNew: 8133->642K(9216)新生代回收情况，表示回收时新生代占用了8133K，回收后使用了642K，垃圾回收耗时0.0038771s。
8133K->6787K(19456K)整个堆内存回收情况，回收前使用了8133K，回收后使用6786K，回收后使用了6787K，整个回收过程耗时0.0039130s。
所以最终的堆内存使用情况是老年代占用(6786 - 642)6144K，Servivor的from区占用642K，used 62%。
其中Times表示：
- user：进程执行用户态代码所耗费的处理器时间
- sys：进程执行和心态代码所耗费的处理器时间
- real：执行动作从开始到结束耗费的时钟时间
user和sys是时间代表的是线程占用处理器一个核心的耗时计数，在单核情况下，这三者等效。
-XX:+PrintGCDetails -Xms20M -Xmx20m -Xmn5m -XX:+UseSerialGC
新生代总内存被限制为5MB，可用内存为4608，第一次GC的发生时间是在c2对象创建时，第二次GC发生是在c3对象创建之前，这个时候新生代的对象都复制到老年代了，这个时候新生代就能创建c3对象了，在创建c4对象时，新生代占用了一部分空间，这里没有促发垃圾会后，而是之间将c4对象放在了老年代。
默认Parallel Scavenge+Parrallel Old
-XX:+PrintGCDetails -Xms20M -Xmx20m -Xmn10m -XX:SurvivorRatio=8
这里没有发生垃圾回收，可能c4对象创建时，内存不够，之间放在了老年代。
大对象直接进入老年代
两种情况：
- 新生代的内存空间不够新对象创建，可能直接将对象放在老年代(前面已经出现过)。
- 通过设置大于某阈值的对象，直接放在老年代，这个只对Serial和ParNew收集器有效。
Serial
-XX:+PrintGCDetails -Xms20M -Xmx20m -Xmn10m -XX:SurvivorRatio=8 -XX:+UseSerialGC -XX:PretenureSizeThreshold=3m
Parallel Scavenge
-XX:+PrintGCDetails -Xms20M -Xmx20m -Xmn10m -XX:SurvivorRatio=8 -XX:PretenureSizeThreshold=3m
Parallel Scavenge收集器-XX:PretenureSizeThreshold=3m参数不生效
长期存活对象进入老年代
可以通过这个MaxTenuringThreshold参数控制年龄达到多少的对象能够进入到老年代。
-XX:+PrintGCDetails -Xms20M -Xmx20m -Xmn10m -XX:SurvivorRatio=8 -XX:+UseSerialGC -XX:MaxTenuringThreshold=1 -XX:+PrintTenuringDistribution
-XX:+PrintGCDetails -Xms20M -Xmx20m -Xmn10m -XX:SurvivorRatio=8 -XX:+UseSerialGC -XX:MaxTenuringThreshold=15 -XX:+PrintTenuringDistribution
设置之后不生效
动态对象年龄判定
HotSpot虚拟机并不是永远要求对象的年龄必须达到-XX:MaxTenuringThreshold才能晋升老年代，在Servivor空间的低于或等于某个年龄的所有对象大小大于Servivor空间的一半，这个时候也能晋升老年代。
-XX:+PrintGCDetails -Xms20M -Xmx20m -Xmn10m -XX:SurvivorRatio=8 -XX:+UseSerialGC -XX:MaxTenuringThreshold=15 -XX:+PrintTenuringDistribution
这里之所以老年代会占用这么多空间，是因为在c4第一次创建空间时，经过垃圾回收，c3已经被移动到老年代了，这个之后c3赋值为null，并没有触发垃圾回收，在最后创建c4时，空间不够把新生代所有对象都复制到老年代，这个时候就出现了老年代占用9MB，多新生代只有4MB。
去掉一个对象，这里的Servivor空间，并没有像深入理解JVM虚拟机书中所写的那样(老年代的内存占用上面是大于下面的)。
空间分配担保
低于JDK1.8可能可以使用HandlePromotionFailure参数来控制分配担保风险，1.8的参数是PromotionFailureALot这个，而且还需要再debug模式下才能生效。
在发生Minor GC之前，需要看一下当前老年的最大可用空间是否能够容纳新生代所有对象的总空间，如果这个条件成立，则这次Minor GC可以确保是安全的。如果不成立，则看是否运行担保失败，如果允许，则继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，则尝试进行以Minor GC(存在风险)；如果小于或者开关未开启，则就要进行一次Full GC。
如果前面说的理论是GC先后理论是一直执行的，那下面的结果就能实现反推。第一次GC进入老年代的对象大概是4MB，此时老年代可用空间约等于6MB， 这时新生代的内存占用也是6MB都，这个时候如果开启了分配担保风险，上一次晋升对象4MB<当前老年代可用空间6MB，所以是进行Minor GC。
Java对象已死判定
在可达性分析算法中判断为不可达的对象，这个时候他们还是一个中间状态，并没有真正死亡，要宣告一个对象死亡，最多会经历两次标记过程：如果对象在进行可达性分析后发现没有于GC Root相连接的引用链，那它会被第一次标记，随后进行一次筛选，筛选的条件是此对象时候有必要执行finalize()方法。如果对象没有覆盖finalize()方法，或者finalize()方法已经被调用过，那么虚拟机将这两种情况都视为没有必要执行。
如果这个对象被判断为有必要执行finalize()方法，那么对象会被放置在一个名为F-Queue的队列中，并稍后再由虚拟机自动建立低优先级的Finalizer线程去执行他们的finalize()方法。
