JVM-垃圾回收机制

JVM-垃圾回收机制

Java和C++最大的区别：Java拥有内存动态分配和垃圾自动回收机制

自动内存管理=内存动态分配+垃圾回收机制

垃圾回收（GC）要完成：

1.哪些内存需要回收------应用GC的区域（Java堆和方法区）

2.什么时候进行回收------如何判断对象已死？

3.如何回收-------垃圾回收算法+垃圾收集器

**程序计数栈、虚拟机栈、本地方法栈三个区域，线程创建时分配内存，线程销毁时内存回收，因此其内存的分配和回收是确定的，不需要GC

如何判断对象已死？

1.引用计数算法：给每个对象添加一个引用计数器，当有一个地方引用它时，计数器值+1；当引用失效时，计数器值-1；任何时候计数器值为0的对象就是不能被再使用的。

缺点：无法解决对象之间相互循环引用的问题

Java语言不采用该方法。

2.根搜索算法：通过一系列名为 “GC Roots” 的对象作为起始点，从这些结点开始向下搜索，搜索走过的路径称为“引用链”，当一个对象到 GC Roots 没有任何引用链相连时，则证明该对象是不可用的。（用图论的话来说就是从GC Roots到该对象不可达）

Java中可作为GC Roots的对象包括：

​ （1）虚拟机栈中引用的对象

​ （2）方法区中的类静态属性引用的对象

​ （3）方法区中的常量引用的对象

​ （4）本地方法栈中JNI（Native方法）的引用的对象

四种引用

1.强引用（Strong Reference）：即最普遍的类似于 Object obj = new Object() 这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象

2.软引用（Soft Reference）：用来描述一些还有用但并非必需的对象，通过SoftReference类来实现软引用。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列入回收范围并进行第二次回收，如果这次回收完成后仍没有足够的内存才会抛出内存溢出异常。

3.弱引用（Week Reference）：用来描述并非必需的对象，但其强度弱于软引用，通过WeekReference类来实现弱引用。被弱引用关联的对象只能存活到下一次垃圾收集发生之前，当垃圾收集器进行工作时，无论内存是否足够都会回收掉被软引用关联的对象。

4.虚引用（PhantomReference）：也称为幽灵引用或幻影引用，是最弱的一种引用关系，通过PhantomReference类实现虚引用。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得对象实例。为一个对象设置虚引用关联的唯一目的就是希望在这个对象被收集器回收时受到一个系统通知。

方法区的垃圾回收

永久代的垃圾收集主要回收两部分内容：废弃常量和无用的类

废弃常量：类似于回收Java堆中的对象

能称为“无用的类”的类应满足：
（1）该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例

​ （2）加载该类的ClassLoader已经被回收

​ （3）该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类 的方法

虚拟机可以对无用的类进行回收（但并不一定回收，可以通过参数设置是否回收）

垃圾收集算法

1.标记-清除算法（主要用于老年代）

思想：首先标记出所有需要回收的对象，在标记完成后统一回收掉所有被标记的对象

缺点：

​ （1）效率问题：标记和清除的效率不高

​ （2）空间问题：标记清除之后会产生大量不连续的内存碎片，可能会导致在需要分配较大对象时 没有足够的连续空间，进而不得不触发另一次的垃圾收集

2.复制算法

思想：将内存划分为两块，每次使用其中的一块，当这一块的内存用完了需要进行垃圾回收时，将该块上还存活着的对象复制到另一块上，然后把该块一次清理掉

优点：不会存在内存碎片的问题

缺点：内存缩小为原来的一半

3.改进的复制算法（主要用于新生代的垃圾收集）

思想：新生代的对象98%都是朝生夕死的，因此不需要按照1：1的比例划分内存，而是将内存划分为一块较大的 Eden空间（80%） 和两块较小的 Survivor空间（10%*2），每次使用Eden和一个Survivor。回收时将Eden和Survivor中还存活着的对象复制到另一个Survivor上，，最后清理掉Eden和已使用的Survivor空间。当Survivor空间不够用时，需要依赖其他内存（这里指老年代）进行分配担保。

4.标记-整理算法（主要用于老年代）

思想：首先标记出所有需要回收的对象（与标记-清除算法相同），让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存

5.分代收集算法：

思想：根据对象的存活周期的不同将内存划分为几块。一般将Java堆分为新生代和老年代，然后根据各个年代的特点选用最适当的收集算法

当前商业虚拟机的垃圾收集都采用分代收集算法

垃圾收集器

（Java虚拟机规范没有规定如何实现垃圾收集器，因此不同的厂商、不同版本的虚拟机所提供的垃圾收集器可能差别很大，并且一般都会根据参数供用户根据自己的应用特点和要求组合出各个年代所使用的收集器，没有最好的万能的收集器）

1.Serial收集器

特点：单线程，使用一个CPU或一条收集线程去完成垃圾收集工作，并且在它进行垃圾收集时，必须暂停其他所有的工作线程（Stop the world），直到它收集结束。

缺点：把用户的工作线程暂停掉，这对很多应用来说是难以忍受的

优点：没有线程交互的开销，可以获得较高的单线程收集效率

使用：运行在Client模式下的虚拟机的新生代

算法：复制算法

2.ParNew收集器

特点：相当于Serial收集的多线程版本，进行收集时也会暂停其他所有的工作线程

缺点：需要暂停其他所有的工作线程；会带来线程交互的开销

优点：随着CPU数量的增加，对于GC时系统资源的利用有好处

使用：运行在Server模式下的虚拟机的新生代

算法：复制算法

3.Parallel Scavenge收集器（吞吐量优先收集器）

特点：并行的多线程收集器，关注点在于达到一个可控制的吞吐量（吞吐量=CPU用于运行用户代码的时间与CPU总消耗时间的比值，高吞吐量可以更高效率地利用CPU时间），可以自定义参数来精确控制吞吐量，也可以采用 GC自适应的调节策略（虚拟机根据当前系统的运行状况收集性能监控信息，动态调整参数以提供最合适的停顿时间或最大的吞吐量）

使用：新生代收集器

算法：复制算法

4.Serial Old收集器

特点：Serial的老年代版本，单线程，进行收集时暂停其他所有的工作线程

使用：运行于Client模式下的虚拟机的老年代

算法：标记-整理算法

5.Parallel Old收集器

特点：Parallel Scavenge收集器的老年代版本，多线程，进行收集时暂停其他所有工作线程

使用：老年代收集器，与Parallel Scavenge配合时多用于注重吞吐量和CPU资源敏感的场合

算法：标记-整理算法

6.CMS收集器（并发低停顿收集器）

特点：Concurrent Mark Sweep，以获取最短回收停顿时间为目标

过程：

​ （1）初始标记：需要暂停用户进程，仅标记一下GC Roots能直接关联到的对象，速度很快

​ （2）并发标记：不需要暂停用户进程，进行Roots Tracing

​ （3）重新标记：需要暂停用户进程，修正并发标记期间因用户程序继续运作而导致标记产生变动 的那一部分对象的标记记录

​ （4）并发清除：不需要暂停用户进程

优点：并发收集，低停顿

缺点：

​ （1）对CPU资源敏感：并发阶段会占用一部分CPU资源从而导致应用进程变慢，总吞吐量降低

​ （2）无法处理浮动垃圾，可能出现Concurrent Mode Failure失败而导致另一次Full GC的产生

​ 浮动垃圾：由于CMS并发清除阶段用户进程还在运行，这一阶段产生的垃圾称为浮动垃圾

​ 因此不能等内存被填满了在收集，需要预留出足够的空间给用户线程使用

​ （3）会产生内存碎片------解决：在执行完 Full GC 后附送一个碎片整理过程

使用：老年代

算法：标记-清除算法

7.G1收集器

特点：避免全区域的垃圾收集，而是将整个Java堆（新生代+老年代）划分为多个大小固定的独立区域，并跟踪这些区域里的垃圾堆积程度，在后台维护一个优先列表，每次根据允许的收集时间，优先回收垃圾最多的区域

优点：不会产生内存碎片，能精确地控制停顿（实时Java（RTSJ）的垃圾收集器的特征）

算法：标记-整理算法