可视化Java垃圾回收

jopen 10年前

        英文原文: Visualizing Java Garbage Collection

        垃圾回收,就像双陆棋一样,只需几分钟来学习,但要用一生来精通。

        Ben Evans 是一名资深培训师兼顾问,他在演讲可视化垃圾回收中从基础谈起讨论了垃圾回收。

        以下是对其演讲的简短总结。

        基础

        当谈到释放不再使用的内存,垃圾回收已经在很大程度上取代了早期技术,比如手动内存管理和引用计数。

        这是件好事,因为内存管理令人厌烦,学究式地簿记是计算机擅长的,而不是人擅长的。在这方面,语言的运行时环境比人强。

        现代的垃圾回收非常高效,远远超过早期语言中典型的手工分配。通常,具有其它语言背景的人只盯着垃圾回收造成的中断,却没有完全理解自动内存管理发生作用的上下文环境。

        标记&清除是 Java(及其它运行时环境)用于垃圾回收的基本算法。

        在标记&清除算法中,引用会从每个线程栈的桢指向程序的堆。所以,从栈开始,循着指针找到所有可能的引用,然后再循着这些引用递归下去。

        当递归完成,就找到了所有的活对象,其它的都是垃圾。

        请注意,人们经常漏掉的一点是,运行时环境本身也有一个“分配清单(allocation list)”,上面列出了指向每个对象的指针,该列表由垃圾回收器负责维护,并帮助垃圾回收器进行垃圾清理。因此,运行时环境总是可以找出由它创建但尚未回收的对象。

可视化Java垃圾回收

        图一

        上面插图中所示的栈只是一个与单个应用程序线程相关的栈;每个应用程序线程都有一个类似的栈,每个栈本身都有一组指向堆的指针。

        如果垃圾回收器试图在应用程序运行过程中获取活对象的快照,那么它就要追踪运动着的目标,那样很容易漏掉一些严重超时的对象分配,因而无法获得 一个准确的快照。因此,“Stop the World”是有必要的;也就是,停止应用程序线程足够长的时间,以便捕获活对象的快照。

        下面是垃圾回收器必须遵循的两条黄金法则:

  1. 垃圾回收器必须回收所有的垃圾。
  2. 垃圾回收器必须从不回收任何活对象。

        但这两条规则并不是对等的;如果违反了第二条规则,结果会使数据遭到破坏。

        另一方面,如果违反了第一条规则,则会是另一种情况,系统并不总是能够回收所有的垃圾,但最终会回收所有的垃圾,那么这是可以接受的,而实际上,这是垃圾回收器的基本原理。

        HotSpot

        现在,我们来说下 HotSpot,它实际上是一个C、C++以及许多特定于平台的汇编程序组成的混合体。

        当人们想到解释器,就会想到一个很大的 while 循环,其中包含一个很长的 switch 语句。但 HotSpot 解释器比那个要复杂的多(由于性能原因)。在开始阅读 JDK 源代码的时候,就会发现 HotSpot 中实在是有许多汇编程序代码。

        对象创建

        Java 会预先分配大量的连续空间,就是我们所说的“堆”。之后,HotSpot 完全在用户空间里管理这块内存。

        如果一个 Java 进程占用了大量的系统(或内核)时间,那么毫无疑问,它不是在进行垃圾回收——因为所有的垃圾回收内存“簿记(bookkeeping)”都是在用户空间进行的。

        内存池

可视化Java垃圾回收

        图二

        “永久代(PermGen)”是一个存储区域,用于保存那些需要在程序生存期内一直存活的东西,如类的元数据。不过,随着应用程序服务器的出 现,它们有自己的类加载器,并且需要重新加载类的元数据,永久代作为一个优化决策开始显得糟糕,所幸,它在 Java 8 中消失了。

        Java 8 将会使用一个名为“元空间(Metaspace)”的新概念。元空间与永久代并不完全相同。它在堆的外面,由操作系统管理。这意味着,它不会在 Java 堆中,而是在本地内存里。目前,这还不是一个非常好的消息,因为没有多少工具能够让用户轻松地查看本地内存。所以,永久代消失是件好事,但工具赶上这个变 化还需要一些时间。

        Java 堆布局

        现在,我们来看下 Java 堆。注意堆空间之间的虚拟空间。它们提供了一点浮动量,以允许对内存池进行一定量的尺寸调整,又不用为任何对象移动付出代价。

可视化Java垃圾回收

        图三

        “弱代假设(Weak Generational Hypothesis)”

        就现状而言,究竟为什么要将堆分成所有这些内存池?

可视化Java垃圾回收

        图四

        有的运行时事实无法通过静态分析推导出来。上面的插图说明有两组对象:一组存活时间短,一组存活时间长——所以,做额外的簿记以便利用这一事实是有意义的。在 Java 平台中,有许多类似的作为优化写入平台的事实。

        演示

        Ben Evans 进行了一系列的动画演示。第一个演示是个 Flash,说明了对象在 Eden 区和一个新生代 Survivor 空间之间移动,并最终进入老年代的过程。

        图五是用 JavaFX 再现了同样的过程。

可视化Java垃圾回收

        图五

        运行时开关

        ‘强制性’参数

  • -verbose:gc——为用户输出一些 GC 信息
  • -Xloggc:<文件路径>——指定日志输出路径,要确保磁盘有空间
  • -XX:+PringGCDetails——为辅助工具提供“最低限度信息(Minimum information)”

            ——用这个参数代替-verbose:gc

  • --XX:PrintTenuringDistribution——“过早提升(Premature promotion)”信息

        基本堆大小参数

  • -Xms —— 设置预留给堆的最小内存值
  • -Xmx —— 设置预留给堆的最大内存值
  • -XX:MaxPermSize=——设置永久代的最大内存值

            ——有利于 Spring 应用程序和应用服务器

        以前,我们被教导要把-Xms 和-Xmx 的值设的一样大。不过这已经变了。因此,现在可以为-Xms 设置一个合理范围内较小的值,或者根本就不设置,因为堆的适应能力现在已经非常好了。

        其它参数

  • -XX:NewRatio=N
  • -XX:NewSize=N
  • -XX:MaxNewSize=N
  • -XX:MaxHeapFreeRatio
  • -XX:MinHeapFreeRatio
  • -XX:SurvivorRatio=N
  • -XX:MaxTenuringThreshold=N

可视化Java垃圾回收

        图六

        为什么要有日志文件

        日志文件的好处是能够用于取证分析,可以使用户免于为了再现问题而不得不再执行一次代码(如果是一个罕见的生产环境错误,那么重现并不容易)。

        另外,它们包含的信息比针对内存的 JMX MXBeans 所能提供的信息更多,且不说轮询 JMX 本身会引入一系列 GC 问题。

        工具

  • HP JMeter(用 Google 查询一下)

            ——免费,非常可靠,但不再提供支持/功能增强

  • GCViewer

            ——免费,开源,但界面有点丑

  • GarbageCat

            ——名字最好听

  • IBM GCMV

            ——支持 J9

  • jClarity Censum

            ——界面最美观,而且最有用——不过,这是我们的偏见!

        小结

  • 需要了解一些 GC 基础理论
  • 要让新生代的大部分对象在年轻时死亡
  • 打开 GC 日志!——原始日志文件难以阅读——使用工具
  • 使用工具来帮助自己调优——测量,而不是猜测

        查看完整演讲视频,请点击这里

        关于作者

可视化Java垃圾回收

        Ben Evans 是一家 Java/JVM 性能分析创业公司 jClarity 的 CEO。在业余时间,他是伦敦 Java 社区的一名负责人,也是 Java 社区过程执行委员会成员之一。他先前的项目包括:对 Google IPO、金融交易系统做性能测试,为若干 90 年代最大的电影开发获奖网站等等。

来自: InfoQ