jvmGC回收机制（垃圾回收器经典算法）（JVM中内存区域的划分）（GC收集器有哪些）

Minor GC触发条件&＃xff1a;当Eden区满时&＃xff0c;触发Minor GC。

Full GC触发条件&＃xff1a;

1. 调用System.gc()时&＃xff0c;系统建议执行Full GC&＃xff0c;但是不必然执行
2. 老年代空间不足
3. 方法区空间不足
4. 通过Minor GC后进入老年代的平均大小大于老年代的可用内存
5. 由Eden区、From Space区向To Space区复制时&＃xff0c;对象大小大于To Space可用内存&＃xff0c;则把该对象转存到老年代&＃xff0c;且老年代的可用内存小于该对象大小

 - 伊甸园&＃xff08;Eden&＃xff09;&＃xff1a;这是对象最初诞生的区域&＃xff0c;并且对大多数对象来说&＃xff0c;这里是它们唯一存在过的区域。 
 - 幸存者乐园&＃xff08;Survivor&＃xff09;&＃xff1a;从伊甸园幸存下来的对象会被挪到这里。 
 - 终身颐养园&＃xff08;Tenured&＃xff09;&＃xff1a;这是足够老的幸存对象的归宿。年轻代收集&＃xff08;Minor-GC&＃xff09;过程是不会触及这个地方的。当年轻代收集不能把对象放进终身颐养园时&＃xff0c;就会触发一次完全收集&＃xff08;Major-GC&＃xff09;&＃xff0c;这里可能还会牵扯到压缩&＃xff0c;以便为大对象腾出足够的空间。

1、 可达性分析法&＃xff1a;通过一系列“GC Roots”对象作为起点进行搜索&＃xff0c;如果在“GC Roots”和一个对象之间没有可达路径&＃xff0c;则称该对象是不可达的。不可达对象不一定会成为可回收对象。进入DEAD状态的线程还可以恢复&＃xff0c;GC不会回收它的内存。&＃xff08;把一些对象当做root对象&＃xff0c;JVM认为root对象是不可回收的&＃xff0c;并且root对象引用的对象也是不可回收的&＃xff09;
2、 以下对象会被认为是root对象&＃xff1a;
&＃xff08;1&＃xff09; 虚拟机栈&＃xff08;栈帧中本地变量表&＃xff09;中引用的对象
&＃xff08;2&＃xff09; 方法区中静态属性引用的对象
&＃xff08;3&＃xff09; 方法区中常量引用的对象
&＃xff08;4&＃xff09; 本地方法栈中Native方法引用的对象
3、 对象被判定可被回收&＃xff0c;需要经历两个阶段&＃xff1a;
&＃xff08;1&＃xff09; 第一个阶段是可达性分析&＃xff0c;分析该对象是否可达
&＃xff08;2&＃xff09; 第二个阶段是当对象没有重写finalize()方法或者finalize()方法已经被调用过&＃xff0c;虚拟机认为该对象不可以被救活&＃xff0c;因此回收该对象。&＃xff08;finalize()方法在垃圾回收中的作用是&＃xff0c;给该对象一次救活的机会&＃xff09;
4、 方法区中的垃圾回收&＃xff1a;
&＃xff08;1&＃xff09; 常量池中一些常量、符号引用没有被引用&＃xff0c;则会被清理出常量池
&＃xff08;2&＃xff09; 无用的类&＃xff1a;被判定为无用的类&＃xff0c;会被清理出方法区。判定方法如下&＃xff1a;
A、 该类的所有实例被回收
B、 加载该类的ClassLoader被回收
C、 该类的Class对象没有被引用
5、 finalize():
&＃xff08;1&＃xff09; GC垃圾回收要回收一个对象的时候&＃xff0c;调用该对象的finalize()方法。然后在下一次垃圾回收的时候&＃xff0c;才去回收这个对象的内存。
&＃xff08;2&＃xff09; 可以在该方法里面&＃xff0c;指定一些对象在释放前必须执行的操作。

二、 发现虚拟机频繁full GC时应该怎么办&＃xff1a;
&＃xff08;full GC指的是清理整个堆空间&＃xff0c;包括年轻代和永久代&＃xff09;
&＃xff08;1&＃xff09; 首先用命令查看触发GC的原因是什么 jstat –gccause 进程id
&＃xff08;2&＃xff09; 如果是System.gc()&＃xff0c;则看下代码哪里调用了这个方法
&＃xff08;3&＃xff09; 如果是heap inspection(内存检查)&＃xff0c;可能是哪里执行jmap –histo[:live]命令
&＃xff08;4&＃xff09; 如果是GC locker&＃xff0c;可能是程序依赖的JNI库的原因

GC目的&＃xff1a;回收堆内存中不再使用的对象&＃xff0c;释放资源
回收时间&＃xff1a;当对象永久地失去引用后&＃xff0c;系统会在合适的时候回收它所占的内存。

  GC System.gc()或Runtime.getRuntime().gc()&＃xff0c;

忘记或者错误的内存回收会导致程序或系统的不稳定甚至崩溃&＃xff0c;Java提供的GC功能可以自动监测对象是否超过作用域从而达到自动回收内存的目的。垃圾回收可以有效的防止内存泄露&＃xff0c;有效的使用可以使用的内存。

1.serial收集器&＃xff08;用于新生代&＃xff09;

单线程&＃xff0c;工作时必须暂停其他工作线程。多用于client机器上&＃xff0c;使用复制算法

单线程&＃xff0c;在进行垃圾收集时必须暂停其他所有的工作线程&＃xff08;"Stop the World"&＃xff09;。虚拟机运行在Client模式下的默认新生代收集器。简单而高效&＃xff08;与其他收集器的单线程比&＃xff09;&＃xff0c;对于限定单个CPU的环境来说&＃xff0c;Serial收集器由于没有线程交互的开销&＃xff0c;专心做垃圾收集自然可以获得最高的单线程效率。

2.ParNew收集器&＃xff08;新生代&＃xff09;

serial收集器的多线程版本&＃xff0c;server模式下虚拟机首选的新生代收集器。复制算法

ParNew收集器其实是Serial收集器的多线程版本&＃xff0c;它是许多运行在Server模式下的虚拟机中首选的新生代收集器&＃xff0c;因为除了Serial收集器外&＃xff0c;目前只有它能与CMS收集器配合工作。

3.Parallel Scavenge收集器&＃xff08;“吞吐量优先”收集器&＃xff09;&＃xff08;新生代&＃xff09;

复制算法&＃xff0c;可控制吞吐量的收集器。吞吐量即有效运行时间。

  使用复制算法&＃xff0c;并行多线程&＃xff0c;这些特点与ParNew一样&＃xff0c;它的独特之处是它的关注点与其他收集器不同&＃xff0c;CMS等收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间&＃xff0c;而Parallel Scavenge收集器的目的则是达到一个可控制的吞吐量&＃xff08;Throughput&＃xff09;,即CPU用于运行用户代码的时间与CPU总消耗时间的比值&＃xff0c;吞吐量&＃61;运行用户代码时间 /&＃xff08;运行用户代码时间&＃43;垃圾收集时间&＃xff09;&＃xff0c;虚拟机总共运行了100分钟&＃xff0c;其中垃圾收集花掉1分钟&＃xff0c;吞吐量就是99%。

       停顿时间越短对于需要与用户交互的程序来说越好&＃xff0c;良好的响应速度能提升用户的体验&＃xff1b;

       高吞吐量可以最高效率地利用CPU时间&＃xff0c;尽快地完成程序的运算任务&＃xff0c;主要适合在后台运算而不太需要太多交互的任务。

参数设置&＃xff1a;

-XX:MaxGCPauseMillis 控制最大垃圾收集停顿时间。&＃xff08;大于0的毫秒数&＃xff09;停顿时间缩短是以牺牲吞吐量和新生代空间换取的。&＃xff08;新生代调的小&＃xff0c;吞吐量跟着小&＃xff0c;垃圾收集时间就短&＃xff0c;停顿就小&＃xff09;。

-XX:GCTimeRatio 直接设置吞吐量大小&＃xff0c;0

-XX:&＃43;UseAdaptiveSizePolicy  一个开关参数&＃xff0c;开启GC自适应调节策略&＃xff08;GC Ergonomics&＃xff09;,将内存管理的调优任务&＃xff08;新生代大小-Xmn、Eden与Survivor区的比例-XX:SurvivorRatio、晋升老年代对象年龄-XX: PretenureSizeThreshold 、等细节参数&＃xff09;交给虚拟机完成。这是Parallel Scavenge收集器与ParNew收集器的一个重要区别&＃xff0c;另一个是吞吐量。

4.Serial Old收集器&＃xff08;老年代&＃xff09;

它是Serial收集器的老年代版本&＃xff0c;单线程&＃xff0c;使用“标记-整理”算法。主要意义是被Client模式下的虚拟机使用。如果在Server模式下&＃xff0c;它还有两大用途&＃xff1a;在JDK1.5及之前的版本中与Parallel Scavenge收集器搭配使用&＃xff1b;作为CMS 收集器的后备预案&＃xff0c;在并发收集发生Concurrent Mode Failure的时候使用。运行过程同Serial收集器。

serial的老年代版本&＃xff0c;使用整理算法。

5.Parallel Old收集器&＃xff08;老年代&＃xff09;

第三种收集器的老年代版本&＃xff0c;多线程&＃xff0c;标记整理

它是Parallel Scavenge收集器的老年代版本&＃xff0c;多线程&＃xff0c;使用“标记-整理”算法。在注重吞吐量及CPU资源敏感的场合&＃xff0c;都可以优先考虑Parallel Scavenge&＃43;Parallel Old收集器。工作过程如下&＃xff1a;

6.CMS收集器

它是一种以获取最短回收停顿时间为目标的收集器。优点&＃xff1a;并发收集&＃xff0c;低停顿。基于“标记-清除”算法。目前很大一部分Java应用都集中在互联网站或B/S系统的服务端上&＃xff0c;这类应用尤其重视服务的响应速度&＃xff0c;希望系统停顿时间最短&＃xff0c;以给用户带来较好的体验&＃xff0c;CMS收集器就非常符合这类应用的需求。运作过程较复杂&＃xff0c;分为4个步骤&＃xff1a;

初始标记&＃xff08;CMS initial mark&＃xff09;:需要“Stop The World”&＃xff0c;标记GC Roots能直接关联到的对象&＃xff0c;速度快。
并发标记&＃xff08;CMS concurrent mark&＃xff09;&＃xff1a;进行GC Roots Tracing 过程
重新标记&＃xff08;CMS remark&＃xff09;&＃xff1a;需要“Stop The World”,修正并发标记期间&＃xff0c;因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录。停顿时间&＃xff1a;初始标记<重新标记<<并发标记
并发清除&＃xff08;CMS concurrent sweep&＃xff09;&＃xff1a;时间较长。

缺点&＃xff1a;

对CPU资源非常敏感&＃xff0c;面向并发设计的程序都会对CPU资源较敏感。CMS默认的回收线程数: &＃xff08;CPU数量&＃43;3&＃xff09;/4

无法处理浮动垃圾&＃xff0c;可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。并发清理阶段用户程序运行产生的垃圾过了标记阶段所以无法在本次收集中清理掉&＃xff0c;称为浮动垃圾。CMS收集器默认在老年代使用了68%的空间后被激活。若老年代增长的不是很快&＃xff0c;可以适当调高参数-XX:CMSInitiatingOccupancyFraction  提高触发百分比&＃xff0c;但调得太高会容易导致“Concurrent Mode Failure”失败。

基于“标记-清除”算法会产生大量空间碎片。提供开关参数-XX:&＃43;UseCMSCompactAtFullCollection 用于在“ 享受”完Full GC服务之后进行碎片整理过程&＃xff0c;内存整理的过程是无法并发的。但是停顿时间会变长。

-XX:CMSFullGCsBeforeCompation 设置在执行多少次不压缩的Full GC后&＃xff0c;跟来来一次带压缩的。
 

目标是最短回收停顿时间。7.G1收集器,基本思想是化整为零&＃xff0c;将堆分为多个Region&＃xff0c;优先收集回收价值最大的Region。

G1收集器&＃xff08;Garbage First

它是当前收集器技术发展的最前沿成果。与CMS相比有两个显著改进&＃xff1a;

基于“标记-整理”算法实现收集器
非常精确地控制停顿
G1收集器可以在几乎不牺牲吞吐量的前提下完成低停顿的内存回收&＃xff0c;这是由于它能够极力避免全区域的垃圾收集&＃xff0c;之前的收集器进行收集的范围都是整个新生代或老年代&＃xff0c;而G1将整个Java堆&＃xff08;包括新生代、老年代&＃xff09;划分为多个大小固定的独立区域&＃xff08;Region&＃xff09;&＃xff0c;并且跟踪这些区域里面的垃圾堆积程度&＃xff0c;在后台维护一个优先列表&＃xff0c;每次根据允许的收集时间&＃xff0c;优先回收垃圾最多的区域&＃xff08;这就是Garbage First名称的由来&＃xff09;。区域划分、有优先级的区域回收&＃xff0c;保证了G1收集器在有限的时间内可以获得最高的收集效率。

 CMS收集器&＃xff1a;

&＃xff08;1&＃xff09;一种以获取最短回收停顿时间为目标的收集器。
&＃xff08;2&＃xff09;一般用于互联网站或者B/S系统的服务端
&＃xff08;3&＃xff09;基于标记-清除算法的实现&＃xff0c;不过更为复杂&＃xff0c;整个过程为4个步骤&＃xff1a;

A、初始标记&＃xff1a;标记GC Root能直接引用的对象
B、并发标记&＃xff1a;利用多线程对每个GC Root对象进行tracing搜索&＃xff0c;在堆中查找其下所有能关联到的对象。
C、重新标记&＃xff1a;为了修正并发标记期间&＃xff0c;用户程序继续运作而导致标志产生变动的那一部分对象的标记记录。
D、并发清除&＃xff1a;利用多个线程对标记的对象进行清除

&＃xff08;4&＃xff09;由于耗时最长的并发标记和并发清除操作都是用户线程一起工作&＃xff0c;所以总体来说&＃xff0c;CMS的内存回收工作是和用户线程一起并发执行的。
&＃xff08;5&＃xff09;缺点&＃xff1a; 

A、对CPU资源占用比较多。可能因为占用一部分CPU资源导致应用程序响应变慢。
B、CMS无法处理浮动垃圾。在并发清除阶段&＃xff0c;用户程序继续运行&＃xff0c;可能产生新的内存垃圾&＃xff0c;
这一部分垃圾出现在标记过程之后&＃xff0c;因此&＃xff0c;CMS无法清除。这部分垃圾称为“浮动垃圾“
C、需要预留一部分内存&＃xff0c;在垃圾回收时&＃xff0c;给用户程序使用。
D、基于标记-清除算法&＃xff0c;容易产生大量内存碎片&＃xff0c;导致full GC&＃xff08;full GC进行内存碎片的整理&＃xff09;
JVM中内存区域的划分

 1&＃xff0c;程序计数器&＃xff08;Program Counter Register&＃xff09;&＃xff1a;程序计数器是一个比较小的内存区域&＃xff0c;用于指示当前线程所执行的字节码执行到了第几行&＃xff0c;可以理解为是当前线程的行号指示器。字节码解释器在工作时&＃xff0c;会通过改变这个计数器的值来取下一条语句指令。
 每个程序计数器只用来记录一个线程的行号&＃xff0c;所以它是线程私有&＃xff08;一个线程就有一个程序计数器&＃xff09;的。
   如果程序执行的是一个Java方法&＃xff0c;则计数器记录的是正在执行的虚拟机字节码指令地址&＃xff1b;如果正在执行的是一个本地&＃xff08;native&＃xff0c;由C语言编写 完成&＃xff09;方法&＃xff0c;则计数器的值为Undefined&＃xff0c;由于程序计数器只是记录当前指令地址&＃xff0c;所以不存在内存溢出的情况&＃xff0c;因此&＃xff0c;程序计数器也是所有JVM内存区 域中唯一一个没有定义OutOfMemoryError的区域。

  2&＃xff0c;虚拟机栈&＃xff08;JVM Stack&＃xff09;&＃xff1a;一个线程的每个方法在执行的同时&＃xff0c;都会创建一个栈帧&＃xff08;Statck Frame&＃xff09;&＃xff0c;栈帧中存储的有局部变量表、操作站、动态链接、方法出口等&＃xff0c;当方法被调用时&＃xff0c;栈帧在JVM栈中入栈&＃xff0c;当方法执行完成时&＃xff0c;栈帧出栈。
   局部变量表中存储着方法的相关局部变量&＃xff0c;包括各种基本数据类型&＃xff0c;对象的引用&＃xff0c;返回地址等。在局部变量表中&＃xff0c;只有long和double类型会占用2个局部变量空间&＃xff08;Slot&＃xff0c;对于32位机器&＃xff0c;一个Slot就是32个bit&＃xff09;&＃xff0c;其它都是1个Slot。需要注意的是&＃xff0c;局部变量表是在编译时就已经确定 好的&＃xff0c;方法运行所需要分配的空间在栈帧中是完全确定的&＃xff0c;在方法的生命周期内都不会改变。
   虚拟机栈中定义了两种异常&＃xff0c;如果线程调用的栈深度大于虚拟机允许的最大深度&＃xff0c;则抛出StatckOverFlowError&＃xff08;栈溢出&＃xff09;&＃xff1b;不过多 数Java虚拟机都允许动态扩展虚拟机栈的大小(有少部分是固定长度的)&＃xff0c;所以线程可以一直申请栈&＃xff0c;知道内存不足&＃xff0c;此时&＃xff0c;会抛出 OutOfMemoryError&＃xff08;内存溢出&＃xff09;。
   每个线程对应着一个虚拟机栈&＃xff0c;因此虚拟机栈也是线程私有的。

  3&＃xff0c;本地方法栈&＃xff08;Native Method Statck&＃xff09;&＃xff1a;本地方法栈在作用&＃xff0c;运行机制&＃xff0c;异常类型等方面都与虚拟机栈相同&＃xff0c;唯一的区别是&＃xff1a;虚拟机栈是执行Java方法的&＃xff0c;而本地方法栈是用来执行native方法的&＃xff0c;在很多虚拟机中&＃xff08;如Sun的JDK默认的HotSpot虚拟机&＃xff09;&＃xff0c;会将本地方法栈与虚拟机栈放在一起使用。
  本地方法栈也是线程私有的。

  4&＃xff0c;堆区&＃xff08;Heap&＃xff09;&＃xff1a;堆区是理解Java GC机制最重要的区域&＃xff0c;没有之一。在JVM所管理的内存中&＃xff0c;堆区是最大的一块&＃xff0c;堆区也是Java GC机制所管理的主要内存区域&＃xff0c;堆区由所有线程共享&＃xff0c;在虚拟机启动时创建。堆区的存在是为了存储对象实例&＃xff0c;原则上讲&＃xff0c;所有的对象都在堆区上分配内存&＃xff08;不过现代技术里&＃xff0c;也不是这么绝对的&＃xff0c;也有栈上直接分配的&＃xff09;。
  一般的&＃xff0c;根据Java虚拟机规范规定&＃xff0c;堆内存需要在逻辑上是连续的&＃xff08;在物理上不需要&＃xff09;&＃xff0c;在实现时&＃xff0c;可以是固定大小的&＃xff0c;也可以是可扩展的&＃xff0c;目前主流的虚拟机堆区都是可扩展的。如果在执行垃圾回收之后&＃xff0c;仍没有足够的内存分配&＃xff0c;也不能再扩展&＃xff0c;将会抛出OutOfMemoryError:Java heap space异常。
    “Java内存分配机制”。

  5&＃xff0c;方法区&＃xff08;Method Area&＃xff09;&＃xff1a;在Java虚拟机规范中&＃xff0c;将方法区作为堆的一个逻辑部分来对待&＃xff0c;但事实上&＃xff0c;方法区并不是堆&＃xff08;Non-Heap&＃xff09;&＃xff1b;另外&＃xff0c;不少人的博客中&＃xff0c;将Java GC的分代收集机制分为3个代&＃xff1a;青年代&＃xff0c;老年代&＃xff0c;永久代&＃xff0c;这些作者将方法区定义为“永久代”&＃xff0c;这是因为&＃xff0c;对于之前的HotSpot Java虚拟机的实现方式中&＃xff0c;将分代收集的思想扩展到了方法区&＃xff0c;并将方法区设计成了永久代。不过&＃xff0c;除HotSpot之外的多数虚拟机&＃xff0c;并不将方法区当做永久代&＃xff0c;HotSpot本身&＃xff0c;也计划取消永久代。本文中&＃xff0c;由于笔者主要使用Oracle JDK6.0&＃xff0c;因此仍将使用永久代一词。
  方法区是各个线程共享的区域&＃xff0c;用于存储已经被虚拟机加载的类信息&＃xff08;即加载类时需要加载的信息&＃xff0c;包括版本、field、方法、接口等信息&＃xff09;、final常量、静态变量、编译器即时编译的代码等。
  方法区在物理上也不需要是连续的&＃xff0c;可以选择固定大小或可扩展大小&＃xff0c;并且方法区比堆还多了一个限制&＃xff1a;可以选择是否执行垃圾收集。一般的&＃xff0c;方法区上 执行的垃圾收集是很少的&＃xff0c;这也是方法区被称为永久代的原因之一&＃xff08;HotSpot&＃xff09;&＃xff0c;但这也不代表着在方法区上完全没有垃圾收集&＃xff0c;其上的垃圾收集主要是针对常量池的内存回收和对已加载类的卸载。
  在方法区上进行垃圾收集&＃xff0c;条件苛刻而且相当困难&＃xff0c;效果也不令人满意&＃xff0c;所以一般不做太多考虑&＃xff0c;可以留作以后进一步深入研究时使用。
  在方法区上定义了OutOfMemoryError:PermGen space异常&＃xff0c;在内存不足时抛出。
  运行时常量池&＃xff08;Runtime Constant Pool&＃xff09;是方法区的一部分&＃xff0c;用于存储编译期就生成的字面常量、符号引用、翻译出来的直接引用&＃xff08;符号引用就是编码是用字符串表示某个变量、接口的位置&＃xff0c;直接引用就是根据符号引用翻译出来的地址&＃xff0c;将在类链接阶段完成翻译&＃xff09;&＃xff1b;运行时常量池除了存储编译期常量外&＃xff0c;也可以存储在运行时间产生的常量&＃xff08;比如String类的intern()方法&＃xff0c;作用是String维护了一个常量池&＃xff0c;如果调用的字符“abc”已经在常量池中&＃xff0c;则返回池中的字符串地址&＃xff0c;否则&＃xff0c;新建一个常量加入池中&＃xff0c;并返回地址&＃xff09;。

  6&＃xff0c;直接内存&＃xff08;Direct Memory&＃xff09;&＃xff1a;直接内存并不是JVM管理的内存&＃xff0c;可以这样理解&＃xff0c;直接内存&＃xff0c;就是 JVM以外的机器内存&＃xff0c;比如&＃xff0c;你有4G的内存&＃xff0c;JVM占用了1G&＃xff0c;则其余的3G就是直接内存&＃xff0c;JDK中有一种基于通道&＃xff08;Channel&＃xff09;和缓冲区 &＃xff08;Buffer&＃xff09;的内存分配方式&＃xff0c;将由C语言实现的native函数库分配在直接内存中&＃xff0c;用存储在JVM堆中的DirectByteBuffer来引用。 由于直接内存收到本机器内存的限制&＃xff0c;所以也可能出现OutOfMemoryError的异常。

 1&＃xff09;标记-整理算法&＃xff08;针对老年代&＃xff09;

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

     根据老年代的特点提出了“标记-整理”算法&＃xff0c;标记过程仍然与“标记-清除”算法一样&＃xff0c;但后续步骤不是直接对可回收对象进行清理&＃xff0c;而是让所有存活的对象都向一端移动&＃xff0c;然后直接清理掉端边界以外的内存。 

标记-整理的步骤&＃xff1a;

1. 标记阶段
2. 整理阶段&＃xff1a;移动存活对象&＃xff0c;同时更新存活对象中所有指向被移动对象的指针

整理的顺序

不同算法中&＃xff0c;堆遍历的次数&＃xff0c;整理的顺序&＃xff0c;对象的迁移方式都有所不同。而整理顺序又会影响到程序的局部性。主要有以下3种顺序&＃xff1a; 

     1. 任意顺序&＃xff1a;对象的移动方式和它们初始的对象排列及引用关系无关 

       任意顺序整理实现简单&＃xff0c;且执行速度快&＃xff0c;但任意顺序可能会将原本相邻的对象打乱到不同的高速缓存行或者是虚拟内存页中&＃xff0c;会降低赋值器的局部性。任意顺序算法只能处理单一大小的对象&＃xff0c;或者针对大小不同的对象需要分批处理&＃xff1b;

     2. 线性顺序&＃xff1a;将具有关联关系的对象排列在一起 
     3. 滑动顺序&＃xff1a;将对象“滑动”到堆的一端&＃xff0c;从而“挤出”垃圾&＃xff0c;可以保持对象在堆中原有的顺序 
    所有现代的标记-整理回收器均使用滑动整理&＃xff0c;它不会改变对象的相对顺序&＃xff0c;也就不会影响赋值器的空间局部性。复制式回收器甚至可以通过改变对象布局的方式&＃xff0c;将对象与其父节点或者兄弟节点排列的更近以提高赋值器的空间局部性。   
整理算法的限制&＃xff0c;如整理过程需要2次或者3次遍历堆空间&＃xff1b;对象头部可能需要一个额外的槽来保存迁移的信息。
 

部分整理算法&＃xff1a;

双指针回收算法&＃xff1a;实现简单且速度快&＃xff0c;但会打乱对象的原有布局
Lisp2算法&＃xff08;滑动回收算法&＃xff09;&＃xff1a;需要在对象头用一个额外的槽来保存迁移完的地址
引线整理算法&＃xff1a;可以在不引入额外空间开销的情况下实现滑动整理&＃xff0c;但需要2次遍历堆&＃xff0c;且遍历成本较高
单次遍历算法&＃xff1a;滑动回收&＃xff0c;实时计算出对象的转发地址而不需要额外的开销

  2&＃xff09;Mark-sweep&＃xff08;标记清理&＃xff09;

   简介

基本思想是&＃xff1a;每次从根集出发寻找所有的引用&＃xff08;称为活对象&＃xff09;&＃xff0c;每找到一个&＃xff0c;则对其做出标记&＃xff0c;当追踪完成之后&＃xff0c;所有的未标记对象便是需要回收的垃圾。
也叫追踪算法&＃xff0c;基于标记并清除。这个垃圾回收步骤分为两个阶段&＃xff1a;在标记阶段&＃xff0c;垃圾回收器遍历整棵引用树并标记每一个遇到的对象。在清除阶段&＃xff0c;未标记的对象被释放&＃xff0c;并使其在内存中可用。

  具体阐述

“标记-清除”算法是最基础的算法&＃xff0c;分为“标记”和“清除”两个阶段&＃xff1a;首先标记出所有需要回收的对象&＃xff0c;在标记完成后统一回收掉所有被标记的对象。它主要由两个缺点&＃xff1a;一个是效率问题&＃xff0c;标记和清除过程的效率都不高&＃xff1b;另一个是空间问题&＃xff0c;标记清除之后会产生大量不连续的内存碎片&＃xff0c;空间碎片太多可能会导致当程序在以后的运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

  3&＃xff09;Copying collection&＃xff08;复制收集&＃xff09;

  简介

基本思想是&＃xff1a;将内存划分为两块&＃xff0c;一块是当前正在使用&＃xff1b;另一块是当前未用。每次分配时使用当前正在使用内存&＃xff0c;当无可用内存时&＃xff0c;对该区域内存进行标记&＃xff0c;并将标记的对象全部拷贝到当前未用内存区&＃xff0c;这是反转两区域&＃xff0c;即当前可用区域变为当前未用&＃xff0c;而当前未用变为当前可用&＃xff0c;继续执行该算法。
拷贝算法需要停止所有的程序活动&＃xff0c;然后开始冗长而繁忙的copy工作。这点是其不利的地方。

 具体阐述

为了解决标记清除算法的效率问题&＃xff0c;出现了复制算法&＃xff0c;它将可用内存按容量划分为大小相等的两块&＃xff0c;每次使用其中的一块。当这块的内存用完了&＃xff0c;就将还存活着的对象复制到另一块上面&＃xff0c;然后再把已使用过的内存空间一次清理掉。优点是每次都是对其中的一块进行内存回收&＃xff0c;内存分配时就不用考虑内存碎片等复杂情况&＃xff0c;只要移动堆顶指针&＃xff0c;按顺序分配内存即可&＃xff0c;实现简单&＃xff0c;运行高效。缺点是将内存缩小为原来的一半&＃xff0c;代价太高了一点。

 现在的商业虚拟机都采用复制收集算法来回收新生代&＃xff0c;有研究表明&＃xff0c;新生代中的对象98%是朝生夕死的&＃xff0c;所以并不需要按照1:1的比例来划分内存空间&＃xff0c;而是将内存分为一块较大的Eden空间和两块较小的Survivor空间&＃xff0c;每次使用Eden和其中的一块Survivor。当回收时&＃xff0c;将Eden和Survivor中还存活着的对象一次性地拷贝到另外一块Survivor空间上&＃xff0c;最后清理掉Eden和刚才用过的Survivor空间。HotSpot虚拟机默认Eden和Survivor的大小比例是8:1&＃xff0c;也就是每次新生代中可用内存空间为整个新生代容量的90%&＃xff08;80%&＃43;10%&＃xff09;&＃xff0c;只有10%的内存是会被“浪费”的。当然&＃xff0c;并不能保证每次回收都只有10%的对象存活&＃xff0c;当Survivor空间不够用时&＃xff0c;需要依赖其他内存&＃xff08;这里指老年代&＃xff09;进行分配担保&＃xff08;Handle Promotion&＃xff09;。即如果另外一块Survivor空间没有足够的空间存放上一次新生代收集下来的存活对象&＃xff0c;这些对象将直接通过分配担保机制进入老年代。
 

 4&＃xff09;Generational garbage collection&＃xff08;分代&＃xff09;

简介

其思想依据是&＃xff1a;
  (1) 被大多数程序创建的大多数对象有着非常短的生存期。
  (2) 被大多数程序创建的部分对象有着非常长的生存期。
简单拷贝算法的主要不足是它们花费了更多的时间去拷贝了一些长期生存的对象。
而分代算法的基本思想是&＃xff1a;将内存区域分两块&＃xff08;或更多&＃xff09;&＃xff0c;其中一块代表年轻代&＃xff0c;另一块代表老的一代。针对不同的特点&＃xff0c;对年轻一代的垃圾收集更为频繁&＃xff0c;对老代的收集则较少&＃xff0c;每次经过年轻一代的垃圾回收总会有未被收集的活对象&＃xff0c;这些活对象经过收集之后会增加成熟度&＃xff0c;当成熟度到达一定程度&＃xff0c;则将其放进老代内存块中。
分代算法很好的实现了垃圾回收的动态性&＃xff0c;同时避免了内存碎片&＃xff0c;是目前许多JVM使用的垃圾回收算法。 

具体阐述

  当前商业虚拟机的垃圾收集都采用“分代收集”算法&＃xff0c;这种算法并无新的方法&＃xff0c;只是根据对象的存活周期的不同将内存划分为几块&＃xff0c;一般是把Java堆分为新生代和老年代&＃xff0c;这样就可以根据各个年代的特点采用最适当的收集算法。在新生代中&＃xff0c;每次垃圾收集时都发现有大批对象死去&＃xff0c;只有少量存活&＃xff0c;那就选用复制算法&＃xff0c;只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保&＃xff0c;就必须使用“标记-清理”或“标记-整理”算法来进行回收。
 

1.标记-清除算法

        该算法先标记&＃xff0c;后清除&＃xff0c;将所有需要回收的算法进行标记&＃xff0c;然后清除&＃xff1b;这种算法的缺点是&＃xff1a;效率比较低&＃xff1b;标记清除后会出现大量不连续的内存碎片&＃xff0c;这些碎片太多可能会使存储大对象会触发GC回收&＃xff0c;造成内存浪费以及时间的消耗。

2.复制算法

        复制算法将可用的内存分成两份&＃xff0c;每次使用其中一块&＃xff0c;当这块回收之后把未回收的复制到另一块内存中&＃xff0c;然后把使用的清除。这种算法运行简单&＃xff0c;解决了标记-清除算法的碎片问题&＃xff0c;但是这种算法代价过高&＃xff0c;需要将可用内存缩小一半&＃xff0c;对象存活率较高时&＃xff0c;需要持续的复制工作&＃xff0c;效率比较低。

3.标记整理算法

        标记整理算法是针对复制算法在对象存活率较高时持续复制导致效率较低的缺点进行改进的&＃xff0c;该算法是在标记-清除算法基础上&＃xff0c;不直接清理&＃xff0c;而是使存活对象往一端游走&＃xff0c;然后清除一端边界以外的内存&＃xff0c;这样既可以避免不连续空间出现&＃xff0c;还可以避免对象存活率较高时的持续复制。这种算法适合老生代。

4.分代收集算法

         分代收集算法就是目前虚拟机使用的回收算法&＃xff0c;它解决了标记整理不适用于老年代的问题&＃xff0c;将内存分为各个年代&＃xff0c;在不同年代使用不同的算法&＃xff0c;从而使用最合适的算法&＃xff0c;新生代存活率低&＃xff0c;可以使用复制算法。而老年代对象存活率高&＃xff0c;没有额外空间对它进行分配担保&＃xff0c;所以使用标记整理算法。
 

https://blog.csdn.net/clover_lily/article/details/80160726

https://blog.csdn.net/carson0408/article/details/79608686