JAVA垃圾收集机制剖析
1.垃圾收集算法的核心思想
Java语言建立了垃圾收集机制,用以跟踪正在使用的对象和发现并回收不再使用(引用)的对象。该机制能够有效防范动态内存分配中可能发生的两个危急:因内存垃圾过多而引发的内存耗尽,以及不恰当的内存释放所造成的内存非法引用。
垃圾收集算法的核心思想是:对虚拟机可用内存空间,即堆空间中的对象进行识别。假设对象正在被引用。那么称其为存活对象,反之。假设对象不再被引用,则为垃圾对象。能够回收其占领的空间,用于再分配。垃圾收集算法的选择和垃圾收集系统參数的合理调节直接影响着系统性能。因此须要开发者做比較深入的了解。
2.触发主GC(Garbage Collector)的条件
JVM进行次GC的频率非常高,但由于这样的GC占用时间极短,所以对系统产生的影响不大。更值得关注的是主GC的触发条件,由于它对系统影响非常明显。
总的来说,有两个条件会触发主GC:
①当应用程序空暇时,即没有应用线程在执行时,GC会被调用。由于GC在优先级最低的线程中进行,所以当应用忙时,GC线程就不会被调用,但下面条件除外。
②Java堆内存不足时,GC会被调用。当应用线程在执行,并在执行过程中创建新对象,若这时内存空间不足,JVM就会强制地调用GC线程,以便回收内存用于新的分配。
若GC一次之后仍不能满足内存分配的要求,JVM会再进行两次GC作进一步的尝试,若仍无法满足要求,则 JVM将报“out of memory”的错误,Java应用将停止。
因为是否进行主GC由JVM依据系统环境决定,而系统环境在不断的变化其中,所以主GC的执行具有不确定性,无法估计它何时必定出现,但能够确定的是对一个长期执行的应用来说,其主GC是重复进行的。
3.降低GC开销的措施
依据上述GC的机制,程序的执行会直接影响系统环境的变化,从而影响GC的触发。若不针对GC的特点进行设计和编码,就会出现内存驻留等一系列负面影响。
为了避免这些影响,主要的原则就是尽可能地降低垃圾和降低GC过程中的开销。详细措施包含下面几个方面:
(1)不要显式调用System.gc()
此函数建议JVM进行主GC,尽管仅仅是建议而非一定,但非常多情况下它会触发主GC,从而添加主GC的频率,也即添加了间歇性停顿的次数。
(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对象
基本类型变量占用的内存资源比对应对象占用的少得多,假设没有必要,最好使用基本变量。
(6)尽量少用静态对象变量
静态变量属于全局变量,不会被GC回收,它们会一直占用内存。
(7)分散对象创建或删除的时间
集中在短时间内大量创建新对象,特别是大对象,会导致突然须要大量内存,JVM在面临这样的情况时,仅仅能进行主GC,以回收内存或整合内存碎片,从而添加主GC的频率。
集中删除对象,道理也是一样的。它使得突然出现了大量的垃圾对象,空暇空间必定降低,从而大大添加了下一次创建新对象时强制主GC的机会。
4.gc与finalize方法
⑴gc方法请求垃圾回收
使用System.gc()能够无论JVM使用的是哪一种垃圾回收的算法,都能够请求Java的垃圾回收。
须要注意的是,调用System.gc()也不过一个请求。JVM接受这个消息后。并非马上做垃圾回收,而不过对几个垃圾回收算法做了加权,使垃圾回收操作easy发生。或提早发生。或回收较多而已。
⑵finalize方法透视垃圾收集器的执行
在JVM垃圾收集器收集一个对象之前 。一般要求程序调用适当的方法释放资源,但在没有明白释放资源的情况下,Java提供了缺省机制来终止化该对象释放资源,这种方法就是finalize()。它的原型为:
protected void finalize() throws Throwable
在finalize()方法返回之后,对象消失,垃圾收集開始运行。原型中的throws Throwable表示它能够抛出不论什么类型的异常。
因此,当对象即将被销毁时,有时须要做一些善后工作。
能够把这些操作写在finalize()方法里。
- protected void finalize()
- {
- // finalization code here
- }
⑶代码演示样例
- class Garbage{
- int index;
- static int count;
- Garbage() {
- count++;
- System.out.println("object "+count+" construct");
- setID(count);
- }
- void setID(int id) {
- index=id;
- }
- protected void finalize() //重写finalize方法
- {
- System.out.println("object "+index+" is reclaimed");
- }
- public static void main(String[] args)
- {
- new Garbage();
- new Garbage();
- new Garbage();
- new Garbage();
- System.gc(); //请求执行垃圾收集器
- }
- }
5.Java 内存泄漏
由于採用了垃圾回收机制,不论什么不可达对象(对象不再被引用)都能够由垃圾收集线程回收。因此通常说的Java 内存泄漏事实上是指无意识的、非有益的对象引用,或者无意识的对象保持。无意识的对象引用是指代码的开发者本来已经对对象使用完成,却由于编码的错误而意外地保存了对该对象的引用(这个引用的存在并非编码人员的主观意愿),从而使得该对象一直无法被垃圾回收器回收掉,这样的本来以为能够释放掉的却终于未能被释放的空间能够觉得是被“泄漏了”。
考虑以下的程序,在ObjStack类中,使用push和pop方法来管理堆栈中的对象。两个方法中的索引(index)用于指示堆栈中下一个可用位置。push方法存储对新对象的引用并添加索引值,而pop方法减小索引值并返回堆栈最上面的元素。在main方法中,创建了容量为64的栈,并64次调用push方法向它加入对象,此时index的值为64,随后又32次调用pop方法,则index的值变为32,出栈意味着在堆栈中的空间应该被收集。
但其实,pop方法仅仅是减小了索引值,堆栈仍然保持着对那些对象的引用。
故32个无用对象不会被GC回收,造成了内存渗漏。
- private Object[] stack;
- private int index;
- ObjStack(int indexcount) {
- stack = new Object[indexcount];
- index = 0;
- }
- public void push(Object obj) {
- stack[index] = obj;
- index++;
- }
- public Object pop() {
- index--;
- return stack[index];
- }
- }
- public class Pushpop {
- public static void main(String[] args) {
- int i = 0;
- Object tempobj;
- //new一个ObjStack对象。并调用有參构造函数。分配stack Obj数组的空间大小为64,能够存64个对象。从0開始存储
- ObjStack stack1 = new ObjStack(64);
- while (i < 64)
- {
- tempobj = new Object();//循环new Obj对象。把每次循环的对象一一存放在stack Obj数组中。
- stack1.push(tempobj);
- i++;
- System.out.println("第" + i + "次进栈" + "\t");
- }
- while (i > 32)
- {
- tempobj = stack1.pop();//这里造成了空间的浪费。
- //正确的pop方法可改成例如以下所指示,当引用被返回后,堆栈删除对他们的引用,因此垃圾收集器在以后能够回收他们。
- /*
- * public Object pop() {index - -;Object temp = stack [index];stack [index]=null;return temp;}
- */
- i--;
- System.out.println("第" + (64 - i) + "次出栈" + "\t");
- }
- }
- }
6.怎样消除内存泄漏
尽管Java虚拟机(JVM)及其垃圾收集器(garbage collector,GC)负责管理大多数的内存任务,Java软件程序中还是有可能出现内存泄漏。实际上,这在大型项目中是一个常见的问题。避免内存泄漏的第一步是要弄清楚它是怎样发生的。
本文介绍了编写Java代码的一些常见的内存泄漏陷阱,以及编写不泄漏代码的一些最佳实践。一旦发生了内存泄漏,要指出造成泄漏的代码是很困难的。因此本文还介绍了一种新工具。用来诊断泄漏并指出根本原因。
该工具的开销很小。因此能够使用它来寻找处于生产中的系统的内存泄漏。
垃圾收集器的作用
尽管垃圾收集器处理了大多数内存管理问题,从而使编程人员的生活变得更轻松了,可是编程人员还是可能犯错而导致出现内存问题。简单地说。GC循环地跟踪全部来自“根”对象(堆栈对象、静态对象、JNI句柄指向的对象,诸如此类)的引用。并将全部它所能到达的对象标记为活动的。程序仅仅能够操纵这些对象;其它的对象都被删除了。由于GC使程序不可能到达已被删除的对象。这么做就是安全的。
尽管内存管理能够说是自己主动化的,可是这并不能使编程人员免受思考内存管理问题之苦。
比如。分配(以及释放)内存总会有开销,尽管这样的开销对编程人员来说是不可见的。创建了太多对象的程序将会比完毕相同的功能而创建的对象却比較少的程序更慢一些(在其它条件相同的情况下)。
并且,与本文更为密切相关的是。假设忘记“释放”先前分配的内存,就可能造成内存泄漏。假设程序保留对永远不再使用的对象的引用,这些对象将会占用并耗尽内存,这是由于自己主动化的垃圾收集器无法证明这些对象将不再使用。
正如我们先前所说的。假设存在一个对对象的引用,对象就被定义为活动的。因此不能删除。为了确保能回收对象占用的内存,编程人员必须确保该对象不能到达。
这一般是通过将对象字段设置为null或者从集合(collection)中移除对象而完毕的。
可是。注意,当局部变量不再使用时,没有必要将其显式地设置为null。对这些变量的引用将随着方法的退出而自己主动清除。
概括地说,这就是内存托管语言中的内存泄漏产生的主要原因:保留下来却永远不再使用的对象引用。
典型泄漏
既然我们知道了在Java中确实有可能发生内存泄漏。就让我们来看一些典型的内存泄漏及其原因。
全局集合
在大的应用程序中有某种全局的数据储存库是非经常见的,比如一个JNDI树或一个会话表。在这些情况下。必须注意管理储存库的大小。必须有某种机制从储存库中移除不再须要的数据。
这可能有多种方法,可是最常见的一种是周期性执行的某种清除任务。该任务将验证储存库中的数据,并移除不论什么不再须要的数据。
还有一种管理储存库的方法是使用反向链接(referrer)计数。然后集合负责统计集合中每一个入口的反向链接的数目。这要求反向链接告诉集合何时会退出入口。当反向链接数目为零时,该元素就能够从集合中移除了。
缓存
缓存是一种数据结构。用于高速查找已经运行的操作的结果。
因此。假设一个操作运行起来非常慢,对于经常使用的输入数据,就能够将操作的结果缓存。并在下次调用该操作时使用缓存的数据。
缓存通常都是以动态方式实现的。当中新的结果是在运行时加入到缓存中的。
典型的算法是:
检查结果是否在缓存中,假设在。就返回结果。
假设结果不在缓存中。就进行计算。
将计算出来的结果加入到缓存中,以便以后对该操作的调用能够使用。
该算法的问题(或者说是潜在的内存泄漏)出在最后一步。假设调用该操作时有相当多的不同输入,就将有相当多的结果存储在缓存中。
非常明显这不是正确的方法。
为了预防这样的具有潜在破坏性的设计,程序必须确保对于缓存所使用的内存容量有一个上限。因此,更好的算法是:
检查结果是否在缓存中。假设在,就返回结果。
假设结果不在缓存中,就进行计算。
假设缓存所占的空间过大,就移除缓存最久的结果。
将计算出来的结果加入到缓存中。以便以后对该操作的调用能够使用。
通过始终移除缓存最久的结果。我们实际上进行了这种如果:在将来,比起缓存最久的数据,近期输入的数据更有可能用到。这一般是一个不错的如果。
新算法将确保缓存的容量处于提前定义的内存范围之内。确切的范围可能非常难计算。由于缓存中的对象在不断变化,并且它们的引用包罗万象。为缓存设置正确的大小是一项非常复杂的任务。须要将所使用的内存容量与检索数据的速度加以平衡。
解决问题的还有一种方法是使用java.lang.ref.SoftReference类跟踪缓存中的对象。这样的方法保证这些引用可以被移除。假设虚拟机的内存用尽而须要很多其它堆的话。
ClassLoader
Java ClassLoader结构的使用为内存泄漏提供了很多可乘之机。正是该结构本身的复杂性使ClassLoader在内存泄漏方面存在如此多的问题。ClassLoader的特别之处在于它不仅涉及“常规”的对象引用,还涉及元对象引用。比方:字段、方法和类。这意味着仅仅要有对字段、方法、类或ClassLoader的对象的引用,ClassLoader就会驻留在JVM中。
由于ClassLoader本身能够关联很多类及其静态字段。所以就有很多内存被泄漏了。
确定泄漏的位置
通常发生内存泄漏的第一个迹象是:在应用程序中出现了OutOfMemoryError。这通常发生在您最不愿意它发生的生产环境中,此时差点儿不能进行调试。有可能是由于測试环境执行应用程序的方式与生产系统不全然同样,因而导致泄漏仅仅出如今生产中。
在这样的情况下。须要使用一些开销较低的工具来监控和查找内存泄漏。还须要可以无需重新启动系统或改动代码就行将这些工具连接到正在执行的系统上。
可能最重要的是。当进行分析时,须要可以断开工具而保持系统不受干扰。
尽管OutOfMemoryError通常都是内存泄漏的信号,可是也有可能应用程序确实正在使用这么多的内存;对于后者,或者必须添加JVM可用的堆的数量,或者相应用程序进行某种更改,使它使用较少的内存。可是。在很多情况下。OutOfMemoryError都是内存泄漏的信号。一种查明方法是不间断地监控GC的活动,确定内存使用量是否随着时间添加。假设确实如此,就可能发生了内存泄漏。