破除java神话（一） 垃圾收集解决所有的内存问题

核心提示：作者： Cherami 译对于java程序员而言，垃圾收集功能是一个非常大的帮助，破除java神话（一） 垃圾收集解决所有的内存问题，同时也是使用java语言的一个非常大的优势， 然而，可用内存越少，那么垃圾收集的执行次数越多，实际情况应该是不能因为垃圾收集可以清除无用的内存就不去考虑内存问题，这里要指明的是

　　作者： Cherami 译
　　对于java程序员而言，垃圾收集功能是一个非常大的帮助，同时也是使用java语言的一个非常大的优势。 然而，实际情况应该是不能因为垃圾收集可以清除无用的内存就不去考虑内存问题。这里要指明的是， 假如忽略这个问题，那么就会导致问题。
　　
　　首先，在不同的JVM上垃圾收集算法是不同的，因此，假如你想你的程序能够很好的运行在不同的JVM上，那么就不能依靠垃圾收集的特定行为。垃圾收集是一个非常活跃的研究问题，更好、更快并且更精确的收集器总在实现中。
　　
　　然而很多现代的垃圾收集器都有着同样的问题。其中一个是当他们运行时并非总是释放所有那些可以被收集的对象。
　　
　　分析表明java编程中大多对象的生存期是短暂的，因此，对于需要提高性能的收集器而言，他们会减少检查那些具有较长生命的对象的频度，这个是依据大多对象具有较短的生存期，而那些生存期较长的对象往往会被继续引用，因此，没有必要在每次检查时都去检查这样的对象是否可以被回收。
　　
　　要释放特定的对象的内存可能需要多次调用垃圾收集。你可以通过调用System.gc方法建议（注重是建议）垃圾收集器运行。请求这个方法的结果通常导致垃圾收集器进行一次完整的收集。通常这个比VM调用垃圾收集要更彻底和完全，也会尽可能快的完成。假如程序员显式的调用System.gc，那么推论是有更多的时间做更多的工作（请注重是有更多的事情做更多的事情，这意味着将进行大量的检查,还记得刚才的有关对长短生命期对象的检查的频度的变化吗？而不是真正彻底的清除）。在任何一种情况下（显式调用垃圾收集和VM调用垃圾收集）都不要假设所有可以被收集的对象会真正的被收集。
　　
　　显式的调用System.gc有更大的机会完成彻底的收集，但不是保证会完成。
　　
　　另一个程序员会碰到的麻烦是他们往往保持对那些不再需要的对象的引用。这将阻止垃圾收集器释放该对象。
　　
　　这种情况在你自己治理列表的时候会发生。
　　
　　考虑下面的ObjStack类。这个类使用push和pop方法治理堆栈中的对象。两个方法都利用索引，该索引指明堆栈中下一个可用的位置。push方法存储对新对象的引用并增加索引值，而pop方法减小索引值并返回堆栈最上面的元素。
　　
　　实例一：没有正确实现pop方法的ObjStack
　　
　　class ObjStack
　　
　　{
　　
　　PRivate Object[] stack;
　　
　　private int index;
　　
　　public void push(Object o)
　　
　　{
　　
　　stack[index] = o;
　　
　　index++;
　　
　　}
　　
　　public Object pop()
　　
　　{
　　
　　index-;
　　
　　return stack[index];
　　
　　}
　　
　　//...
　　
　　}
　　
　　现在创建一个容量为10的对象，然后调用8次push方法向它添加对象，那么此时索引值为8。
　　
　　现在考虑三次调用pop方法后发生什么？此时的索引值为5，但是请注重，除了这个索引值发生变化外堆栈其实没有其它任何变化！
　　
　　虽然pop方法减小了索引值，但是实际上堆栈仍然保持着对那些对象的引用。调用pop方法往往意味着那些对象应该被收集（大多情况是如此的，即使不是马上，也是在稍后使用完该对象后）。然而由于堆栈仍然保留有对该对象的引用，它就不能被收集。这些对象只能在调用push后被替换才可能被收集。正确的pop的实现如下：
　　
　　public Object pop()
　　
　　{
　　
　　index-;
　　
　　Object o = stack[index];
　　
　　stack[index] = null;
　　
　　return o;
　　
　　}
　　
　　在这个版本的pop方法中，当引用被返回后，堆栈删除对他们的引用因此垃圾收集器在以后可以回收他们。
　　
　　在你自己的编码中，对于那些不需要的对象，不要在引用它们！程序的执行极大收到可用内存的影响，可用内存越少，那么垃圾收集的执行次数越多，这将极大的伤害性能。