jvm垃圾回收总结

1、java内存的划分

java虚拟机在运行java程序是将jvm管理内存区域划分为不同的数据区域，统称为java运行时数据区。其中包括程序计数器、虚拟机栈、本地方法栈、方法区、堆等主要区域。详情如下图所示：

由上图可以看出，虚拟机栈、本地方法栈、和程序计数器是非线程共享的。这三个区域与线程息息相关，随着线程的创建而产生，随着线程的结束而销毁。

1.1、 线程私有区域

程序计数器：在虚拟机的概念模型中，字节码解析器就是获取程序计数器的值来判断下一条语句执行的字节码指定，我们代码中的顺序、分支、循环、跳转、异常处理和线程恢复都是通过程序计数器来完成的。在多线程环境下，为了保证线程切换后能恢复到正确的执行位置，每个线程都拥有自己的程序计数器，各个线程之间不会互相影响、内存独立存储，所以他们是线程私有区域。并且此区域是虚拟机中唯一为规范内存溢出的区域。

虚拟机栈：虚拟机栈同程序计数器一样，也是线程私有，并且生命周期与线程一致。虚拟机栈只要是描述线程执行方法的一种内存表现。每个java方法在被执行的时候，都会创建一个栈帧，用于保存局部变量表、动态链接、方法出口、操作数栈等信息。***局部变量表***用于存放程序在编译器的各种基本数据类型和对象引用。其中每个局部变量空间（Slot）有32位，所以long和double类型的数据会占用两个局部变量空间，其他类型包括对象引用占用一个。对象引用调用的是存在堆中的对象，这个引用可以是对象的起始地址或者是指向对象的句柄。局部变量表所需的内存在编译期就已经确定了也就是进入这个方法时就已经确定了，运行期间不会更改。***操作数栈***通过字节码翻译的指令来让操作数栈把一些数据进行出栈入栈的操作。***动态链接*就是将符号引用所表示的类、方法或者变量转换为实际的直接引用。方法出口**调用方法执行完后会有相应的返回上一层的返回的字节码指令，这种方式是正常完成出口，或是遇到异常代码中使用了throw字节码这种方式的异常完成出口。在此区域jvm规范了两种异常：当栈深度超过虚拟机的规定时，StackOverFlowError；当扩展时无法申请到足够的内存，OutOfMemeryError。

本地方法栈：本地方法栈（Native Method Stacks）与虚拟机栈所发挥的作用是非常相似的，其区别不过是虚拟机栈为虚拟机执行Java方法（也就是字节码）服务，而本地方法栈则是为虚拟机使用到的Native方法服务。虚拟机规范中对本地方法栈中的方法使用的语言、使用方式与数据结构并没有强制规定，因此具体的虚拟机可以自由实现它。甚至有的虚拟机（譬如Sun HotSpot虚拟机）直接就把本地方法栈和虚拟机栈合二为一。与虚拟机栈一样，本地方法栈区域也会抛出StackOverflowError和OutOfMemoryError异常。

1.2、线程共享区域

堆：给所有类的实例和数组分配内存的运行时数据区。 堆在虚拟机启动的时候创建，堆中储存的对象通过一个自动存储管理系统（垃圾回收器）进行回收。 对象从不明确的被分配(JVM从不指明对象的释放)。JVM加上没有(JVM不指定特定的自动存储管理系统)自动存储管理系统的特别的类型，(开发者可根据系统要求自主选择)并且这个存储管理技术可能被选择按照实现的系统需求。堆根据分代概念，实质上分为新生代（Young Generation）、老年代（Old Generation）(新生代和老年代内存比例使用-XX:NewRatio)。对于新生代又分为Eden空间、From Survivor空间、To Survivor空间(设置from和to区的空间比例-XX:SurvivorRatio)。Java虚拟机规范的规定，Java堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可，就像我们的磁盘空间一样。在实现时，既可以实现成固定大小的，也可以是可扩展的，不过当前主流的虚拟机都是按照可扩展来实现的（通过-Xmx和-Xms控制）。如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出OutOfMemoryError异常。

方法区：JVM的方法区是所有线程共享的，方法区类似于传统语言编译代码时的存储区域或类似于操作系统进程的文本段。他存储内容包括：每一个类的结构，如运行时常量池，字段和方法的数据；方法和构造器的代码，如用于类，实例和接口初始化的特殊方法。这个方法区在JVM启动的时候被创建，一般情况下JVM不会选择对方法区进行垃圾回收或者压缩，这个版本的JVM规范没有强制规定方法区的位置和管理编译后代码的策略。方法区可固定大小，或按需伸缩。方法区的内存不需要相邻。方法区中包含运行时常量池。运行时常量池是类和接口运行时的常量池表，它在字节码文件里。它包含几类常量。 在编译时期识别的数值常量，在运行区识别的方法或引用字段。运行区常量池类似于传统语言的字符表，但它比传统字符表所存储的范围更广。每一个运行区常量池从方法区分配内存。当类和接口被JVM创建时相应的常量池也被创建。当类和接口创建时，如果运行区常量池所需内存不足，则抛出OutOfMemoryError。

2、回收目标确定

在线程私有区域都是随着线程创建开辟内存，线程销毁就回收内存，相对来说比较固定和稳定，无需过多考虑回收问题。而Java堆区和方法区则不一样，这部分内存的分配和回收是动态的，正是垃圾收集器所需关注的。所以java堆和方法区也是GC工作的主要区域。

2.1 引用计数法

判断对象是否存活：给对象添加一个引用计数器，当对象存在一个地方引用时，则计数器加1，引用失效时，则计数器减1。当计数器的值减少为0时，我们认为该对象为可回收对象。此方法相对来说方便、高效，但在常用你的商业虚拟机中都未选用该方法，主要因为存在对象之间相互引用问题无法解决。

2.2 可达性分析法

在目前我们使用HotSpot虚拟机采用的是可达性分析算法来判断对象是否存活。该算法核心思想是"GCRoots"对象作为一个根节点,从根节点往下搜索，搜索的路径则为引用链。当一个对象没有任何引用链相连时，则认为该对象是可以被回收的对象。
在Java语言中，可作为GC Roots的对象包括下面几种：

a) 虚拟机栈中引用的对象（栈帧中的本地变量表）；

b) 方法区中类静态属性引用的对象；

c) 方法区中常量引用的对象；

d) 本地方法栈中JNI（Native方法）引用的对象。

3、回收算法

3.1、标记-清除

顾名思义，该算法一共分为两个步骤，“标记”和“清除”。第一步根据根据根节点可达性分析算法标记存活的对象,第二步清除回收第一步未被标记的对象。该算法主要适应于存活对象多(老年代对象存活率比较高，所以该算法适应于老年代)。

缺点：
a)、回收完成后容易产生较多的内存碎片(可用内存空间不连续)。

b)、效率比较低，整个过程标记了存活对象，第二步清除未标记的对象。

3.2、标记-整理

首先第一步根据根搜索算法对存活对象进行标记，然后将所有存活的独享移动到内存的一侧，最后清除该边界以外的内存空间。如下图所示：

这种方式回收内存空间不会形成内存碎片。也不需要和复制算法一样需要另一块未使用的内存空间。

3.3、复制

首先根据根节点可达性分析算法标记堆中已使用的内存。然后将已被标记的内存复制到另一块内存上，将原来那块内存够全部回收。

适应场合：对象内存存活很低的情况很高效，

适用于年轻代（即新生代）：基本上98%的对象是”朝生夕死”的，存活下来的会很少，

扫描了整个空间一次（标记存活对象并复制移动）。

缺点：需要另一块内存，

需要复制移动对象。

3.4、分代收集算法

分代收集算法就是目前虚拟机使用的回收算法，它解决了标记整理不适用于老年代的问题，将内存分为各个年代。一般情况下将堆区划分为老年代（Tenured Generation）和新生代（Young Generation），在堆区之外还有一个代就是永久代（Permanet Generation）。

在不同年代使用不同的算法，从而使用最合适的算法，新生代存活率低，可以使用复制算法。而老年代对象存活率搞，没有额外空间对它进行分配担保，所以只能使用标记清除或者标记整理算法。

4、回收器

垃圾回收器就是内存回收的体现，随着虚拟机的不断发展，主要的回收器有7种。SerialGC、ParNewGC、Parallel scavenge、Parallel old、CMS和G1等收集器。其主要工作区域如下图所示：
)

SerialGC

此收集器在为单线程的收集器，主要的收集区域是新生代。该收集器在工作时只能使用一个线程工作并且会停用其他的用户线程，直到它工作结束。此过程中则会产生“stop the world”。在Hotspot的client程序中使用，并且在限定CPU的情况下使用该收集器比较高效。（在单线程情况下没有线程之间的切换，所以可以获得高效的执行效率）

ParNew GC

ParNew收集器只是Serial收集器的一个多线程版本，其“Stop the world”、回收算法、回收策略等方式都与SerialGc收集器是相同的。但ParNew收集器是能在Server程序中回收新生代，除了Serial,ParNew是唯一一种与CMS配合工作的。

parallel scavenge

parallel scavenge与Parnew也是大相径庭，收集器工作区域为新生代、使用的回收算法为复制算法。parallel scavenge收集器的目的就是控制一个可控的吞吐量。吞吐量=运行用户代码时间/（GC占用时间+运行用户代码时间）。parallel scavenge提供两个jvm参数控制吞吐量。+Xx:MAXGcpauseMillis和GCTimeRatio。

MAXGcpauseMillis:可以设置一个大于0的参数。控制垃圾回收时间在设置时间范围内。Gc停顿时间是牺牲系统的吞吐量和新生代的空间来换取的。收集更小的新生代，肯定花费的时间也越小，这将导致垃圾收集越频繁。例如500Mb的新生代每10s回收一次，每次停顿100ms。减少到300MB后,每5s收集一次，一次停顿70ms。前者的吞吐量为99%,后者的吞吐量为98.6%。这种情况下吞吐量就下来了。所以在设置这个参数时,需要根据系统情况而定。
GCTimeRatio：参数取值范围为0~100的整数，即垃圾收集时间占用总时间的总数比例。相当于吞吐量的倒数。

SerialOldGC

SerialOldGC是Serial的老年代版本，也是使用单线程工作，使用标记整理算法。存在主要意义是提供给client模式下使用，在Server模式下，在jdk1.5之前和parallel scavenge配合使用；作为CNS的一个预选方案，在发生Concurrent mode failed使用。（promotion failed是在进行Minor GC时，survivor space放不下、对象只能放入旧生代，而此时旧生代也放不下造成的；concurrent mode failure是在执行CMS GC的过程中同时有对象要放入旧生代，而此时旧生代空间不足造成的。）

parallel old

老年代收集器，采用标记真理算法对垃圾进行回收，是parallel scavenge的老年代版本。若系统为吞吐量优先系统，则可以使用parallel old+parallel scavenge进行垃圾回收。

CMS

CMS是一款关注低停顿时间的收集器，它工作于老年代，采用标记清除算法进行垃圾回收。目前主要使用与注重用户体验好、服务器响应快的系统上。比如:电商等B/S后台系统。具体执行不走如下

1、初始标记：标记GC Roots关联的对象，会发生stop the world。
2、并发标记：执行GC roots Tracing,时间占用长，不会发生stop stop world。

3、重新标记： 标记在并发标记阶段产生的新对象，会发生stop the world

4、并发清除：清除的同时用户进程会导致新的垃圾，时间长，不发生用户进程停顿。

CMS的缺点：
1、老年代采用的标记清除算法，在每次收集完成后，会造成很大的内存碎片。当大对象分配时，应老年代连续的内存空间，不得不造成提前发生full gc。为了解决该问题，cms提供内存碎片整合参数UserCMSCompactAtFullCollection，但是带来的问题是停顿时间变长。
2、对CPU资源非常敏感。
3、对在清除时，用户进程新产生的垃圾无法清除。

G1

G1收集器将java堆分为大小相同的独立区间(region,大小为1~32M，最多可分配2000个，使用-XX:G1HeapRegionSize参数进行设置)，G1与CMS相比存在以下特点：

并发与并行：
利用多cpu和多核心的优势。使用多CPU来缩短STW时间。前面的收集器在GC过程中原来需要停顿的，G1使用并发的方式任然能让用户线程继续执行。

可预测停顿时间：G1建立了可预测时间模型，能指定在一段M毫秒的运行时间，消耗在Gc上的时间不超过N毫秒。应为它可以有计划的避免在GC标记是去扫描整个java堆，G1会跟踪整个region中垃圾价值大小，优先回收价值高的region

分代收集:：能独立管理整个GC堆（新生代和老年代），而不需要与其他收集器搭配；
能够采用不同方式处理不同时期的对象；
虽然保留分代概念，但Java堆的内存布局有很大差别；
将整个堆划分为多个大小相等的独立区域（Region）；
新生代和老年代不再是物理隔离，它们都是一部分Region（不需要连续）的集合；

空间整合:跟CMS相比，G1使用的是标记-整理算法。局部region之间使用的是复制算法。这两种方式在GC后都不会产生内存碎片，而是连续规整的内存空间，这种情况下不会因为无法分配大对象而内存空间不足。

G1执行步骤：

1、初始标记（Initial Marking）

仅标记一下GC Roots能直接关联到的对象；
且修改TAMS（Next Top at Mark Start）,让下一阶段并发运行时，用户程序能在正确可用的Region中创建新对象；

需要"Stop The World"，但速度很快；

2、并发标记（Concurrent Marking）
进行GC Roots Tracing的过程；
刚才产生的集合中标记出存活对象；
耗时较长，但应用程序也在运行；
并不能保证可以标记出所有的存活对象；

3、最终标记（Final Marking）

为了修正并发标记期间因用户程序继续运作而导致标记变动的那一部分对象的标记记录；
上一阶段对象的变化记录在线程的Remembered Set Log；
这里把Remembered Set Log合并到Remembered Set中；
需要"Stop The World"，且停顿时间比初始标记稍长，但远比并发标记短；
采用多线程并行执行来提升效率；

4、筛选回收（Live Data Counting and Evacuation）
首先排序各个Region的回收价值和成本；
然后根据用户期望的GC停顿时间来制定回收计划；
最后按计划回收一些价值高的Region中垃圾对象；
回收时采用"复制"算法，从一个或多个Region复制存活对象到堆上的另一个空的Region，并且在此过程中压缩和释放内存；
可以并发进行，降低停顿时间，并增加吞吐量。

使用场景：

面向服务端应用，针对具有大内存、多处理器的机器；

最主要的应用是为需要低GC延迟，并具有大堆的应用程序提供解决方案；

如：在堆大小约6GB或更大时，可预测的暂停时间可以低于0.5秒；

用来替换掉JDK1.5中的CMS收集器；

在下面的情况时，使用G1可能比CMS好：

（1）、超过50％的Java堆被活动数据占用；

（2）、对象分配频率或年代提升频率变化很大；

（3）、GC停顿时间过长（长于0.5至1秒）。

GC JVM参数

串行回收器相关的参数：

-XX:+UseSerialGC:在新生代和老年代使用串行收集器；

-XX:SurvivorRatio:设置eden区大小和survivior区大小的比例；

-XX:PretenureSizeThreshold:设置大对象直接进入老年代的阈值。当对象的大小超过这个值时，将直接在老年代分配；

-XX:MaxTenuringThreshold:设置对象进入老年代的年龄的最大值。每一次MinorGC后，对象年龄就加1。任何大于这个年龄的对象，一定会进入老年代；

与并行GC相关的参数：

-XX:+UseParNewGC:在新生代使用并行收集器；

-XX:+UseParallelOldGC:老年代使用并行回收收集器；

-XX:ParallelGCThreads:设置用于垃圾回收的线程数。通常情况下可以和CPU数量相等，但在CPU数量比较的情况下，设置相对较小的数值也是合理的；

-XX:MaxGCPauseMillis:设置最大垃圾收集停顿时间。它的值是一个大于0的整数。收集器在工作时，会调整Java堆大小或者其他一些参数，尽可能地把停顿时间控制在MaxGCPauseMillis以内；

-XX:GCTimeRation:设置吞吐量大小。它的值是一个0到100之间的整数。假设GCTimeRatio的值为n,那么系统将花费不超过1/（1+n）的时间用于垃圾收集；

-XX:+UseAdaptiveSizePolicy:打开自适应GC策略。在这种模式下，新生代的大小，eden和survivior的比例，晋升老年代的对象年龄等参数会被自动调整，以达到在堆大小，吞吐量和停顿时间之间的平衡点；

与CMS回收器相关的参数：

-XX:+UseConcMarkSweepGC:新生代使用并行收集器，老年代使用CMS+串行收集器。

-XX:+ParallelCMSThreads:设定CMS的线程数量；

-XX:CMSInitiatingOccupancyFraction:设置CMS收集器在老年代空间被使用多少后触发，默认为68%；

-XX:+UseCMSCompactAtFullCollection:设置CMS收集器在完成垃圾收集后是否要进行一次内存碎片的整理；

-XX:CMSFullGCsBeforeCompaction:设定进行多少次CMS垃圾回收后，进行一次内存压缩；

-XX:+CMSClassUnloadingEnabled:允许对元数据区进行回收；

-XX:UseCMSInitiatingPermOccupancyFraction:当永久区占用率达到这一百分比时，启动CMS回收（前提是-XX:+CMSClassUnloadingEnabled激活了）；

-XX:UseCMSInitiatingOccupancyOnly:表示只在到达阈值的时候才进行CMS回收；

-XX:CMSIncrementalMode:使用增量模式，比较适合单CPU。增量模式在JDK8中标记为废弃，并且将在JDK9中彻底移除；

与G1回收器相关的参数：

-XX:+UseG1GC:使用G1回收器；

-XX:MaxGCPauseMillis:设置最大垃圾收集停顿时间；

-XX:GCPauseIntervalMillis:设置停顿间隔时间；