JVM详解——垃圾回收算法（补充）
Posted 匠心
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了JVM详解——垃圾回收算法（补充）相关的知识，希望对你有一定的参考价值。
一、相关概念
1、System.gc()的理解
通过System.gc()或Runtime.getRuntime().gc()的调用，会显式触发Full GC，对新生代和老年代进行回收，释放垃圾对象占用的内存。
然而System.gc()调用附带一个免责声明，它无法保证对垃圾收集器的调用。即：只是告诉JVM希望调用一次，但不保证一定被调用，啥时候调用。
JVM实现者可以通过System.gc()调用来决定JVM的GC行为，然而一般情况下，垃圾回收应该是自动进行的，无须手动触发，否则就太过于麻烦了。
代码示例：
1 public class SystemGCTest { 2 public static void main(String[] args) { 3 new SystemGCTest(); 4 5 // 提醒jvm的垃圾回收器执行gc,但是不确定是否马上执行gc 6 System.gc(); // 与Runtime.getRuntime().gc();的作用一样。 7 8 // System.runFinalization(); // 强制调用失去引用的对象的finalize()方法 9 } 10 11 @Override 12 protected void finalize() throws Throwable { 13 super.finalize(); 14 System.out.println("SystemGCTest 重写了finalize()"); 15 } 16 } 17 18 // 结果 19 SystemGCTest 重写了finalize() // 应该不是每次执行都能打印此结果. 20 21 // System.gc() 的源码 22 // public static void gc() { 23 // Runtime.getRuntime().gc(); 24 // }
在执行gc之前，对象的finalize()方法会执行一次。下面这句话就应该会被打印。多运行几次，可能会打印出来，说明了System.gc()方法不一定一定执行GC操作。
代码示例：手动gc理解不可达对象的回收行为
1 // -XX:+PrintGCDetails 2 public class LocalVarGC { 3 public static void main(String[] args) { 4 LocalVarGC local = new LocalVarGC(); 5 // 分别执行下面 5 个方法 6 local.localvarGC1(); 7 } 8 9 // 执行GC,未释放引用.对象直接进入老年代 10 public void localvarGC1() { 11 // 10MB 12 byte[] buffer = new byte[10 * 1024 * 1024]; 13 System.gc(); 14 } 15 16 // 执行GC,释放引用.回收空间 17 public void localvarGC2() { 18 byte[] buffer = new byte[10 * 1024 * 1024]; 19 buffer = null; 20 System.gc(); 21 } 22 23 // 执行GC,虽然出了buffer作用域,但引用还在.占用了局部变量表的一个slot槽 24 // 未回收空间 25 public void localvarGC3() { 26 { 27 byte[] buffer = new byte[10 * 1024 * 1024]; 28 } 29 System.gc(); 30 } 31 32 // 同localvarGC3().但是buffer出了作用域后,slot槽被value复用了 33 // 释放引用.回收空间 34 public void localvarGC4() { 35 { 36 byte[] buffer = new byte[10 * 1024 * 1024]; 37 } 38 int value = 10; 39 System.gc(); 40 } 41 42 // localvarGC1()已经执行完了.出栈后,buffer自然释放. 43 // 释放引用.回收空间 44 public void localvarGC5() { 45 localvarGC1(); 46 System.gc(); 47 } 48 }
2、内存溢出与内存泄漏
内存溢出：Javadoc中对OOM的解释是，没有空闲内存，并且垃圾收集器也无法提供更多内存。没有空闲内存，原因有：
（1）Java虚拟机的堆内存设置不够。
（2）代码中创建了大量大对象，且长时间不能被垃圾收集器收集。
通常在抛出OOM之间，垃圾收集器会被触发，尽可能的清理空间。比如：在引用机制分析中，JVM会去尝试回收软引用指向的对象等；在java.nio.BIts.reserveMemory()方法中，System.gc()会被调用，以清理空间。
当然，也不是在任何情况下垃圾收集器都会被触发。比如：分配一个超大对象，已经超过堆的最大值，JVM可以判断出垃圾收集并不能解决这个问题，就会直接抛出OOM。
内存泄露（Memory Leak）：严格来说，只有对象不再被程序用到了，但是GC又不能回收的情况，才叫内存泄漏。但实际上，一些不太好的实践（或疏忽）会导致对象的生命周期变得很长，导致OOM，也可以叫宽泛意义上的"内存泄漏"。
尽管内存泄漏并不会立刻引起程序崩溃，但是一旦发生，程序中的可用内存就会被逐步蚕食，直至耗尽所有内存，最终出现OOM异常，导致程序崩溃。
内存泄漏案例：
（1）单例模式：单例的生命周期和应用程序是一样长的，所以，单例中，如果持有对外部对象的引用的话，那么这个外部对象是不能被回收的，会导致内存泄漏。
（2）一些提供close的资源未关闭导致内存泄漏：数据库连接，网络连接，io流等，必须手动close，否则是不能被回收的。
3、Stop The World
STW：指GC发生过程中，会产生应用程序的停顿。停顿时，整个应用程序线程都会被暂停，没有任何响应，有点像卡死的感觉。
可达性分析算法中，枚举根节点（GC Roots）会导致所有Java执行线程停顿。分析原则：
（1）分析工作必须在一个能确保一致性的快照中进行。
（2）一致性指整个分析期间，执行系统看起来像被冻结在某个时间点上。如果分析过程中，对象引用关系还在不断变化，则分析结果的准确性就无法保证。
被STW中断的应用程序线程会在完成GC之后恢复，频繁中断会让用户感觉像是网速不快造成电影卡顿一样，所以要减少STW的发生。
STW和采用哪款GC无关，所有的GC都会有。只能说垃圾回收期越来越优秀，回收效率越来越高，尽可能的缩短STW时间。
STW是JVM在后台自动发起和自动完成的，在用户不可见的情况下，把用户线程全部停掉。
代码示例：STW
1 public class StopTheWorldDemo { 2 public static class WorkThread extends Thread { 3 List<byte[]> list = new ArrayList<>(); 4 5 @Override 6 public void run() { 7 try { 8 while (true) { 9 for (int i = 0; i < 1000; i++) { 10 byte[] buffer = new byte[1024]; 11 list.add(buffer); 12 } 13 14 if (list.size() > 10000) { 15 list.clear(); 16 System.gc();// 会触发full gc，进而会出现STW事件 17 } 18 } 19 } catch (Exception ex) { 20 ex.printStackTrace(); 21 } 22 } 23 } 24 25 public static class PrintThread extends Thread { 26 private final long startTime = System.currentTimeMillis(); 27 28 @Override 29 public void run() { 30 try { 31 while (true) { 32 // 每间隔 1d 打印一次时间信息 33 long t = System.currentTimeMillis() - startTime; 34 System.out.println(t / 1000 + "." + t % 1000); 35 Thread.sleep(1000); 36 } 37 } catch (Exception ex) { 38 ex.printStackTrace(); 39 } 40 } 41 } 42 43 public static void main(String[] args) { 44 WorkThread w = new WorkThread(); 45 PrintThread p = new PrintThread(); 46 w.start(); 47 p.start(); 48 } 49 } 50 51 // 结果 52 不开启w.start()时,理论应该每间隔 1s 打印一次时间信息.事实下面好像有点出入 53 0.1 54 1.2 55 2.3 56 3.3 57 4.3 58 5.4 59 6.4 60 …… 61 62 开启w.start()时,可以看到明显的卡顿 63 0.6 64 1.6 65 2.6 66 3.7 67 4.9 // 与上一次时间有卡顿 68 5.9 69 6.11 70 7.13 71 ……
4、垃圾回收的并行与并发
并发：不是真正意义上的"同时进行"，只是CPU在多个应用程序之间来回切换，由于CPU处理速度非常快，让用户感觉是在同时进行。
并行：系统有多个CPU时，一个CPU执行一个进程，另一个CPU执行另一个进程，互不抢占CPU资源，同时进行。
其实，决定并行的因素不是CPU的数量，而是CPU的核心数量，比如一个CPU多个核也可以并行。
并发：多个事情，在同一时间段内同时发生。
并行：多个事情，在同一时间点上同时发生。
并发的多个任务之间是相互抢占资源的，并行的多个任务之间是不相互抢占资源的。只有在多CPU或一个CPU多核的情况下，才会发生并行。否则，看似同时发生的事情，其实都是并发执行的。
垃圾回收的并行与并发
并行（Parallel）：指多条垃圾收集线程并行工作，但此时用户线程仍处于等待状态。比如：ParNew、Parallel Scavenge、Parallel Old。
串行（Serial）：相较于并行，单线程执行。如果内存不足，则程序暂停，启动JVM垃圾回收器进行垃圾回收，回收完，再启动程序的线程。
并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），垃圾回收线程在执行时不会停顿用户程序的运行。比如：CMS，G1。
5、安全点与安全区域
安全点：程序执行时并非在所有地方都能停顿下来GC，只有在特定位置才能停顿下来开始GC，这些位置称为"安全点"。类似于高速路的服务区，并不是所有的地方都能停车，只有到达服务区后，才能停车。
安全点的选择很重要，如果太少可能导致GC等待时间太长，如果太频繁可能导致运行时的性能问题。大部分指令的执行时间都非常短暂，通常会根据"是否具有让程序长时间执行的特征"为标准。比如选择一些执行时间较长的指令作为安全点，如方法调用，循环跳转，异常处理等。
如何在GC发生时，检查所有线程都跑到最近的安全点停顿下来呢？
（1）抢先式中断（目前没有虚拟机采用了）：首先中断所有线程，如果还有线程不在安全点，就恢复线程，让线程跑到安全点。
（2）主动式中断：设置一个中断标志，各个线程运行到安全点的时候主动轮询这个标志。如果中断标志为真，则将自己进行中断挂起。
安全区域：安全点机制保证了程序执行时，在不太长的时间内就会遇到可进入GC的安全点。但是，程序"不执行"的时候呢？例如线程处于 sleep 状态或 blocked 状态，这时候线程无法响应JVM的中断请求，"走"到安全点去中断挂起，JVM也不太可能等待线程被唤醒。对于这种情况，就需要安全区域来解决。
安全区域是指在一段代码片段中，对象的引用关系不会发生变化，在这个区域中的任何位置开始GC都是安全的。也可以把安全区域看作是被扩展了的安全点。
实际执行时，当线程运行到安全区域的代码时，首先标识已经进入了安全区域，如果这段时间内发生GC，JVM会忽略标识为安全区域状态的线程。
当线程即将离开安全区域时，会检查JVM是否已经完成GC，如果完成了，则继续运行。否则线程必须等待直到收到可以安全离开安全区域的信号为止。
二、再谈引用
强引用（StrongReference）：是指在程序代码中普遍存在的引用赋值，即：Object obj = new Object()，这种引用关系。无论任何情况下，只要引用关系还在，垃圾收集器就永远不会回收掉被引用的对象。
软引用（SoftReference）：系统在发生内存溢出之前，将会把这些对象列入回收范围进行二次回收。如果这次回收后还没有足够的内存，才会抛出内存溢出。
弱引用（WeakReference）：被弱引用关联的对象只能生存到下一次垃圾收集之前。当垃圾收集器工作时，无论内存空间是否足够，都会回收被弱引用关联的对象。
虚引用（PhantomReference）：一个对象是否有虚引用的存在，完全不会对其生存时间造成影响，也无法通过虚引用来获得一个对象的实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。
99%都是用的强引用；软、弱，用于缓存的场景下；虚引用，主要用于对象回收的跟踪。
1、强引用：不回收
强引用的对象是可触及的，垃圾收集器永远不会回收被引用的对象。相对的，软引用、弱引用和虚引用的对象是软可触及、弱可触及和虚可触及。在一定条件下，都是可以被回收的。所以，强引用是造成Java内存泄漏的主要原因之一。
代码示例：强引用
1 public class StrongReferenceTest { 2 public static void main(String[] args) { 3 StringBuffer str = new StringBuffer("Hello world!"); 4 StringBuffer str1 = str; 5 6 str = null; 7 System.gc(); 8 9 try { 10 Thread.sleep(3000); 11 } catch (InterruptedException e) { 12 e.printStackTrace(); 13 } 14 15 // 强引用,不会被回收 16 System.out.println(str1); 17 } 18 }
2、软引用：内存不足才回收
软引用是用来描述一些还有用，但非必需的对象。只被软引用关联的对象，在系统发生内存溢出前，会把这些对象列进回收范围中进行第二次回收（第一次，指不可达的对象）。如果这次回收还没有足够的内存，才会抛出内存溢出。
软引用通常用来实现内存敏感的缓存。比如：高速缓存，如果还有空闲内存，就暂时保留缓存，当内存不足时就清理掉。这样就保证了使用缓存的同时，不会耗尽内存。软引用，不会引起OOM。
内存足够：不会回收软引用的可达对象。
内存不够：会回收软引用的可达对象。
代码示例：软引用
1 // -Xms10m -Xmx10m 2 public class SoftReferenceTest { 3 4 public static void main(String[] args) { 5 // 创建对象,建立软引用 6 SoftReference<User> userSoftRef = new SoftReference<>(new User(1, "haha")); 7 // 从软引用中重新获得对象 8 System.out.println(userSoftRef.get()); 9 10 System.gc(); 11 System.out.println("After GC:"); 12 // 垃圾回收之后获得软引用中的对象.由于堆空间内存足够,所有不会回收软引用的可达对象。 13 System.out.println(userSoftRef.get()); 14 15 try { 16 // 让系统认为内存资源紧张、不够 17 byte[] b = new byte[1024 * 1024 * 7]; 18 } catch (Throwable e) { 19 e.printStackTrace(); 20 } finally { 21 // 再次从软引用中获取数据 22 // 在报OOM之前，垃圾回收器会回收软引用的可达对象。 23 System.out.println(userSoftRef.get()); 24 } 25 } 26 27 private static class User { 28 public User(int id, String name) { 29 this.id = id; 30 this.name = name; 31 } 32 33 public int id; 34 public String name; 35 36 @Override 37 public String toString() { 38 return "[id=" + id + ", name=" + name + "] "; 39 } 40 } 41 } 42 43 // 结果 44 [id=1, name=haha] 45 After GC: 46 [id=1, name=haha] 47 java.lang.OutOfMemoryError: Java heap space 48 at com.lx.jvm.SoftReferenceTest.main(SoftReferenceTest.java:20) 49 null
3、弱引用：发现即回收
弱引用也是用来描述非必需对象，只被弱引用关联的对象只能生存到下一次垃圾收集发生为止。在系统GC时，不管堆空间是否足够，都会回收只被弱引用关联的对象。
但是，由于垃圾回收器的线程优先级通常很低，因此，并不一定能很快的发现持有弱引用的对象。在这种情况下，弱引用对象可以存在较长的时间。
软、弱引用都非常适合保存那些可有可无的缓存数据。当系统内存不足时，回收缓存数据，不会导致内存溢出；内存充足时，缓存数据可以存在相当长的时间，从而起到加速系统的作用。
应用：三级缓存，内存—>本地—>网络。用WeakHashMap去存储图片信息，就可以在内存不足的时候，及时回收数据。
代码示例：弱引用
1 public class WeakReferenceTest { 2 3 public static void main(String[] args) { 4 // 构造了弱引用 5 WeakReference<User> userWeakRef = new WeakReference<>(new User(1, "haha")); 6 // 从弱引用中重新获取对象 7 System.out.println(userWeakRef.get()); 8 9 System.gc(); 10 // 不管当前内存空间足够与否，都会回收它的内存 11 System.out.println("After GC:"); 12 // 重新尝试从弱引用中获取对象 13 System.out.println(userWeakRef.get()); 14 } 15 16 private static class User { 17 public User(int id, String name) { 18 this.id = id; 19 this.name = name; 20 } 21 22 public int id; 23 public String name; 24 25 @Override 26 public String toString() { 27 return "[id=" + id + ", name=" + name + "] "; 28 } 29 } 30 } 31 32 // 结果 33 [id=1, name=haha] 34 After GC: 35 null
4、虚引用：对象回收跟踪
一个对象是否有虚引用的存在，完全不会决定对象的生命周期。若只有虚引用，那么它和没有引用几乎是一样的，随时都可能被垃圾回收器回收。
它不能单独使用，也无法通过虚引用来获取被引用的对象。
为一个对象设置虚引用关联的唯一目的在于跟踪垃圾回收过程。能在这个对象被收集器回收时收到一个系统通知。
虚引用必须和引用队列一起使用，在创建时必须提供一个引用队列作为参数。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象后，将这个虚引用加入引用队列，以通知应用程序对象的回收情况。
由于虚引用可以跟踪对象的回收时间，因此，也可以将一些资源释放操作放置在虚引用中执行和记录。
代码示例：虚引用
1 public class PhantomReferenceTest { 2 public static PhantomReferenceTest obj; 3 // 引用队列 4 static ReferenceQueue<PhantomReferenceTest> phantomQueue = null; 5 6 public static class CheckRefQueue extends Thread { 7 @Override 8 public void run() { 9 while (true) { 10 if (phantomQueue != null) { 11 PhantomReference<PhantomReferenceTest> objt = null; 12 try { 13 objt = (PhantomReference<PhantomReferenceTest>) phantomQueue.remove(); 14 } catch (InterruptedException e) { 15 e.printStackTrace(); 16 } 17 if (objt != null) { 18 System.out.println("追踪垃圾回收过程：PhantomReferenceTest实例被GC了"); 19 } 20 } 21 } 22 } 23 } 24 25 @Override 26 protected void finalize() throws Throwable { 27 super.finalize(); 28 System.out.println("调用当前类的finalize()方法"); 29 obj = this; 30 } 31 32 public static void main(String[] args) { 33 Thread t = new CheckRefQueue(); 34 t.setDaemon(true); // 设置为守护线程：当程序中没有非守护线程时，守护线程也就执行结束。 35 t.start(); 36 37 phantomQueue = new ReferenceQueue<>(); 38 obj = new PhantomReferenceTest(); 39 // 构造对象的虚引用,并指定了引用队列 40 PhantomReference<PhantomReferenceTest> phantomRef = new PhantomReference<>(obj, phantomQueue); 41 42 try { 43 // 不可获取虚引用中的对象 44 System.out.println(phantomRef.get()); 45 46 // 将强引用去除 47 obj = null; 48 // 第一次进行GC,由于对象可复活，GC无法回收该对象 49 System.gc(); 50 Thread.sleep(1000); 51 if (obj == null) { 52 System.out.println("obj 是 null"); 53 } else { 54 System.out.println("obj 复活"); 55 } 56 57 System.out.println("第 2 次 gc"); 58 obj = null; 59 System.gc(); // 一旦将obj对象回收，就会将此虚引用存放到引用队列中。 60 Thread.sleep(1000); 61 if (obj == null) { 62 System.out.println("obj 是 null"); 63 } else { 64 System.out.println("obj 可用"); 65 } 66 } catch (InterruptedException e) { 67 e.printStackTrace(); 68 } 69 } 70 }
5、终结器引用
它用以实现对象的finalize()方法。无需手动编码，其内部配合引用队列使用。在GC时，终结器引用入队，由Finalizer线程通过终结器引用找到被引用对象并调用它的finalize()方法，第二次GC时才能回收被引用对象。
作者：Craftsman-L
本博客所有文章仅用于学习、研究和交流目的，版权归作者所有，欢迎非商业性质转载。
如果本篇博客给您带来帮助，请作者喝杯咖啡吧！点击下面打赏，您的支持是我最大的动力！
JVM详解——垃圾回收算法
一、概述
1、什么是垃圾
垃圾收集，不是Java语言的伴生产物。早在1960年，第一门开始使用内存动态分配和垃圾收集技术的Lisp语言诞生。关于垃圾收集的三个经典问题：
（1）哪些内存需要回收？
（2）什么时候回收？
（3）如何回收？
垃圾收集机制是Java的招牌能力，极大地提高了开发效率。如今，垃圾收集几乎成为现代语言的标配，即使经过如此长时间的发展，Java的垃圾收集机制仍然在不断的演进中，不同大小的设备、不同特征的应用场景，对垃圾收集提出了新的挑战。
垃圾是指在运行程序中没有任何指针指向的对象。如果不及时对内存中的垃圾进行清理，那么，这些垃圾对象所占的内存空间会一直保留到应用程序结束，被保留的空间无法被其他对象使用，就可能导致内存溢出。
2、为什么需要GC
对于高级语言来说，不断的分配内存空间而又不进行回收，内存迟早会被消耗完。
除了释放没用的对象，垃圾回收还可以清除内存里的记录碎片。碎片整理将所占用的堆内存移到堆的一端，以便JVM将整理出的内存分配给新的对象。
随着应用程序所应付的业务越来越庞大，复杂，用户越来越多，没有GC就不能保证应用程序的正常进行。而经常造成STW的GC又跟不上实际的需求，所以才会不断的尝试对GC进行优化。
3、早期垃圾回收
在早期的C/C++时代，垃圾回收基本上是手工进行的。开发人员可以使用new关键字进行内存申请，使用delete关键字进行内存释放。
代码示例：
这种方式可以灵活控制内存释放的时间，但是会给开发人员带来频繁申请和释放内存的管理负担，如果有一处内存区间由于程序员编码的问题忘记被回收，那么就会产生内存泄漏，垃圾对象永远无法被清除。随着系统运行时间的不断增长，垃圾对象所耗内存可能持续上升，直到出现内存溢出并造成应用程序崩溃。
内存泄漏：这个对象不用了，但是Java程序试图gc回收的时候，回收不了。因为它还有相关的引用指向。
在有了垃圾回收机制后，上述代码有可能变成这样：
现在，除了Java以外，C#、Python、Ruby等语言都使用了自动垃圾回收的思想，也是未来发展趋势。这种自动化的内存分配和垃圾回收机制已经成为现代开发语言必备的标准。
4、Java垃圾回收机制
好处：自动内存管理，无需开发人员手动参与内存的分配与回收，这样降低内存泄漏和内存溢出的风险。也将程序员从繁重的内存管理中释放出来，可以更专注于业务开发。
Oracle官网关于垃圾回收的介绍
https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/toc.html
坏处：对于Java开发人员而言，自动内存管理就像一个黑匣子，如果过度依赖于"自动"，就会弱化Java开发人员在程序出现内存溢出时定位问题和解决问题的能力。
垃圾回收器可以对新生代，老年代回收，也可以是全堆和方法区的回收。其中，Java堆是垃圾收集器的工作重点。
从频率上说：频繁收集新生代，较少收集老年代，基本不动方法区。
二、相关算法
判断哪些是垃圾？——标记阶段：引用计数算法、可达性分析算法。
是垃圾后，怎么清除？——清除阶段：标记-清除算法、复制算法、标记-压缩算法。
清除阶段的算法：分代收集算法、增量收集算法、分区算法。
JVM中如何判断一个对象已经死亡呢？简单来说，当一个对象已经不再被任何存活对象继续引用时，就可以判定为死亡。判断对象是否存活一般有两种方式：引用计数算法和可达性分析算法。
1、标记阶段：引用计数算法
引用计数算法，对每个对象保存一个整型的引用计数器属性，用于记录对象被引用的情况。
思想：对于对象A，只要有对象引用了A，则A的引用计数器加1；当引用失效时，减1；当为0时，即表示对象A不再被使用，可进行回收。
优点：实现简单，垃圾对象便于辨识；判定效率高，回收没有延迟性。
缺点：需要单独的字段存储计数器，增加了空间开销；每次赋值需要更新计数器，增加了时间开销；无法处理循环引用的情况，致命，导致在Java垃圾回收器中没有使用这类算法。
代码示例：证明Java使用的不是引用计数算法
1 // -XX:+PrintGCDetails 2 public class RefCountGC { 3 // 这个成员属性唯一的作用就是占用一点内存.5MB 4 private byte[] bigSize = new byte[5 * 1024 * 1024]; 5 6 Object reference = null; 7 8 public static void main(String[] args) { 9 RefCountGC obj1 = new RefCountGC(); 10 RefCountGC obj2 = new RefCountGC(); 11 12 obj1.reference = obj2; 13 obj2.reference = obj1; 14 15 obj1 = null; 16 obj2 = null; 17 18 // 显式的执行垃圾回收行为 19 // 这里发生GC,obj1和obj2能否被回收？ 20 System.gc(); 21 22 try { 23 Thread.sleep(1000000); 24 } catch (InterruptedException e) { 25 e.printStackTrace(); 26 } 27 } 28 }
引用计数算法：如果把obj1 = null;obj2 = null;则在Java堆当中，两块内存依然保持着相互引用，无法回收。
结论：如果采用了引用计数算法，那么，这里就不会发生gc才对。从而证明没有采用。
2、标记阶段：可达性分析算法
相比引用计数算法，可达性分析算法不仅同样具备实现简单，执行高效等特点，更重要的是它可以有效的解决循环引用的问题，防止内存泄漏的发生。这种类型的垃圾收集通常也叫作追踪性垃圾收集。
思想：以根对象集合（GC Roots）为起始点，按照从上至下的方式搜索被根对象集合所连接的目标对象是否可达。可达：存活；不可达，死亡。
所谓"GC Roots"根集合就是一组必须活跃的引用。
那么，如何确定 GC Roots？即：哪些元素可以作为GC Roots？
（1）虚拟机栈中引用的对象。比如，各个线程被调用的方法中使用的参数、局部变量等。
（2）本地方法栈内JNI（本地方法）引用的对象。
（3）方法区中类静态属性引用的对象。比如，Java类的引用类型静态变量。
（4）方法区中常量引用的对象。比如，字符串常量池（String Table）里的引用。
（5）所有被同步锁synchronized持有的对象。
（6）Java虚拟机内部的引用。基本数据类型对应的Class对象，一些常驻的异常对象，系统类加载器。
（7）反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。
除了这些固定的GC Roots集合以外，根据用户所选用的垃圾收集器以及当前回收的内存区域不同，还可以有其他对象"临时性"的加入，共同构成完整GC Roots集合。比如：分代收集和局部回收（Partial GC）。
比如，只针对新生代的回收，那么被老年代的对象所引用的对象也应该加入到GC Roots中考虑，才能保证可达性分析的准确性。
小技巧：由于Root采用栈方式存放变量和指针，所以，如果一个指针保存了堆内存里面的对象，但是自己又不存放在堆内存里，那它就是一个Root。
注意：如果使用可达性分析算法，那么分析工作必须在一个能保障一致性的快照中进行，这点不满足的话分析结果的准确性就无法保证。这点也是导致GC时必须STW的一个重要原因。即使是号称几乎不会发生停顿的CMS收集器中，枚举根节点时也必须要停顿。
即，打扫门店的时候，必须关门（停止营业）。
3、对象的finalization机制
Java语言提供了对象终止机制来允许开发人员提供对象被销毁前的自定义处理逻辑。垃圾回收之前，总会先调用这个对象的finalize()方法。finalize()方法允许在子类中被重写，用于在对象被回收时进行资源释放。通常进行一些资源释放和清理工作，比如关闭文件、套接字和数据库连接等。
永远不要主动调用对象的finalize()方法。应该交给垃圾回收机制调用，理由：
（1）在finalize()时可能会导致对象复活。
（2）finalize()方法的执行时间没有保障，它完全由GC线程决定，极端情况下，若不发生GC，则finalize()方法将没有执行机会。
（3）一个糟糕的finalize()会严重影响GC的性能。
由于finalize()方法的存在，对象有三种可能的状态。如果某个对象不可达，一般来说，此对象需要被回收。但事实，它们暂处理"缓刑"阶段，有可能在某个条件下，复活自己。如果这样，那对它的回收就是不合理的。三种状态：
可触及的：从根节点开始，可达，存活对象。
可复活的：对象的所有引用都被释放，但是有可能在finalize()中复活。
不可触及的：finalize()被调用，且没有复活。则必须死！
finalize()只会被调用一次！
总结：不可达，是垃圾。在回收之前，会调用finalize()方法。finalize()方法是由垃圾回收器自己来调，且只会被调用一次。
代码示例：演示可复活的对象
1 public class CanReliveObj { 2 3 // 类变量，属于 GC Root 4 public static CanReliveObj obj; 5 6 //此方法只能被调用一次 7 @Override 8 protected void finalize() throws Throwable { 9 super.finalize(); 10 System.out.println("调用当前类重写的finalize()方法"); 11 obj = this;//当前待回收的对象在finalize()方法中与引用链上的一个对象obj建立了联系 12 } 13 14 public static void main(String[] args) { 15 try { 16 obj = new CanReliveObj(); 17 // 对象第一次成功拯救自己 18 obj = null; 19 System.gc();//调用垃圾回收器 20 System.out.println("第1次 gc"); 21 // 因为Finalizer线程优先级很低，暂停2秒，以等待它 22 Thread.sleep(2000); 23 if (obj == null) { 24 System.out.println("obj is dead"); 25 } else { 26 System.out.println("obj is still alive"); 27 } 28 29 System.out.println("第2次 gc"); 30 // 下面这段代码与上面的完全相同，但是这次自救却失败了 31 obj = null; 32 System.gc(); 33 // 因为Finalizer线程优先级很低，暂停2秒，以等待它 34 Thread.sleep(2000); 35 if (obj == null) { 36 System.out.println("obj is dead"); 37 } else { 38 System.out.println("obj is still alive"); 39 } 40 } catch (InterruptedException e) { 41 e.printStackTrace(); 42 } 43 } 44 } 45 46 // 结果 47 第1次 gc 48 调用当前类重写的finalize()方法 49 obj is still alive 50 第2次 gc 51 obj is dead
4、MAT与JProfiler的GC Roots溯源
一个程序当中，到底有多少个GC Roots ，分别又是什么呢？可以通过一些工具来查看。
MAT是Memory Analyzer Tool的简称，它是一款功能强大的Java堆内存分析器。用于查找内存泄漏以及查看内存消耗情况，是一款免费的性能分析工具。
官网下载：http://www.eclipse.org/mat/
代码示例：用MAT查看GC Roots
1 // 在输入前后分别获取一次dump文件 2 public class GCRootsTest { 3 public static void main(String[] args) { 4 List<Object> list = new ArrayList<>(); 5 Date date = new Date(); 6 7 for (int i = 0; i < 100; i++) { 8 list.add(String.valueOf(i)); 9 try { 10 Thread.sleep(10); 11 } catch (InterruptedException e) { 12 e.printStackTrace(); 13 } 14 } 15 16 System.out.println("数据添加完毕，请操作："); 17 18 new Scanner(System.in).next(); 19 list = null; 20 date = null; 21 22 System.out.println("list、birth已置空，请操作："); 23 new Scanner(System.in).next(); 24 25 System.out.println("结束"); 26 } 27 }
获取dump文件
方式一：命令行使用jmap
jps // 获取pid
jmap -dump:format=b,live,file=test1.bin #{pid}
方式二：使用JVisualVM
应用程序—>监视—>堆dump
用MAT打开两个dump文件，对比就可知道。
代码示例：同上。用JProfiler查看GC Roots
代码示例：用JProfiler分析OOM
1 package com.lx.jvm; 2 3 import java.util.ArrayList; 4 5 // -Xms8m -Xmx8m -XX:+HeapDumpOnOutOfMemoryError 6 public class HeapOOM { 7 // 1MB 8 byte[] buffer = new byte[1 * 1024 * 1024]; 9 10 public static void main(String[] args) { 11 ArrayList<HeapOOM> list = new ArrayList<>(); 12 13 int count = 0; 14 try { 15 while (true) { 16 list.add(new HeapOOM()); 17 count++; 18 } 19 } catch (Throwable e) { 20 System.out.println("count = " + count); 21 e.printStackTrace(); 22 } 23 } 24 } 25 26 // 结果 27 java.lang.OutOfMemoryError: Java heap space 28 Dumping heap to java_pid12820.hprof ... 29 Heap dump file created [7834867 bytes in 0.011 secs] 30 count = 6 31 java.lang.OutOfMemoryError: Java heap space 32 at com.lx.jvm.HeapOOM.<init>(HeapOOM.java:8) 33 at com.lx.jvm.HeapOOM.main(HeapOOM.java:16)
用JProfiler打开java_pid12820.hprof
5、清除阶段：标记-清除算法（Mark-Sweep）
当成功判定是否是垃圾后，接下来就是释放掉无用对象所占用的内存空间，以便有足够的可用内存空间为新对象分配内存。思想：
标记：Collector从引用根节点开始遍历，标记所有被引用的对象。一般是在对象的Header中记录为可达对象。
清除：Collector对堆内存从头到尾进行线性的遍历，如果某个对象在其Header中没有标记为可达对象，则将其回收。清除的是死亡对象。
缺点：效率不算高；GC时，需要停止整个应用程序，导致用户体验差；这种方式清理出来的内存是不连续的，会产生内存碎片，需要维护一个空闲列表。
注意：何为清除？
这里所谓的清除并不是真的置空，而是把需要清除的对象地址保存在空闲的地址列表中。下次有新的对象需要加载时，判断垃圾的位置空间是否够，如果够，就存放。
6、清除阶段：复制算法（Copying）
思想：将活着的内存空间分为两块，每次只使用其中一块，在垃圾回收时将正在使用的内存中的存活对象复制到未被使用的内存块中，之后清除正在使用的内存块中的所有对象，交换两个内存的角色，完成垃圾回收。
复制的是存活对象。
优点：没有标记和清除过程，实现简单，运行高效；保证空间的连续性，不会出现"碎片"问题。
缺点：需要两倍的内存空间；对于G1这种分拆成为大量region的GC，复制而不是移动，意味着GC需要维护region之间对象引用关系，不管是内存占用或者时间开销也不小。
注意：此算法存活对象数量很越少，效果越好！不然就白瞎折腾嘛！适用于垃圾很多，存活对象很少，那么需要复制过去的对象就很少，就最理想。比如：S0/S1区。
如果从根节点标记的存活对象很多（垃圾很少），极端的都存活的话，那么就会把所有的对象都复制过来一遍，完了之后还什么垃圾也没回收到，还把栈上的引用地址也全都修改一遍。就很得不偿失了。
应用场景：在新生代，对常规应用的垃圾回收，一次通常可以回收70%~99%的内存空间，回收性价比很高。所以现在的商业虚拟机都是用这种收集算法回收新生代。
结论：在新生代用复制算法是很理想的。在老年代用复制算法，就不理想了，因为很多对象都是要持久存活的。
7、清除阶段：标记-压缩算法（Mark-Compact）
思想：第一阶段和标记-清除算法一样，从根节点开始标记所有被引用的对象。第二阶段将所有的存活对象压缩到内存的一端，按顺序排放，之后，清理边界外所有的空间。
标记-压缩算法的最终效果等同于标记-清除后，再进行一次内存碎片整理。因此，也把它称为标记-清除-压缩算法。
二者的本质差异在于标记-清除是一种非移动式的回收算法，标记-压缩是移动式的。是否移动回收后的存活对象是一项优缺点并存的风险决策。
被整理后，当需要给新的对象分配内存时，JVM只需要持有一个内存的起始地址即可，这比维护一个空闲列表显然少了很多开销。
解决了标记清除和复制算法的缺点。
优点：解决了标记-清除中，内存分散的缺点；解决了复制中，内存减半的代价。
缺点：效率上，低于复制算法；移动对象的同时，如果对象被其他对象引用，则还需要调整引用的地址；移动过程中，需要全程停止用户应用程序，即STW。
8、三种算法的对比
|
标记-清除
|
复制
|
标记-压缩
|
|
|
速度
|
中等
|
最快
|
最慢
|
|
空间开销
|
少（会堆积碎片）
|
需要活对象的2倍大小（不堆积碎片）
|
少（不堆积碎片）
|
|
移动对象
|
否
|
是
|
是
|
效率上说，复制算法最好，但是却浪费了太多内存。为了兼顾各个指标，标记-压缩相对来说更平滑一些，但是效率不尽人意。它比复制多了一个标记的阶段，比标记-清除多了一个整理内存的阶段。
难道就没有一种最优的算法吗？没有最优的！只有最适合的！
9、分代收集算法
分代收集算法，基于这样一个事实：不同对象的生命周期是不一样的。因此，不同生命周期的对象采取不同的收集方式，以便提高回收效率。
一般地，把Java堆分为新生代和老年代，这样就可以根据各个年代的特点使用不同的回收算法，以提高垃圾回收效率。
在Java程序中，有些对象是与业务信息相关，比如：Http请求中的Session对象、线程、Socket连接，这类对象跟业务直接挂钩，生命周期比较长；但是有一些对象，主要是程序运行过程中生成的临时变量，这些对象生命周期比较短，比如：String对象，由于其不变类的特性，系统会产生大量的这些对象，有些对象甚至只用一次即可回收。
目前，几乎所有的GC都是采用分代收集算法执行垃圾回收的。在Hotspot中，基于分代的概念，GC所使用的内存回收算法必须结合新生代、老年代各自的特点。
新生代：对象生命周期短、存活率低，回收频繁。这种情况复制算法的回收整理，速度是最快的。
老年代：区域较大，对象生命周期长、存活率高，回收不及新生代频繁。这种情况复制算法明显不合适，一般由标记-清除或标记-清除与标记-整理的混合实现。
（1）Mark阶段：开销与存活对象的数量成正比。
（2）Sweep阶段：开销与所管理区域的大小成正比。
（3）Compact阶段：开销与存活对象的数据成正比。
10、增量收集算法、分区算法
增量收集算法：
上述现有的算法，在垃圾回收过程中，应用程序将处于一种STW（stop the world）的状态。在这个状态下，应用程序所有的线程都会挂起，暂停一切正常工作，等待垃圾回收的完成。如果垃圾回收时间过长，势必将严重影响用户体验或系统的稳定性。为了解决STW时间过长的问题。对实时垃圾收集算法的研究直接导致了增量收集算法的诞生。
思想：如果一次性将所有的垃圾进行处理，会造成系统长时间的停顿，那么就可以让垃圾收集线程和应用程序线程交替执行。每次，垃圾收集线程只收集一小片区域的内存空间，接着切换到应用程序线程，依次反复，直到垃圾收集完成。
总的来说，增量收集算法的基础仍是传统的标记-清除和复制算法。增量收集算法通过对线程间冲突的妥善处理，允许垃圾收集线程以分阶段的方式完成标记、清理或复制工作。
为解决，或者说平衡， 用户线程与gc线程之间的矛盾（gc时会停止所有用户线程，会严重影响用户体验）。增量收集算法，就是为了在二者之间找到平衡，使其最佳。
缺点：使用这种方式，由于在垃圾回收过程中，间断性的还执行了应用程序代码，所以能减少系统的停顿时间。但是，因为线程上下文切换的消耗，会使得垃圾回收的总体成本上升，造成系统吞吐量的下降。
分区算法：
一般地，在相同条件下，堆空间越大，一次GC所需要的时间就越长，有关GC产生的停顿也越长。为了更好的控制GC产生的停顿时间，将一块大的内存区域分割成多个小块，根据目标的停顿时间，每次合理的回收若干个小区间，而不是整个堆空间，从而减少一次GC所产生的停顿。
分代算法将按照对象的生命周期长短划分成两个部分，分区算法将整个堆空间划分成连续的不同小区间region。
每一个小区间都独立使用，独立回收。这种算法的好处是可以控制一次回收多少个小区间。
注意：这些只是基本的算法思路，实际GC实现过程要复杂的多，目前还在发展中的前沿GC都是复合算法，并且并行和并发兼备。
作者：Craftsman-L
本博客所有文章仅用于学习、研究和交流目的，版权归作者所有，欢迎非商业性质转载。
如果本篇博客给您带来帮助，请作者喝杯咖啡吧！点击下面打赏，您的支持是我最大的动力！
以上是关于JVM详解——垃圾回收算法（补充）的主要内容，如果未能解决你的问题，请参考以下文章