链接：https://pan.baidu.com/s/13jDxowDMiO_6N03i7BOjEw 

提取码：d4u4 

 

深入理解JVM总结-垃圾收集器与内存分配策略

在面试时，总是会问到JVM的GC机制等问题，这一块算是十分重要的了。

GC（garbage collection），垃圾收集器。

对于GC，我们需要考虑的是以下三点：

①哪些内存需要回收；（Java 堆和方法区）

②什么时候回收；（检测算法）

③如何回收。（回收算法）

为何要考虑垃圾回收机制呢？

当需要排查各种内存溢出、内存泄漏时，当垃圾收集成为系统达到高并发量的瓶颈时，就需要对这些“自动化”技术实施必要的监控和调节。

哪些内存需要回收

从写的另一篇博文 深入理解JVM总结-JDK各版本、JVC内存分配及溢出异常已知，内存运行时，程序计数器、本地方法栈和虚拟机栈是随着线程的产生而产生，随着线程的消亡而消亡的。栈中的栈帧是随着方法的进出而入栈出栈的，它们的内存分配是在类结构确定下来时就已经分配好了的。因此这几个地方的分配和回收是确定好了的，不必考虑其回收的问题，因为方法结束或线程结束时，内存就紧跟着回收了。

而Java堆和方法区不一样。一个接口中多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，我们只有在运行期间才知道会创建哪些对象。这部分的内存分配是动态的，JVM的GC机制主要针对的就是Java堆和方法区动态内存分配区域的垃圾回收。

什么时候回收

---->回收Java堆

由于Java堆中存放的是Java的对象实例，因此，在回收之前，必须得确定哪些对象是“存活的”，哪些对象是“死亡的”。而我们要回收的，就是那些“死亡的”对象。

判断的方法有两种：引用计数算法，可达性分析算法。

①引用计数算法

给对象一个引用计数器，引用一次计数器加1，失效时，计数器减1；任何时刻引用计数器的值为0，则该对象就不会被使用，进入“消亡”状态，就可以被回收了。

它的实现很简单，判定的效率也很高。但缺点在于很难解决对象之间相互循环引用而无法回收的问题。

例如： objA=objB; objB=objA;  objA=null;objB=null; 除此之外，无任何对象的引用。实际上这两个对象不可能再被访问了，但是由于相互引用了对方，导致引用计数器不为1，gc无法回收它们。

②可达性分析算法（Java/C#/Lisp）

基于对象相互引用而无法回收的问题，产生了可达性分析算法。

 

通过GC Roots作为起点开始往下搜索，所走过的路径为引用链。当一个对象到GC Roots没有任何引用链时，则该对象不可达，即该对象是不可用的，那么就将其判定为可回收的对象。

其中，可作为GC Roots的对象包括四种：a.虚拟机栈（栈帧中的本地变量表）中的引用对象；

  b.方法区中的静态属性引用的对象；

  c.方法区中常量引用的对象；

  d.本地方法栈中JNI（即一般的native方法）引用的对象。

========================补充：引用

引用的原始定义：如果引用类型的数据中存储的是另一个内存的起始地址，就成为这个内存代表着一个引用。但太过狭隘。希望这样描述对象：当内存空间还足够时，则能保留在内存之中，如果内存空间在进行垃圾收集后还很紧张，则可以抛弃这些对象。

JDK1.2以后，引用分为强引用、软引用、弱引用、虚引用四种。

强引用：普遍存在，类似Object obj=new Object();只要强引用还在，GC就永远不会回收掉被引用的对象。

软引用：还有用但非必需的对象。在系统发生内存溢出异常之前将这些对象列入回收范围之中进行第二次回收，如果这次回收还没有足够的内存，才会抛出内存溢出异常。JDK1.2之后，提供了SoftReference类来实现软引用。

弱引用：描述非必需对象，但比软引用更弱一些。被弱引用关联的对象只能生存到下一次GC发生之前。GC工作时，无论内存是否足够，都会回收掉只被弱引用关联的对象。提供了WeakReference类来实现。

虚引用：幽灵引用或幻影引用。最弱的一种关系引用。一个对象是否有虚引用的存在完全不会对其生存时间构成影响，也无法提供虚引用来取得一个对象实例。虚引用的唯一目的是能在对象被GC回收时可以收到一个系统通知，提供了PhantomReference来实现。