Java虚拟机垃圾收集器

编程语言 2018-07-23 11:27:08 阅读次数: 0

一、概述

1.1 为什么要了解垃圾收集器

          目前内存的动态分配与内存回收技术已经相当成熟，一起看起来都进入“自动化”时代，那为什么还要去了解GC和内存分配呢，答案很简单：当需要排查各种内存溢出、内存泄露问题时，当垃圾收集成为系统达到更高并发量的瓶颈时，我们就需要要对这些“自动化”技术实施必要的监控和调节。

1.2 垃圾收集器主要关注哪部分内存

          之前的文章已经提到，Java内存运行时区域中的程序计数器、虚拟机栈、本地方法栈这3个线程独享的区域随线程而生，随线程而灭；栈中的栈帧随着方法的进入和退出而有条不紊地执行着出栈和入栈操作，每一个栈帧中分配多少内存基本上是在类结构确定下来时就已知的，因此这几个区域的内存分配和回收都具备确定性，在这几个区域内就不需要过多考虑回收的问题，因为方法结束或者线程结束时，内存自然就跟随着回收了。

         但是Java堆和方法区这2个共享区域则不一样，一个接口中的多个实现类需要的内存可能不一样，一个方法的多个分支需要的内存也可能不一样，我们在程序处于运行期间时才能知道会创建哪些对象，这部分内存分配和回收都是动态的，垃圾收集器所关注的就是这部分内存。

二、对象已死吗

          在堆里面存放着Java世界中几乎所有的对象实例，垃圾收集器在对堆进行回收前，第一件事情就是要确定这些对象之中哪些还“存活”着，哪些已经“死去”（即：不可能再被任何途径使用的对象）。

2.1 引用计数算法

           该算法是这样的：给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的。 

           主流的Java虚拟机里面没有选用引用计数算法来管理内存，因为算法有个缺陷：它很难解决对象之间相关相互循环引用的问题。举个简单的例子：

package GC;

public class ReferenceCountingGC {
	public Object instance = null;
	private static final int _1MB = 1024 * 1024;
	private byte[] bigSize = new byte[2 * _1MB];
	
	public static void main(String[] args) {
		ReferenceCountingGC objA = new ReferenceCountingGC();
		ReferenceCountingGC objB = new ReferenceCountingGC();
		objA.instance = objB;
		objB.instance = objA;
		objA = null;
		objB = null;
		System.gc();
	}
}

输出结果：

[GC (System.gc()) [PSYoungGen: 7424K->632K(38400K)] 7424K->640K(125952K), 0.0019997 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (System.gc()) [PSYoungGen: 632K->0K(38400K)] [ParOldGen: 8K->579K(87552K)] 640K->579K(125952K), [Metaspace: 2722K->2722K(1056768K)], 0.0081344 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 
Heap
 PSYoungGen      total 38400K, used 222K [0x00000000d5b80000, 0x00000000d8600000, 0x0000000100000000)
  eden space 33280K, 0% used [0x00000000d5b80000,0x00000000d5bb78e8,0x00000000d7c00000)
  from space 5120K, 0% used [0x00000000d7c00000,0x00000000d7c00000,0x00000000d8100000)
  to   space 5120K, 0% used [0x00000000d8100000,0x00000000d8100000,0x00000000d8600000)
 ParOldGen       total 87552K, used 579K [0x0000000081200000, 0x0000000086780000, 0x00000000d5b80000)
  object space 87552K, 0% used [0x0000000081200000,0x0000000081290e48,0x0000000086780000)
 Metaspace       used 2728K, capacity 4486K, committed 4864K, reserved 1056768K
  class space    used 300K, capacity 386K, committed 512K, reserved 1048576K

对象objA和objB都有字段instance，赋值令objA.instance=objB及objB.instance=objA，除此之外，这两个对象再无任何引用，实际上这两个对象已经不可能再访问了，但是它们因为相互引用着对方，导致它们的引用计数都不为0，于是引用计数器算法无法通知GC收集器回收它们。

          从运行结果来看,GC日志中

看出来，虚拟机并没有因为这两个对象相互引用就不回收它们，这也从侧面说明虚拟机并不是通过引用计数算法来判断对象是否存活的。 

2.2 可达性分析算法

          在主流的商用程序语言（Java、C#等等）的主流实现中，都是通过可达性分析（Reachability Analysis）来判定对象是否存活的。

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

在Java语言中，可作为GC Roots的对象包括下面几种：

  • 虚拟机栈（栈帧中的本地变量表）中引用的对象
  • 方法区中类静态属性引用的对象
  • 方法区中常量引用的对象
  • 本地方法栈中JNI（即：一般说的Native方法）引用的对象

2.3 引用分类 

          在JDK1.2之后，Java对引用的概念进行了扩充，将引用分为强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）、虚引用（Phantom Reference）4种，这4种引用强度依次逐渐减弱。

  • 强引用就是指在程序代码之中普遍存在的，类似“Object obj = new Object()”这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。
  • 软引用是用来描述一些还有用但并非必需的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。在JDK1.2之后，提供了SoftReference类来实现软引用。
  • 弱引用也是用来描述非必需对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。 在JDK1.2之后，提供了WeakReference类来实现弱引用。
  • 虚引用也称为幽灵引用或者幻影引用，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知，在JDK1.2之后，提供了PhantomReference类来实现虚引用。

2.4 回收方法区

          方法区（或者HotSpot虚拟机中的永久代）也是有垃圾收集的，只是相对堆中的对象回收来说，效率远远低于它。

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

         如果一个常量没有任何地方引用它，就称为废弃常量，如果发生了内存回收，将会被清理。（常量池中的其他类（接口）、方法、字段、字段的符号引用也与此类似）。

          判定一个常量是否是“废弃常量”比较简单，而要判定一个类是否是“无用的类”，则要满足下面3个条件：

  1. 该类所有的实例都已经被回收，也就是堆中不存在该类的任何实例
  2. 加载该类的ClassLoader已经被回收
  3. 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问到该类的方法

虚拟机可以对满足上述3个条件的无用类进行回收，但是仅仅是可以，而不是和对象一样，不使用了就必然会回收。 

三、垃圾收集算法 

3.1 标记-清除算法 

          该算法是最基础的算法，分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，，在标记完成后统一回收所有被标记的对象。之所以说它是最基础的收集算法，是因为后续的收集算法都是基于这种思路并对其不足进行改进而得到的。

          该算法有两个不足之处：

  1. 效率问题：标记和清除两个过程的效率都不高
  2. 空间问题：标记清楚之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

标记-清除算法的执行过程如下图：

3.2 复制算法    

         为解决效率问题，复制算法出现了，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当着一块的内存用完了，就将还存活的对象复制到另外一块上面，然后再把已使用过的内存空间一次清掉。 这样使得每次都是对整个半区进行内存回收，内存分配时就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为了原来的一半，在对象存活率较高时就要进行较多的复制操作，效率将会变低。

         复制算法的执行过程如下图：

             现在的商业虚拟机都采用这种收集算法来回收新生代，IBM公司的专门研究表明，新生代的对象98%是“朝生夕死”的，所以并不需要按照1:1比例来划分内存空间，而是将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor。当回收时，将Eden和Survivor中还存活的对象一次性地复制到另外一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。

             HotSpot虚拟机默认Eden和Survivor的大小比例是8:1，也就是每次新生代中可用内存空间为整个新生代容量的90%，只有10%的内存会被“空闲或者说“浪费。当然，98%的对象可回收只是一般场景下的数据，我们没有办法保证每次回收都只有不多于10%的对象存活，当Survivor空间不够用时，需要依赖其他内存(这里指老年代）进行分配担保，通过分配担保机制将这些对象进入老年代。

3.3 标记-整理算法

          复制收集算法在对象存活率较高是就要进行较多的复制操作，效率将会变低。更关键点额是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所有老年代一般不能直接选用这种算法。

           根据老年代的特点，有人提出了另外一种“标记-整理”（Mark-Compact）算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存，“标记-整理”算法的过程如下：

3.4 分代收集算法

          该算法是把Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。

          在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它对进行分配担保，就必须使用“标记-清理”或者“标记-整理”算法来进行回收。

注：新生代的GC（Minor GC）， 老年代的GC（Full GC）

四、垃圾收集器 

           如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。 

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

4.1 串行收集器（Serial收集器）

 串行收集器是最古老，最稳定以及效率高的收集器可能会产生较长的停顿，只使用一个线程去回收。

  参数控制：-XX:+UseSerialGC 串行收集器

   特点如下：

  • 新生代、老年代使用串行回收
  • 新生代复制算法
  • 老年代标记-压缩

串行收集器日志输出：

0.844: [GC 0.844: [DefNew: 17472K->2176K(19648K), 0.0188339 secs] 17472K->2375K(63360K), 0.0189186 secs] [Times: user=0.01 sys=0.00, real=0.02 secs]

8.259: [Full GC 8.259: [Tenured: 43711K->40302K(43712K), 0.2960477 secs] 63350K->40302K(63360K), [Perm : 17836K->17836K(32768K)], 0.2961554 secs] [Times: user=0.28 sys=0.02, real=0.30 secs]

4.2 并行收集器

4.2.1 ParNew收集器

参数控制：-XX:+UseParNewGC ParNew收集器（new代表新生代，所以适用于新生代）

  • 新生代并行
  • 老年代串行

                   -XX:ParallelGCThreads 限制线程数量

特点如下：

  • Serial收集器新生代的并行版本
  • 在新生代回收时使用复制算法
  • 多线程，需要多核支持

4.2.2 Parallel收集器

有以下几个特点：

  • 类似ParNew 
  • 新生代复制算法
  • 老年代标记-压缩 
  • 更加关注吞吐量 

    -XX:+UseParallelGC  

  • 使用Parallel收集器+ 老年代串行

-XX:+UseParallelOldGC 

  • 使用Parallel收集器+ 老年代并行

Parallel收集器的日志输出：

1.500: [Full GC [PSYoungGen: 2682K->0K(19136K)] [ParOldGen: 28035K->30437K(43712K)] 30717K->30437K(62848K) [PSPermGen: 10943K->10928K(32768K)], 0.2902791 secs] [Times: user=1.44 sys=0.03, real=0.30 secs]

4.3 CMS收集器

  • Concurrent Mark Sweep 并发标记清除（应用程序线程和GC线程交替执行）
  • 使用标记-清除算法
  • 并发阶段会降低吞吐量（停顿时间减少，吞吐量降低）
  • 老年代收集器（新生代使用ParNew）
  • -XX:+UseConcMarkSweepGC

CMS运行过程比较复杂，着重实现了标记的过程，可分为

1. 初始标记（会产生全局停顿）

  • 根可以直接关联到的对象
  • 速度快

2. 并发标记（和用户线程一起） 

  • 主要标记过程，标记全部对象

3. 重新标记 （会产生全局停顿） 

  • 由于并发标记时，用户线程依然运行，因此在正式清理前，再做修正

4. 并发清除（和用户线程一起） 

  • 基于标记结果，直接清理对象

这里就能很明显的看出，为什么CMS要使用标记清除而不是标记压缩，如果使用标记压缩，需要多对象的内存位置进行改变，这样程序就很难继续执行。但是标记清除会产生大量内存碎片，不利于内存分配。

CMS收集器的日志输出：

1.662: [GC [1 CMS-initial-mark: 28122K(49152K)] 29959K(63936K), 0.0046877 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
1.666: [CMS-concurrent-mark-start]
1.699: [CMS-concurrent-mark: 0.033/0.033 secs] [Times: user=0.25 sys=0.00, real=0.03 secs] 
1.699: [CMS-concurrent-preclean-start]
1.700: [CMS-concurrent-preclean: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
1.700: [GC[YG occupancy: 1837 K (14784 K)]1.700: [Rescan (parallel) , 0.0009330 secs]1.701: [weak refs processing, 0.0000180 secs] [1 CMS-remark: 28122K(49152K)] 29959K(63936K), 0.0010248 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
1.702: [CMS-concurrent-sweep-start]
1.739: [CMS-concurrent-sweep: 0.035/0.037 secs] [Times: user=0.11 sys=0.02, real=0.05 secs] 
1.739: [CMS-concurrent-reset-start]
1.741: [CMS-concurrent-reset: 0.001/0.001 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

CMS收集器特点：

尽可能降低停顿
会影响系统整体吞吐量和性能

  • 比如，在用户线程运行过程中，分一半CPU去做GC，系统性能在GC阶段，反应速度就下降一半

清理不彻底 

  • 因为在清理阶段，用户线程还在运行，会产生新的垃圾，无法清理

因为和用户线程一起运行，不能在空间快满时再清理（因为也许在并发GC的期间，用户线程又申请了大量内存，导致内存不够） 

  • -XX:CMSInitiatingOccupancyFraction设置触发GC的阈值
  • 如果不幸内存预留空间不够，就会引起concurrent mode failure
33.348: [Full GC 33.348: [CMS33.357: [CMS-concurrent-sweep: 0.035/0.036 secs] [Times: user=0.11 sys=0.03, real=0.03 secs] 
 (concurrent mode failure): 47066K->39901K(49152K), 0.3896802 secs] 60771K->39901K(63936K), [CMS Perm : 22529K->22529K(32768K)], 0.3897989 secs] [Times: user=0.39 sys=0.00, real=0.39 secs]

一旦 concurrent mode failure产生，将使用串行收集器作为后备。

CMS也提供了整理碎片的参数：

-XX:+ UseCMSCompactAtFullCollection Full GC后，进行一次整理

  • 整理过程是独占的，会引起停顿时间变长

-XX:+CMSFullGCsBeforeCompaction  

  • 设置进行几次Full GC后，进行一次碎片整理

-XX:ParallelCMSThreads 

  • 设定CMS的线程数量（一般情况约等于可用CPU数量）

CMS的提出是想改善GC的停顿时间，在GC过程中的确做到了减少GC时间，但是同样导致产生大量内存碎片，又需要消耗大量时间去整理碎片，从本质上并没有改善时间。

4.4 G1收集器

G1是目前技术发展的最前沿成果之一，HotSpot开发团队赋予它的使命是未来可以替换掉JDK1.5中发布的CMS收集器。

与CMS收集器相比G1收集器有以下特点：

1. 空间整合，G1收集器采用标记整理算法，不会产生内存空间碎片。分配大对象时不会因为无法找到连续空间而提前触发下一次GC。

2. 可预测停顿，这是G1的另一大优势，降低停顿时间是G1和CMS的共同关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为N毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已经是实时Java（RTSJ）的垃圾收集器的特征了。

上面提到的垃圾收集器，收集的范围都是整个新生代或者老年代，而G1不再是这样。使用G1收集器时，Java堆的内存布局与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔阂了，它们都是一部分（可以不连续）Region的集合。

G1的新生代收集跟ParNew类似，当新生代占用达到一定比例的时候，开始出发收集。

和CMS类似，G1收集器收集老年代对象会有短暂停顿。

步骤：

  1. 标记阶段，首先初始标记(Initial-Mark),这个阶段是停顿的(Stop the World Event)，并且会触发一次普通Mintor GC。对应GC log:GC pause (young) (inital-mark)
  2. Root Region Scanning，程序运行过程中会回收survivor区(存活到老年代)，这一过程必须在young GC之前完成。
  3. Concurrent Marking，在整个堆中进行并发标记(和应用程序并发执行)，此过程可能被young GC中断。在并发标记阶段，若发现区域对象中的所有对象都是垃圾，那个这个区域会被立即回收(图中打X)。同时，并发标记过程中，会计算每个区域的对象活性(区域中存活对象的比例)。
  4. Remark, 再标记，会有短暂停顿(STW)。再标记阶段是用来收集 并发标记阶段 产生新的垃圾(并发阶段和应用程序一同运行)；G1中采用了比CMS更快的初始快照算法:snapshot-at-the-beginning (SATB)。
  5. Copy/Clean up，多线程清除失活对象，会有STW。G1将回收区域的存活对象拷贝到新区域，清除Remember Sets，并发清空回收区域并把它返回到空闲区域链表中。
  6. 复制/清除过程后。回收区域的活性对象已经被集中回收到深蓝色和深绿色区域。

五、常用的垃圾收集器组合 

  新生代GC策略 老年老代GC策略 说明
组合1 Serial Serial Old Serial和Serial Old都是单线程进行GC，特点就是GC时暂停所有应用线程。
组合2 Serial CMS+Serial Old CMS（Concurrent Mark Sweep）是并发GC，实现GC线程和应用线程并发工作，不需要暂停所有应用线程。另外，当CMS进行GC失败时，会自动使用Serial Old策略进行GC。
组合3 ParNew CMS 使用 -XX:+UseParNewGC选项来开启。ParNew是Serial的并行版本，可以指定GC线程数，默认GC线程数为CPU的数量。可以使用-XX:ParallelGCThreads选项指定GC的线程数。如果指定了选项 -XX:+UseConcMarkSweepGC选项，则新生代默认使用ParNew GC策略。
组合4 ParNew Serial Old 使用 -XX:+UseParNewGC选项来开启。新生代使用ParNew GC策略，年老代默认使用Serial Old GC策略。
组合5 Parallel Scavenge Serial Old Parallel Scavenge策略主要是关注一个可控的吞吐量：应用程序运行时间 / (应用程序运行时间 + GC时间)，可见这会使得CPU的利用率尽可能的高，适用于后台持久运行的应用程序，而不适用于交互较多的应用程序。
组合6 Parallel Scavenge Parallel Old Parallel Old是Serial Old的并行版本
组合7 G1GC G1GC -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC #开启； -XX:MaxGCPauseMillis=50 #暂停时间目标； -XX:GCPauseIntervalMillis=200 #暂停间隔目标； -XX:+G1YoungGenSize=512m #年轻代大小； -XX:SurvivorRatio=6 #幸存区比例

Reference：

1. 《深入理解Java虚拟机》 

2. https://my.oschina.net/hosee/blog/644618

猜你喜欢

转载自blog.csdn.net/cb_lcl/article/details/81152478
今日推荐
《美国对全球网络空间安全与发展的威胁和破坏》报告发布
火速冲上 GitHub 热榜 —— 开源编程语言、框架哪有这么可爱？
北京人形机器人创新中心发布全球首个纯电驱拟人奔跑的全尺寸人形机器人“天工”
LFOSSA 源来如此公开课 | 掌握云原生未来：CNCF 认证全面攻略与备考秘籍
国产云输入法——仅华为无云端数据上传安全问题
周排行
Python环境安装与基础语法（1）——计算机基础知识
IMU预积分
ADAS中的LDW、FCW、BSD、LCA、ACC、AEB、APA、DMS代表的含义
B站笔试两道题
skyeye arm 硬件虚拟机环境的搭建
Web前端静态页面示例
数组-合并排序数组 II-简单
springcloud之版本问题启动报错
面向对象-------------匿名对象(六)
输入URL到页面呈现中间发生了什么？
每日归档
更多
2024-04-30(1)
2024-04-29(40)
2024-04-28(0)
2024-04-27(56)
2024-04-26(39)
2024-04-25(22)
2024-04-24(36)
2024-04-23(26)
2024-04-22(39)
2024-04-21(0)

代码天地 © 2018 codetd.com

境外服务器   最新电视剧2022