Java虚拟机会在执行Java程序的时候把它所管理的内存区域分为若干个不同的数据区域。
- 程序计数器
- Java虚拟机栈
- 本地方法栈
- Java堆区
- 方法区，方法区中包含运行时常量池
Java内存结构.png
程序计数器、虚拟机栈、本地方法栈随线程而生随线程而灭。栈中的栈帧，随方法的进入和退出有条不紊的进行入栈出栈操作。每一个栈帧分配多少内存基本上是在类结构确定的时候就知道了。这3个地方不用考虑内存回收的问题，因为方法或者线程退出的时候，内存自然就被回收了。而Java堆和方法区则不一样，内存的分配和回收都是动态的，垃圾回收器所关注的是这部分内存。
Jvm的垃圾回收机制，本质上就是做3件事：
- 确定哪些对象可以被回收
- 什么时候回收
- 怎么回收这些对象
判断对象时候可以被回收
-
引用计数法，给每个对象增加一个引用计数器，例如一个对象A，每增加一个引用，它的引用计数就加1，每减少一个引用，引用计数就减1。如果该对象的引用计数为0，那么垃圾回收器就认为该对象可以被回收了。这种算法实现起来简单，判定效率也很高，但是有一个缺点，例如，A和B如果互相引用，那它们的引用计数器就永远不为0，也就意味着垃圾回收器永远不会回收它们了，这明显的不合理。
-
可达性分析算法
该算法是在主流的商用领域采用，算法的思想是通过一系列的称为“GC Root”的对象作为起始点，从这个起始点向下搜索，搜索所走过的路径称为引用链，当一个对象到达GC Root没有任何引用链可用，就认为该对象是不可达的，将会被回收。
例如，在下图中，Object5、Object6、Object7到GC Root之间没有引用链，尽管它们之间存在着引用关系，但是它们还是会被回收。
图片摘自深入理解Java虚拟机.png
GC Root实际上也是对象，那么哪些对象可以作为GC Root呢？
- 虚拟机栈中的引用对象
- 方法区中类的静态属性引用的对象
- 方法区中常量引用的对象
- 本地方法栈中JNI（即一般说的Native方法）引用的对象
垃圾回收算法
标记-清除算法 Mark-Sweep ，算法分为标记和清除阶段，首先标记需要被回收的对象，在标记完成后统一回收所有被标记的对象。不足之处有两个：一是效率问题，两个阶段效率都不高，二是空间问题，标记清除之后会产生大量的空间碎片，后面如果需要分配较大对象时有可能因为连续内存空间不足而导致需要重新出发一次垃圾回收。
图片摘自深入理解Java虚拟机.png
复制算法 Coping，把内存区域按容量分为两个相等的部分，每次只使用一块，当空间使用完毕之后就把还存活的对象赋值到另一块内存区域上，并把使用过的内存空间清空。不用考虑碎片问题，使用简单，但是浪费空间。
图片摘自深入理解Java虚拟机.png
标记整理算法 Mark-Compact，标记过程与标记-清除算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有的存活对象都向一端移动，然后直接清理掉端边界以外的对象，也就是需要被回收的对象。
图片摘自深入理解Java虚拟机.png
分代垃圾回收算法，Generational Collection，商用的JVM、DVM均使用该算法。根据对象存活周期的不同将内存划分几块，一般把Java堆分为新生代和老年代，不同的代采用不同的垃圾回收算法，在新生代中每次垃圾回收都会有大量的对象死去，只有少量存活，就采用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中对象存活时间较长，没有额外空间进行担保，就必须使用标记-清除或者标记-整理算法来进行回收。
新生代中将内存分为一块较大的Eden和两块较小的Survivor区域，每次对象分配只使用Eden和其中一块Survivor区域，当进行GC的时候会有大量的对象死去，少部分存活的对象复制到空闲的Survivor区域。空闲的这个区域相当于是个担保，避免了纯粹的复制算法那样需要一半的空闲区域，浪费空间。
那么为什么需要两块Survivor区域呢，一块就不行吗？如果只有一块的话，相当于在下次复制存活对象的时候，Survivor区域上已经有了对象，这一点是有问题的，要么复制算法复杂，要么造成空间碎片。（这点是我自己理解的，有误的话还请指正）
垃圾收集器
垃圾回收算法只是内存回收的方法论，提供理论指导，真正的具体实现是垃圾收集器。Java 虚拟机规范中对垃圾收集器应该如何实现并没有任何规定，因此不同的厂商、不同版本的虚 拟机所提供的垃圾收集器都可能会有很大差别，并且一般都会提供参数供用户根据自己的应用特点和要求组合出各个年代所使用的收集器。
参考
- 垃圾回收算法之分代回收算法
- 深入理解Java虚拟机——JVM高级特性与最佳实践，周志明
网友评论