JAVA垃圾收集机制剖析

时间  2019-12-01
标签 java 垃圾 收集 机制 剖析 栏目 Java 繁體版
原文   原文链接

1.垃圾收集算法的核心思想java

　　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是重复进行的。post

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()方法里。

 

java 代码
  1. protected void finalize()    
  2. 　　 {    
  3. 　　 // finalization code here    
  4. 　　 }  

 

⑶代码演示样例

java 代码
  1. class Garbage{    
  2. 　　 int index;    
  3. 　　 static int count;    
  4.   
  5. 　　 Garbage() {    
  6. 　　 count++;    
  7. 　　 System.out.println("object "+count+" construct");    
  8. 　　 setID(count);    
  9. 　　 }    
  10.   
  11. 　　 void setID(int id) {    
  12. 　　 index=id;    
  13. 　　 }    
  14.   
  15. 　　 protected void finalize() //重写finalize方法    
  16. 　　 {    
  17. 　　 System.out.println("object "+index+" is reclaimed");    
  18. 　　 }    
  19.   
  20. 　　 public static void main(String[] args)    
  21. 　　 {    
  22. 　　 new Garbage();    
  23. 　　 new Garbage();    
  24. 　　 new Garbage();    
  25. 　　 new Garbage();    
  26. 　　 System.gc(); //请求执行垃圾收集器    
  27. 　　 }    
  28.   
  29. 　}  

5.Java 内存泄漏 
　　因为採用了垃圾回收机制，不论什么不可达对象(对象再也不被引用)都可以由垃圾收集线程回收。所以一般说的Java 内存泄漏事实上是指无心识的、非有益的对象引用，或者无心识的对象保持。无心识的对象引用是指代码的开发者原本已经对对象使用完成，却因为编码的错误而意外地保存了对该对象的引用(这个引用的存在并不是编码人员的主观意愿)，从而使得该对象一直没法被垃圾回收器回收掉，这样的原本觉得可以释放掉的却终于未能被释放的空间可以以为是被“泄漏了”。

　　考虑如下的程序,在ObjStack类中,使用push和pop方法来管理堆栈中的对象。两个方法中的索引(index)用于指示堆栈中下一个可用位置。push方法存储对新对象的引用并添加索引值,而pop方法减少索引值并返回堆栈最上面的元素。在main方法中,建立了容量为64的栈,并64次调用push方法向它加入对象,此时index的值为64,随后又32次调用pop方法,则index的值变为32,出栈意味着在堆栈中的空间应该被收集。

但其实,pop方法仅仅是减少了索引值,堆栈仍然保持着对那些对象的引用。

故32个无用对象不会被GC回收,形成了内存渗漏。

 

java 代码
public  class ObjStack {    
  1. 　　 private Object[] stack;    
  2. 　　 private int index;    
  3. 　　 ObjStack(int indexcount) {    
  4. 　　 stack = new Object[indexcount];    
  5. 　　 index = 0;    
  6. 　　 }    
  7. 　　 public void push(Object obj) {    
  8. 　　 stack[index] = obj;    
  9. 　　 index++;    
  10. 　　 }    
  11. 　　 public Object pop() {    
  12. 　　 index--;    
  13. 　　 return stack[index];    
  14. 　　 }    
  15. 　　 }    
  16. 　　 public class Pushpop {    
  17. 　　 public static void main(String[] args) {    
  18. 　　 int i = 0;    
  19. 　　 Object tempobj;    
  20.   
  21. //new一个ObjStack对象。并调用有參构造函数。分配stack Obj数组的空间大小为64，可以存64个对象。从0開始存储   
  22. 　　 ObjStack stack1 = new ObjStack(64);   
  23.   
  24. 　　 while (i < 64)    
  25. 　　 {    
  26. 　　 tempobj = new Object();//循环new Obj对象。把每次循环的对象一一存放在stack Obj数组中。

        

  27. 　　 stack1.push(tempobj);    
  28. 　　 i++;    
  29. 　　 System.out.println("第" + i + "次进栈" + "\t");    
  30. 　　 }    
  31.   
  32. 　　 while (i > 32)    
  33. 　　 {    
  34. 　　 tempobj = stack1.pop();//这里形成了空间的浪费。    
  35. 　　 //正确的pop方法可改为例如如下所指示,当引用被返回后,堆栈删除对他们的引用,所以垃圾收集器在之后可以回收他们。

        

  36. 　　 /*   
  37. 　　 * public Object pop() {index - -;Object temp = stack [index];stack [index]=null;return temp;}   
  38. 　　 */    
  39. 　　 i--;    
  40. 　　 System.out.println("第" + (64 - i) + "次出栈" + "\t");    
  41. 　　 }    
  42. 　　 }    
  43. 　　 }  

 

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的活动，肯定内存使用量是否随着时间添加。假设确实如此，就可能发生了内存泄漏。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程