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是反复进行的。ide

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接受这个消息后，并非当即作垃圾回收，而只是对几个垃圾回收算法作了加权，使垃圾回收操做容易发生，或提前发生，或回收较多而已。

　　⑵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教程