GC如其名，就是垃圾收集，当然这里仅就内存而言。Garbage Collector（垃圾收集器）以应用程序的root为基础，遍历应用程序在Heap上动态分配的所有对象，通过识别它们是否被引用来确定哪些对象是已经死亡的、哪些仍需要被使用。已经不再被应用程序的root或者别的对象所引用的对象就是已经死亡的对象，即所谓的垃圾，需要被回收（回收的是该对象占用的内存空间）。这就是GC工作的原理。为了实现这个原理，GC有多种算法。比较常见的算法有Reference Counting，Mark Sweep，Copy Collection等等。目前主流的虚拟系统.NET CLR，Java VM和Rotor都是采用的Mark Sweep算法。
JVM堆相关知识 为什么先说JVM堆?
JVM的堆是Java对象的活动空间，程序中的类的对象从中分配空间，其存储着正在运行着的应用程序用到的所有对象。这些对象的建立方式就是那些new一类的操作，当对象无用后，是GC来负责这个无用的对象。
JVM堆
(1) 新域：存储所有新成生的对象 新域会被分为3个部分：1.第一个部分叫Eden。2.另两个部分称为辅助生存空间(幼儿园)，我这里一个称为A空间(From sqace)，一个称为B空间(To Space)。
(2) 旧域：新域中的对象，经过了一定次数的GC循环后，被移入旧域
(3)永久域：存储类和方法对象，从配置的角度看，这个域是独立的，不包括在JVM堆内。默认为4M。�
垃圾回收的原因
从计算机组成的角度来讲，所有的程序都是要驻留在内存中运行的。而内存是一个限制因素(大小)。除此之外，托管堆也有大小限制。因为地址空间和存储的限制因素，托管堆要通过垃圾回收机制，来维持它的正常运作，保证对象的分配，尽可能不造成“内存溢出”。
垃圾回收的基本原理（算法思路都是一致的：把所有对象组成一个集合，或可以理解为树状结构，从树根开始找，只要可以找到的都是活动对象，如果找不到，这个对象就被回收了）
垃圾回收分为两个阶段：
标记 --> 压缩标记的过程，其实就是判断对象是否可达的过程。当所有的根都检查完毕后，堆中将包含可达(已标记)与不可达(未标记)对象。标记完成后，进入压缩阶段。在这个阶段中，垃圾回收器线性的遍历堆，以寻找不可达对象的连续内存块。并把可达对象移动到这里以节约内存空间。
垃圾收集算法
Mark-Sweep标记清理算法
阶段1: Mark-Sweep 标记清除阶段，先假设heap中所有对象都可以回收，然后找出不能回收的对象，给这些对象打上标记，最后heap中没有打标记的对象都是可以被回收的；
阶段2: Compact 压缩阶段，对象回收之后heap内存空间变得不连续，在heap中移动这些对象，使他们重新从heap基地址开始连续排列（节省内存资源）。
Heap内存经过回收、压缩之后，可以继续采用前面的heap内存分配方法， 即仅用一个指针记录heap分配的起始地址就可以。主要处理步骤：将线程挂起→确定roots→创建reachable objects graph→对象回收→heap压缩→指针修复。可以这样理解roots：heap中对象的引用关系错综复杂（交叉引用、循环引用），形成复杂的 graph，roots是CLR在heap之外可以找到的各种入口点。
GC搜索roots的地方包括全局对象、静态变量、局部对象、函数调用参数、当前CPU寄存器中的对象指针（还有finalization queue）等。主要可以归为2种类型：已经初始化了的静态变量、线程仍在使用的对象（stack+CPU register）
指针修复是因为compact过程移动了heap对象，对象地址发生变化，需要修复所有引用指针，包括stack、CPU register中的指针以及heap中其他对象的引用指针。
复制算法
新生代的内存被划分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor。每次回收时，将Eden和Survivor中还存活着的对象一次性复制到另外一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。HotSpot虚拟机默认Eden区和Survivor区的比例为8:1，意思是每次新生代中可用内存空间为整个新生代容量的90%。当然，我们没有办法保证每次回收都只有不多于10%的对象存活，当Survivor空间不够用时，需要依赖老年代进行分配担保（Handle Promotion）。
标记整理算法
与标记清理算法过程一样，只是不直接清理可回收对象，而是将所有存活对象移动到一端，之后清理边界之外的对象内存
分代收集算法
现代商用虚拟机基本都采用分代收集算法来进行垃圾回收。这种算法没什么特别的，无非是上面内容的结合罢了，根据对象的生命周期的不同将内存划分为几块，然后根据各块的特点采用最适当的收集算法。大批对象死去、少量对象存活的（新生代），使用复制算法，复制成本低；对象存活率高、没有额外空间进行分配担保的（老年代），采用标记-清理算法或者标记-整理算法。
如何找到需要回收的对象
1、引用计数法：给对象中添加一个引用计数器，每当一个地方引用这个对象时，计数器值+1；当引用失效时，计数器值-1。任何时刻计数值为0的对象就是不可能再被使用的。
2、可达性分析法:对于可达性分析算法而言，未到达的对象并非是“非死不可”的，若要宣判一个对象死亡，至少需要经历两次标记阶段。
1. 如果对象在进行可达性分析后发现没有与GCRoots相连的引用链，则该对象被第一次标记并进行一次筛选，筛选条件为是否有必要执行该对象的finalize方法，若对象没有覆盖finalize方法或者该finalize方法已经被虚拟机执行过了（ finalize()在什么时候被调用? 有三种情况 1.所有对象被Garbage Collection时自动调用,比如运行System.gc()的时候. 2.程序退出时为每个对象调用一次finalize方法。 3.显式的调用finalize方法），则均视作不必要执行该对象的finalize方法，即该对象将会被回收。反之，若对象覆盖了finalize方法并且该finalize方法并没有被执行过，那么，这个对象会被放置在一个叫F-Queue的队列中，之后会由虚拟机自动建立的、优先级低的Finalizer线程去执行，而虚拟机不必要等待该线程执行结束，即虚拟机只负责建立线程，其他的事情交给此线程去处理。
2.对F-Queue中对象进行第二次标记，如果对象在finalize方法中拯救了自己，即关联上了GCRoots引用链，如把this关键字赋值给其他变量，那么在第二次标记的时候该对象将从“即将回收”的集合中移除，如果对象还是没有拯救自己，那就会被回收。它只能拯救自己一次，第二次就被回收了。此外，从我们可以得知，一个堆对象的this引用会永远存在，在方法体内可以将this引用赋值给其他变量，这样堆中对象就可以被其他变量所引用，即不会被回收.
Java有了GC同样会出现内存泄露问题
1.静态集合类像HashMap、Vector等的使用最容易出现内存泄露，这些静态变量的生命周期和应用程序一致，所有的对象Object也不能被释放，因为他们也将一直被Vector等应用着。
2.各种连接，数据库连接，网络连接，IO连接等没有显示调用close关闭，不被GC回收导致内存泄露。
3.监听器的使用，在释放对象的同时没有相应删除监听器的时候也可能导致内存泄露。
垃圾回收器负责回收所有无任何引用对象的内存空间。
注意：垃圾回收回收的是无任何引用的对象占据的内存空间而不是对象本身。
GC注意事项：
1、只管理内存，非托管资源，如文件句柄，GDI资源，数据库连接等还需要用户去管理。
2、循环引用，网状结构等的实现会变得简单。GC的标志-压缩算法能有效的检测这些关系，并将不再被引用的网状结构整体删除。
3、GC通过从程序的根对象开始遍历来检测一个对象是否可被其他对象访问，而不是用类似于COM中的引用计数方法。
4、GC在一个独立的线程中运行来删除不再被引用的内存。
5、GC每次运行时会压缩托管堆。
GC总结
[if !supportLists]1. [endif]JVM堆的大小决定了GC的运行时间。如果JVM堆的大小超过一定的限度，那么GC的运行时间会很长。2.对象生存的时间越长，GC需要的回收时间也越长，影响了回收速度。3.大多数对象都是短命的，所以，如果能让这些对象的生存期在GC的一次运行周期内，wonderful！4.应用程序中，建立与释放对象的速度决定了垃圾收集的频率。5.如果GC一次运行周期超过3-5秒，这会很影响应用程序的运行，如果可以，应该减少JVM堆的大小了。6.前辈经验之谈：通常情况下，JVM堆的大小应为物理内存的80%。
网友评论