java垃圾回收
参考文献:
http://blog.csdn.net/bocaicbl/article/details/5319915
1.垃圾收集算法的核心思想
Java语言建立了垃圾收集机制，用以跟踪正在使用的对象和发现并回收不再使用(引用)的对象。该机制可以有效防范动态内存分配中可能发生的两个危险：因内存垃圾过多而引发的内存耗尽，以及不恰当的内存释放所造成的内存非法引用。
垃圾收集算法的核心思想是：对虚拟机可用内存空间，即堆空间中的对象进行识别，如果对象正在被引用，那么称其为存活对象，反之，如果对象不再被引用，则为垃圾对象，可以回收其占据的空间，用于再分配。垃圾收集算法的选择和垃圾收集系统参数的合理调节直接影响着系统性能，因此需要开发人员做比较深入的了解。
Java垃圾回收机制（PS:2012-6-8）
Java的垃圾回收器要负责完成3件任务：a)分配内存、b)确保被引用的对象的内存不被错误回收以及c)回收不再被引用的对象的内存空间。垃圾回收是一个复杂而且耗时的操作。如果JVM花费过多的时间在垃圾回收上，则势必会影响应用的运行性能。一般情况下，当垃圾回收器在进行回收操作的时候，整个应用的执行是被暂时中止（stop-the-world）的。这是因为垃圾回收器需要更新应用中所有对象引用的实际内存地址(之所以要更新应用中所有对象引用的实际内存地址，是因为在垃圾回收以后进行了内存碎片整理，导致对象物理地址发生改变)。不同的硬件平台所能支持的垃圾回收方式也不同。比如在多CPU的平台上，就可以通过并行的方式来回收垃圾。而单CPU平台则只能串行进行。不同的应用所期望的垃圾回收方式也会有所不同。服务器端应用可能希望在应用的整个运行时间中，花在垃圾回收上的时间总数越小越好（这样只需要给服务器端某一个固定时间进行垃圾回收就可以了，类似魔兽世界每周二的服务器维护）。而对于与用户交互的应用来说，则可能希望所垃圾回收所带来的应用停顿的时间间隔越小越好（这样减少人机交互中出现长时间的等待）。对于这种情况，JVM中提供了多种垃圾回收方法以及对应的性能调优参数，应用可以根据需要来进行定制。
Java 垃圾回收机制最基本的做法是分代回收（Generation）。内存中的区域被划分成不同的世代，对象根据其存活的时间被保存在对应世代的区域中。一般的实现是划分成3个世代：年轻、年老和永久。内存的分配是发生在年轻世代中的。当一个对象存活时间足够长的时候，它就会被复制到年老世代中。对于不同的世代可以使用不同的垃圾回收算法。进行世代划分的出发点是对应用中对象存活时间进行研究之后得出的统计规律。一般来说，一个应用中的大部分对象的存活时间都很短。比如局部变量的存活时间就只在方法的执行过程中。基于这一点，对于年轻世代的垃圾回收算法就可以很有针对性。
年轻世代的内存区域被进一步划分成Eden空间、From Survivor空间、To Survivor空间等。Eden空间是进行内存分配的地方，是一块连续的空闲内存区域。在上面进行内存分配速度非常快，因为不需要进行可用内存块的查找。From Survivor空间和To Survivor空间两个存活区中始终有一个是空白的。在进行垃圾回收的时候，伊甸园和其中一个非空存活区From Survivor空间中还存活的对象根据其存活时间被复制到当前空白的存活区To Survivor空间或年老世代中。经过这一次的复制之后，之前非空的存活区To Survivor空间中包含了当前还存活的对象，而伊甸园和另一个存活区From Survivor空间中的内容已经不再需要了，只需要简单地把这两个区域清空即可。下一次垃圾回收的时候，这两个存活区的角色就发生了交换。一般来说，年轻世代区域较小，而且大部分对象都已经不再存活，因此在其中查找存活对象的效率较高。
而对于年老和永久世代的内存区域，则采用的是不同的回收算法，称为“标记-清除-压缩（Mark-Sweep-Compact）”。标记的过程是找出当前还存活的对象，并进行标记；清除则遍历整个内存区域，找出其中需要进行回收的区域；而压缩则把存活对象的内存移动到整个内存区域的一端，使得另一端是一块连续的空闲区域，方便进行内存分配和复制。
JDK 5中提供了4种不同的垃圾回收机制。最常用的是串行回收方式，即使用单个CPU回收年轻和年老世代的内存。在回收的过程中，应用程序被暂时中止。回收方式使用的是上面提到的最基本的分代回收。串行回收方式适合于一般的单CPU桌面平台。如果是多CPU的平台，则适合的是并行回收方式。这种方式在对年轻世代进行回收的时候，会使用多个CPU来并行处理，可以提升回收的性能。并发标记-清除回收方式适合于对应用的响应时间要求比较 高的情况，即需要减少垃圾回收所带来的应用暂时中止的时间。这种做法的优点在于可以在应用运行的同时标记存活对象与回收垃圾，而只需要暂时中止应用比较短的时间。
通过JDK中提供的JConsole可以很容易的查看当前应用的内存使用情况。在JVM启动的时候添加参数 -verbose:gc 可以查看垃圾回收器的运行结果。
2.触发主GC(Garbage Collector)的条件
JVM进行次GC的频率很高,但因为这种GC占用时间极短,所以对系统产生的影响不大。更值得关注的是主GC的触发条件,因为它对系统影响很明显。总的来说,有两个条件会触发主GC:
(1)当应用程序空闲时,即没有应用线程在运行时,GC会被调用。因为GC在优先级最低的线程中进行,所以当应用忙时,GC线程就不会被调用,但以下条件除外。
(2)Java堆内存不足时,GC会被调用。当应用线程在运行,并在运行过程中创建新对象,若这时内存空间不足,JVM就会强制地调用GC线程,以便回收内存用于新的分配。若GC一次之后仍不能满足内存分配的要求,JVM会再进行两次GC作进一步的尝试,若仍无法满足要求,则 JVM将报“out of memory”的错误,Java应用将停止。
——————————————————————————————————————————————
为什么执行一次GC以后内存不够还要再执行两次GC呢？（PS：2012-6-8）
根据之前写过的一篇博客：JVM概念之Java对象的大小与引用类型，在文中提到：“软引用一般被做为缓存来使用。与强引用的区别是，软引用在垃圾回收时，虚拟机会根据当前系统的剩余内存来决定是否对软引用进行回收。如果剩余内存比较紧张，则虚拟机会回收软引用所引用的空间;如果剩余内存相对富裕，则不会进行回收。换句话说，虚拟机在发生OutOfMemory时，肯定是没有软引用存在的。”我认我为之所以还需要再执行两次GC以后JVM才决定是否报“out of memory”的错误是因为这两次GC都是去回收软引用去了，如果在回收了软引用以后内存够了，那么就分配内存空间，如果回收了软引用还是内存不够，那么就报“out of memory”的错误。这也是为什么文中强调：“虚拟机在发生OutOfMemory时，肯定是没有软引用存在的。”
——————————————————————————————————————————————
由于是否进行主GC由JVM根据系统环境决定,而系统环境在不断的变化当中,所以主GC的运行具有不确定性,无法预计它何时必然出现,但可以确定的是对一个长期运行的应用来说,其主GC是反复进行的。
3.减少GC开销的措施
根据上述GC的机制,程序的运行会直接影响系统环境的变化,从而影响GC的触发。若不针对GC的特点进行设计和编码,就会出现内存驻留等一系列负面影响。为了避免这些影响,基本的原则就是尽可能地减少垃圾和减少GC过程中的开销。具体措施包括以下几个方面:
(1)不要显式调用System.gc()
此函数建议JVM进行主GC,虽然只是建议而非一定,但很多情况下它会触发主GC,从而增加主GC的频率,也即增加了间歇性停顿的次数。这里特别需要说明的是，在代码中显示的调用System.gc()，并不一定能够进行GC，这个我们可以通过finalize()方法进行验证，即主动调用System.gc()，并不一定每次都调用finalize()方法，具体可以参考博客final finally finalize 的区别中的代码实例。finalize()方法的特征是在对象被回收之前， 首先调用finalize()方法。
(2)尽量减少临时对象的使用
临时对象在跳出函数调用后,会成为垃圾,少用临时变量就相当于减少了垃圾的产生,从而延长了出现上述第二个触发条件出现的时间,减少了主GC的机会。
(3)对象不用时最好显式置为Null
一般而言,为Null的对象都会被作为垃圾处理,所以将不用的对象显式地设为Null,有利于GC收集器判定垃圾,从而提高了GC的效率。
(4)尽量使用StringBuffer,而不用String来累加字符串(详见blog另一篇文章JAVA中String与StringBuffer)
由于String是固定长的字符串对象,累加String对象时,并非在一个String对象中扩增,而是重新创建新的String对象,如 Str5=Str1+Str2+Str3+Str4,这条语句执行过程中会产生多个垃圾对象,因为对次作“+”操作时都必须创建新的String对象,但这些过渡对象对系统来说是没有实际意义的,只会增加更多的垃圾。避免这种情况可以改用StringBuffer来累加字符串,因StringBuffer 是可变长的,它在原有基础上进行扩增,不会产生中间对象。
(5)能用基本类型如Int,Long,就不用Integer,Long对象
基本类型变量占用的内存资源比相应对象占用的少得多,如果没有必要,最好使用基本变量。什么情况下需要使用Integer？这个视具体情况而定，比如类型转换，如果要求整形能够方便的转换成字符串类型，那么如果是Integer i=30，则直接可以视同String str=i.toString();来进行类型转换，但是如果使用的是int i=30，则没有i.toString()方法。
(6)尽量少用静态对象变量
静态变量属于全局变量,不会被GC回收,它们会一直占用内存。
(7)分散对象创建或删除的时间
集中在短时间内大量创建新对象,特别是大对象,会导致突然需要大量内存,JVM在面临这种情况时,只能进行主GC,以回收内存或整合内存碎片, 从而增加主GC的频率。集中删除对象,道理也是一样的。它使得突然出现了大量的垃圾对象,空闲空间必然减少,从而大大增加了下一次创建新对象时强制主GC 的机会。
4.垃圾回收算法
(1)引用计数收集器
引用计数是垃圾收集的早期策略。在这种方法中，堆中每一个对象都有一个引用计数。当一个对象被创建了，并且指向该对象的引用被分配给一个变量，这个对象的引用计数被设置为1。比如新建一个对象A a=new A();然后a被分配给另外一个变量b，也就是b=a;那么对象a的引用计数+1。当任何其他变量被赋值为对这个对象的引用时，计数加1。当一个对象的引用超过生存期或者被设置一个新的值时，对象的引用计数减1，比如令b=c，则a的引用计数-1。任何引用计数为0的对象可以被当做垃圾收集。当一个对象被垃圾收集的时候，它引用的任何对象计数减1。在这种方法中，一个对象被垃圾收集后可能导致后续其他对象的垃圾收集行动。比如A a=new A();b=a;当b被垃圾回收以后，a的引用计数变为0，这样导致a也被垃圾回收。
方法的好处：引用计数收集器可以很快执行，交织在程序的运行之中。这个提醒对于程序不能被长时间打断的实时环境很有利。
方法的坏处：引用计数无法检测出循环（即两个或者更多的对象互相引用）。循环的例子如，父对象有一个子对象的引用，子对象又反过来引用父对象。这样对象用户都不可能计数为0，就算它们已经无法被执行程序的根对象触及。还有一个坏处就是，每次引用计数的增加或者减少都带来额外的开销。
(2)追踪收集器
垃圾检测通常通过建立一个根对象的集合并且检查从这些根对象开始的可触及性来实现。如果正在执行的程序可以访问到的根对象和某个对象之间存在引用路径，这个对象就是可触及的。对于程序来说，根对象总是可以访问的。从这些根对象开始，任何可以被触及的对象都是被认为是“活动”的对象。无法被触及的对象被认为是垃圾，因为它们不在影响程序的未来执行。
跟踪收集器是追踪从根结点开始的对象引用图。在追踪过程中遇到的对象以某手方式打上标记。总的来说，要么在对象本身上设置标记，要么用一个独立的位图来设置标记。当追踪结束时，未被标记的对象就是无法触及的，从而可以被收集。
基本的追踪算法被称作“标记并清除”。这个名字指出垃圾手机的两个阶段。在标记阶段，垃圾收集器遍历引用树，标记每一个遇到的对象。在清除阶段，未被标记的对象被释放，释放对象后获得的内存被返回到正在执行的程序。在Java虚拟机中，清除步骤必须包括对象的终结。
