堆是一个巨大的对象池，在这个对象池中管理者数量巨大的对象实例。
池中对象的引用层次，有的是很深的，一个被频繁调用的接口。每秒生成对象的速度也是非常可观的。对象之间的关系，形成了一张巨大的网。虽然Java一直在营造一种无限内存的氛围，但对象不能只增不减，所以需要垃圾回收。
JVM是如何判断哪些对象应该被回收？哪些是应该保持呢？
JVM中的GC（garbage collection）动作，是不受程序控制的。它会在满足条件的时候，自动触发。在发生GC的时候，一个对象，JVM总能找到引用它的祖先。追溯到最终的祖先时，假如这个祖先已经名存实亡了，它们都会被清理掉。而能躲过垃圾回收的那些祖先，比较特殊，它们的名字就叫作GC Roots。
从GC Roots向下追溯、搜索，会产生一个叫作Reference Chain的链条。当一个对象不能和任何一个GC Roots产生关系时，就会被摧毁并回收相应的内存。垃圾的回收是围绕着GC Roots去做的。同时它也是很多内存泄漏的根源，因为其他引用根本没有这样的权利。
那么什么样的对象会是GC Roots？
不在于是什么对象，而在于它所处的位置。
GC Roots 是一组必须活跃的引用，通俗的说就是程序接下来通过直接引用或间接引用，能够访问到的潜在被使用的对象。
GC Roots有哪些？
1.Java线程中，当前所有正在被调用的方法的引用类型参数、局部变量、临时值等，也就是与我们的栈帧相关的各种引用
2.所有当前被加载的Java类
3.Java类的引用类型静态变量
4.运行时常量池里的引用类型常量（String或Class类型）
5.JVM内部数据结构的一些引用，比如sun.jvm.hotspot.memory.Universe类
6.用于同步的监控对象，比如调用了对象的wait()方法
7.JNI handles 包括global handle 和local handles
这些GC Roots 大体分为三大类
1.活动线程相关的各种引用。
2.类的静态变量的引用。
3.JNI引用
GC Roots三大类
两个注意点
1.这里说的是活跃的引用，而不是对象，对象不能作为GC Roots的。
2.GC过程是找出所有活对象，并把其余空间认定为"无用"；而不是找出所有死掉的对象，并回收它们占用的空间。所以，即使JVM的堆非常的大，基于tracing的GC方式，回收速度也会非常快。
引用级别
先抛出一到面试题，能够找到Reference Chain的对象，就一定会存活吗？
对象对于另外一个对象的引用，要看关系牢靠不牢靠，可能在链条的其中一环，就断掉了。
引用链条示例
根据发生GC时，这条链条的表现，可以对这个引用关系进行更加细致的划分。
它们的关系，可以分为强引用、软引用、弱引用、虚引用等。
强引用 Stong refrences
当内存空间不足，系统撑不住时，JVM就会抛出OutOfMemoryError错误，即使程序会异常终止，这种对象也不会被回收。这种引用属于最普通最强硬的一种存在，只有在和GC Roots断绝关系时，才会被消灭掉。
这种引用，每天的编码工作都在用。例如new 一个普通的对象
Object obj = new Object();
这种方式可能是有问题的。假如你的系统被大量用户（User）访问，你需要记录这个User访问的时间。可惜的是，User对象里并没有这个字段，所以我们决定将这些信息额外开辟一个空间进行存放。
static Map userVisitMap = new HashMap<>...
userVisitMap.put(user,time);
当你用完了User对象，其实你是期望它被回收掉的。但是，由于它被userVisitMap引用，我们没有其他手段remove掉它。这个时候，就发生了内存泄漏（memory leak）。
这种情况通常发生在一个没有设定上限的Cache系统。由于设置了不正确的引用方式，加上不正确的容量，很容易造成OOM。
软引用 Soft references
软引用用于维护一些可有可无的对象。在内存足够的时候，软引用对象不会被回收，只有在内存不足时，系统则会回收软引用对象，如果回收了软引用对象之后仍然没有足够的内存，才会抛出内存溢出异常。
可以看出，这种特性非常适合用在缓存技术上。比如网页缓存、图片缓存等。
Guava的CacheBulder，就提供了软引用和弱引用的设置方式。在这种情况下软引用比强引用安全的多。
软引用可以和一个引用队列（ReferenceQueue）联合使用，如果软引用所引用的对象被垃圾回收，Java虚拟机就会把这个软引用加入到与之关联的引用队列中。
我们可以看下它的代码。软引用需要显示的声明，使用泛型来实现
// 伪代码
Object obj = new Object();
SoftReference softRef = new SoftReference(obj);
这里有一个相关的JVM参数。它的意思是:每MB堆空间中SoftReference的存货时间。这个值得默认时间是1秒（1000）
-XX:SoftRefLRUPolicyMSPerMB=
特别说明的是，网络上一些流传的优化方法，即把这个值设置成0，这样容易引发故障。
弱引用 Weak References
弱引用对象相比较软引用，要更加无用一些，它拥有更短的生命周期。
当JVM进行垃圾回收时，无论是内存是否充足，都会回收弱引用关联的对象。弱引用拥有更短的生命周期，在Java中，用java.lang.ref.WeakReference 类来表示。
应用场景和软引用类似，可以在一些对内存更加敏感的系统中采用。使用方式类似于下面代码：
//伪代码
Object obj = new Object();
WeakReference weakRef = new WeakReference(obj);
虚引用 Phantom References
这是一种形同虚设的引用，在现实场景中用的不是很多。虚引用必须和引用队列（ReferenceQueue）联合使用。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收。
实际上，虚引用的get，总是返回null。
Object obj = new Object();
ReferenceQueue queue = new ReferenceQueue();
//虚引用，必须与一个引用队列关联
PhantomReference pr = new PhantomReference（obj,queue）;
虚引用主要用来追踪对象被垃圾回收的活动。
当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象前，把这个虚引用加入到与之关联的引用队列中。
程序如果发现某个虚引用已经被加入到引用队列，那么就可以在所引用的对象的内存被回收之前采取必要的行动。
基于虚引用，在Java9中有一个实现方式，新加入的Cleaner，用来替代Object类的finalizer方法。
典型的OOM场景
OOM（Out Of Memory）内存溢出
引起的原因
1.内存容量太小，需要扩容或需要调整堆的空间
2.错误的引用方式，发生了内存泄漏，没有及时的切断与GC Roots的关系。比如线程池里的线程，在复用的情况下忘记清理ThreadLocal的内容。
3.接口没有进行范围校验，外部传参超出范围。比如数据库查询时的每页条数等
4.对堆外内存无限制的使用。这种情况一旦发生更加严重，会造成操作系统内存耗尽
典型的内存泄漏场景，原因在于对象每页及时的释放自己的引用。比如一个局部变量，被外部的静态集合引用。在日常工作中，切忌不要为了方便把对象到处引用，即使引用了，也要在合适时机进行手动清理。
总结
学习了GC Roots，了解到了GC Roots包含哪些内容，HotSpot采用了tracing的方式进行GC，内存回收的速度与处于存活状态的对象数量有关。了解对象间的引用关系的分类，
网友评论