与垃圾收集器（Garbage Collector）为伴

• 
  垃圾收集器（Garbage Collector（GC））是一直伴随着 Java 程序员的最有争议的问题之一。我们接受了独立的收集器的原则，但是控制该收集器的迫切需要常常被证明是不可抗拒的。典型情况下，您用好了一个或多个资源，并指望它们会被回收。但它们并没有被回收。一定出现了问题！IBM 为我们提供了一种强行执行 GC 的方法 ? 调用 System.gc()，那么使用这一调用就一定没有问题，是这样吗？ 错。几乎总是错的。
  
  GC 称为“内存管理器”会更好，因为这是它真正做的事情。同 C/C++ 一样，它根据应用程序的请求分配内存。但是与 C/C++ 不同的是，内存释放是 GC 单独执行的。因为内存管理的复杂性中 99% 与未使用内存的自动定位及释放有关。一般我们提到“GC”就是指 Java 内存管理。
  
  Java 虚拟机（Java virtual machine（JVM））有它自己的内存池。我们不使用一般的本地方法，如 malloc。当然，这个内存池只是从本机 OS 中分配的一大块。Java 内存被称作堆。当 Java 对象需要内存时，就从堆中进行内存分配。
  
  通常，JVM 在被要求时才对内存进行分配。当且仅当内存分配发生错误（内存溢出）时才执行 GC。
  
  是的，是的，我知道 Java 1.1.8 有“异步 GC”操作。在 IBM Java SDK 中，这个循环实际上从未被激活。因为性能的缘故，异步 GC 操作被配置成只有在您的应用程序确实什么事也不做的时候才会运行。即使您的应用程序静止，也要经过相当长时间的超时，异步 GC 才会运行。在 Java 2 中已经没有异步操作了。
  
  因此，对于 IBM Java SDK 来说，GC 完全是一个同步操作，而且仅在内存分配发生错误时才发生。
  
  GC 的工作方式
  我们当然不会完整地讨论这些内容；关于这一主题已经有整本专著问世了。我们只要讨论基础知识。
  
  GC 通过扫描 JVM 里运行的所有线程的堆栈和寄存器来执行。如果它发现有些东西似乎是对 Java 堆内的引用，GC 将会继续查下去。如果该引用确实是对对象的引用，那么 GC 将跟随该对象内的所有引用。被引用的对象以及该对象所引用的所有对象都将被“标记”（或标志）。
  
  显然，只有在线程被中止的情况下它才能起作用，因此，GC 要停止 JVM 里的所有线程才能开始执行，当然，其中不包括它正在其上运行的那个线程。
  
  标记阶段结束时，GC 会扫描堆，并对照在标记阶段标志的那些对象检查堆里的所有对象。任何没有被标记的对象都是没有被任何线程引用的对象，因而，这些对象将会被回收并被放回到空闲池。
  
  此处需要指出的重点是：
  
  GC 是一个停止一切的操作。
  GC 是一个同步操作。
  GC 需要扫描每个线程的堆栈。
  GC 需要扫描整个 Java 堆。
  就 CPU 使用和时间而言，GC 操作代价高昂。这就是我们要尽可能减少它的执行的原因。虽然它效率极高，但在一个有许多线程并且堆的大小达多兆字节的环境中运行需要时间。
  
  这解释了相当常见的说法 －“我的对象在应该被回收的时候并没有被回收”。它们符合被回收的条件；可是没有必要运行 GC，所以它并没有执行。
  
  System.gc()
  System.gc() 是“内存分配错误是运行 GC 的唯一原因”这一规则的一个例外。
  
  虽然这可能是一种例外情况，但并不是一个好主意。请相信我。
  
  文档说明该调用设置了一个标志，该标志表明在 JVM 非常想要时可以运行 GC。System.gc() 调用实际上做的事情是：如果调用它的时候有一个 GC 循环正在运行，那么就?略这次调用；否则，就开始一次完整的 GC 循环。
  
  这就是说，每次（或 99.9% 次）调用 System.gc() 的时候，您都会开始一个完整的 GC 循环。也许根本没有必要运行 GC，但是您还是强行让它执行完整个标记／扫描过程。您完全可以把 System.gc() 看作是 System.StopEverythingForAWhile() 调用或 System.SlugMyPerfomance() 调用。
  
  对于这个调用，有一个可能的正当理由。因为如果没有这个调用，直到堆用完 GC 才会运行。如果您有一个千兆字节的堆，在 GC 清理全部垃圾时，您将遭到相当大的打击，然后您可能会考虑以固定间隔强行执行一个 GC 循环以达到“少量多次”的效果。但是，在这种情况下，您考虑调整堆的大小会更好些。
  
  我们为什么要强行执行 GC？
  到处散布 System.gc() 调用的诱惑非常大。在某一阶段，我们总是遇到“内存溢出”的问题，第一反应是认为 GC 出了问题，并强行执行一个循环。尽管这常常能改善局面（至少是暂时能），并且似乎验证了“GC 出了问题”这一想法，但事实也许并非如此。
  
  请记住，GC 处于食物链的底部。由于 GC 的常规操作是彻底检查系统运行时的状态，所以代码中其它地方所犯的错误常常会被 GC 暴露出来。这样，别处所犯的错误导致 GC 没有响应，而程序员认为 JVM 是在 GC 处异常结束的。因此，应该是 GC 的问题。追查要从定位问题开始，因此，我们强行让 GC 在代码中的不同地方执行。不幸的是，一旦了解了 GC 查出的问题的真相，我们总是会忘记删除所有那些 System.gc() 调用。
  
  在一天结束时，最终在您的代码中会有成十、成百或者上千个强行执行 GC 的调用（您有多少个呢？）。除了缓慢的性能和在强制执行的非必要 GC 循环上花费过多的时间之外，这使您一无所获。当允许 GC 按您预想的那样运行时，您可能会感到吃惊，一个劣等系统的响应速度也如此之快。
• [1] [2] 下一页 
• 复制本页网址和标题，发送给你QQ/Msn的好友一起分享
  
  
• 与垃圾收集器（Garbage Collector）为伴 相关文章：
• ·与垃圾收集器（Garbage Collector）为伴
• 与垃圾收集器（Garbage Collector）为伴 相关软件

上一篇:再聚Java One

下一篇:有效地对软件进行交互式诊断的技术和工具

• 特别声明：本站除部分特别声明禁止转载的专稿外的其他文章可以自由转载，但请务必注明出处和原始作
• 者.文章版权归文章原始作者所有.对于被本站转载文章的个人和网站，我们表示深深的谢意。如果本站转
• 载的文章有版权问题请联系编辑人员,我们尽快予以更正. 转载请注明来源：http://www.hackhome.com

精品推荐

热点TOP10

特别推荐