垃圾收集器是一个“宝贝收藏家”？

 

原文请看：http://java.dzone.com/articles/gc-goodstuff-collector

 

 

对象创建与销毁真的性能很低，造成垃圾大量回收吗？对象的重用真的如所想的那么高效吗？垃圾收集器的职责真的是回收垃圾吗？一系列看似很显然的问题你一定不屑一顾。但看完本文，相信你也许会重新看待这类看似“简单”的问题。

 

 

 

正文

 

 

在过于的几个月里，我注意到大家普遍对创建Java对象而感到恐怖。当我度着询问作者缘由时，似乎总是异口同声的将这一切归结为——为了得到更高的性能，避免垃圾收集总是合理的。

 

 

那么既然如此，为什么人们还要创建更多的对象呢？这个呢，其中一个原因就是为了让代码更具可读性。比如说，封装一个算法，然后使用一个合适的helper object来表示该算法会显示更加清晰优雅。

 

 

即使当代码没有被封装在helper object中，也会更倾向于的将它的一个实例反复的重用，避免垃圾回收，从而使得性能表现更加出众。我的第一条建议永远是：“你应该事先衡量这样是否真的有效。”如果要我说的更清楚点，那就是“如果你无法证明创建少的对象可以提高性能，那么很有可能它真就不是这样。”我已经从事许多关于优化的工作，得到一个结论就是：在某一个语言上优化的的正确结果对其它语言还说并不一定就是对的（也就是说，语言之间的优化方式是不可直接复制的）。那怕就算你使用相同的语言，不同的机器之间的优化也不尽相同，说不定在该机器上的最优方案到那台机器反而会性能降低。最后，甚至同一台机器上的不同方面的优化也是不同的。

 

 

如果创建了一个临时对象，它的生命周期只有你所预料的那么长，将有以下几点好处：

 

1.       当你使用它的时候，它总是处于最原始的状态，不用担心被人使用过

2.       你的代码又向线程安全迈了一大步

3.       你的代码可读性更佳，并易于分析

4.       垃圾收集器几乎做很少的工作。

 

 

“什么？”你立马反驳道，“垃圾收集器会因为要收集更多的垃圾而工作的更少？”

 

 

确实如此。当我们听到“垃圾收集器”的时候，我们总是习惯的认为它总是会在垃圾堆满整个heap(堆)的时候，才会开始工作，然后将所有的垃圾一扫而光。但实际上垃圾收集器甚至都不知道垃圾的存在。垃圾的定义就是指那些不可达的对象。垃圾收集器实际上做的就是创建一个新的heap，把你想保留的对象统统都搬过去，然后让原有的heap和剩下所谓的垃圾都“随风而逝”。因此垃圾收集器所做的一切实际上就是让对象“存活”（并不是我们所认为的充当收集者的角色）。看来垃圾收集器真是个goodstuff collector(宝贝收藏家，呵呵)。

)

 

 

这里我还要提一下就是我觉得不应该完全的依赖于finalize方法来掌控你的对象。（由于这样会做会冒著破坏原先回收机制的危险，这也许就解释了是为什么finalize影响性能的原因）。我所经历过的每一次单独测量和微型测试程序(microbenchmark)都使我确定创建和销毁对象永远不是最糟糕的，并且所表现出来的性能比起总是设法让对象存活的做法要有效的多。我的确做过一些试验，因为一开始我也不相信这一点。而其他人的观念又与我的测试完全相反，我不得不研究它了。要说明的一点是，这并不能证明上述内容适合于所有的场合，但我认为当你盲打莽撞的想进行性能优化时，这些东东还是有一定的指导意义的。

 

 

看看这篇来自IBM的文章，从上的数据可以看出：在Java里，分配（allocat）一个对象大概需要10条机器指令（比最好的C/C++分配器都要好一个数量级 ），然后你再猜猜抛弃一个对象的开销是多少？是零！因此只要记住GC是一个“宝贝收藏家”，那么就一定不会错啦。