`
deepinmind
  • 浏览: 451560 次
  • 性别: Icon_minigender_1
  • 来自: 北京
博客专栏
1dc14e59-7bdf-33ab-841a-02d087aed982
Java函数式编程
浏览量:41631
社区版块
存档分类
最新评论

Java的Finalizer引发的内存溢出

阅读更多
本文介绍的是Java里一个内建的概念,Finalizer。你可能对它如数家珍,但也可能从未听闻过,这得看你有没有花时间完整地看过一遍java.lang.Object类了。在java.lang.Object里面就有一个finalize()的方法。这个方法的实现是空的,不过一旦实现了这个方法,就会触发JVM的内部行为,威力和危险并存。

如果JVM发现某个类实现了finalize()方法的话,那么见证奇迹的时刻到了。我们先来创建一个实现了这个非凡的finalize()方法的类,然后看下这种情况下JVM的处理会有什么不同。我们先从一个简单的示例程序开始:

import java.util.concurrent.atomic.AtomicInteger;

class Finalizable {
      static AtomicInteger aliveCount = new AtomicInteger(0);

      Finalizable() {
            aliveCount.incrementAndGet();
     }

     @Override
     protected void finalize() throws Throwable {
                  Finalizable.aliveCount.decrementAndGet();
     }

      public static void main(String args[]) {
            for (int i = 0;; i++) {
                  Finalizable f = new Finalizable();
                  if ((i % 100_000) == 0) {
                        System.out.format("After creating %d objects, %d are still alive.%n", new Object[] {i, Finalizable.aliveCount.get() });
                    }
          }
     }
}



这个程序使用了一个无限循环来创建对象。它同时还用了一个静态变量aliveCount来跟踪一共创建了多少个实例。每创建了一个新对象,计数器会加1,一旦GC完成后调用了finalize()方法,计数器会跟着减1。

你觉得这小段代码的输出结果会是怎样的呢?由于新创建的对象很快就没人引用了,它们马上就可以被GC回收掉。因此你可能会认为这段程序可以不停的运行下去,:


After creating 345,000,000 objects, 0 are still alive.
After creating 345,100,000 objects, 0 are still alive.
After creating 345,200,000 objects, 0 are still alive.
After creating 345,300,000 objects, 0 are still alive.



显然结果并非如此。现实的结果完全不同,在我的Mac OS X的JDK 1.7.0_51上,程序大概在创建了120万个对象后就抛出java.lang.OutOfMemoryError: GC overhead limitt exceeded异常退出了。


After creating 900,000 objects, 791,361 are still alive.
After creating 1,000,000 objects, 875,624 are still alive.
After creating 1,100,000 objects, 959,024 are still alive.
After creating 1,200,000 objects, 1,040,909 are still alive.
Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded
at java.lang.ref.Finalizer.register(Finalizer.java:90)
at java.lang.Object.(Object.java:37)
at eu.plumbr.demo.Finalizable.(Finalizable.java:8)
at eu.plumbr.demo.Finalizable.main(Finalizable.java:19)


垃圾回收的行为

想弄清楚到底发生了什么,你得看下这段程序在运行时的状况如何。我们来打开-XX:+PrintGCDetails选项再运行一次看看:


[GC [PSYoungGen: 16896K->2544K(19456K)] 16896K->16832K(62976K), 0.0857640 secs] [Times: user=0.22 sys=0.02, real=0.09 secs]
[GC [PSYoungGen: 19440K->2560K(19456K)] 33728K->31392K(62976K), 0.0489700 secs] [Times: user=0.14 sys=0.01, real=0.05 secs]
[GC-- [PSYoungGen: 19456K->19456K(19456K)] 48288K->62976K(62976K), 0.0601190 secs] [Times: user=0.16 sys=0.01, real=0.06 secs]
[Full GC [PSYoungGen: 16896K->14845K(19456K)] [ParOldGen: 43182K->43363K(43520K)] 60078K->58209K(62976K) [PSPermGen: 2567K->2567K(21504K)], 0.4954480 secs] [Times: user=1.76 sys=0.01, real=0.50 secs]
[Full GC [PSYoungGen: 16896K->16820K(19456K)] [ParOldGen: 43361K->43361K(43520K)] 60257K->60181K(62976K) [PSPermGen: 2567K->2567K(21504K)], 0.1379550 secs] [Times: user=0.47 sys=0.01, real=0.14 secs]
--- cut for brevity---
[Full GC [PSYoungGen: 16896K->16893K(19456K)] [ParOldGen: 43351K->43351K(43520K)] 60247K->60244K(62976K) [PSPermGen: 2567K->2567K(21504K)], 0.1231240 secs] [Times: user=0.45 sys=0.00, real=0.13 secs]
[Full GCException in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded
 [PSYoungGen: 16896K->16866K(19456K)] [ParOldGen: 43351K->43351K(43520K)] 60247K->60218K(62976K) [PSPermGen: 2591K->2591K(21504K)], 0.1301790 secs] [Times: user=0.44 sys=0.00, real=0.13 secs]
at eu.plumbr.demo.Finalizable.main(Finalizable.java:19)



从日志中可以看到,少数几次的Eden区的新生代GC过后,JVM开始采用更昂贵的Full GC来清理老生代和持久代的空间。为什么会这样?既然已经没有人引用这些对象了,为什么它们没有在新生代中被回收掉?代码这么写有什么问题吗?

要弄清楚GC这个行为的原因,我们先来对代码做一个小的改动,将finalize()方法的实现先去掉。现在JVM发现这个类没有实现finalize()方法了,于是它切换回了”正常”的模式。再看一眼GC的日志,你只能看到一些廉价的新生代GC在不停的运行。



因为修改后的这段程序中,的确没有人引用到了新生代的这些刚创建的对象。因此Eden区很快就被清空掉了,整个程序可以一直的执行下去。

另一方面,在早先的那个例子中情况则有些不同。这些对象并非没人引用 ,JVM会为每一个Finalizable对象创建一个看门狗(watchdog)。这是Finalizer类的一个实例。而所有的这些看门狗又会为Finalizer类所引用。由于存在这么一个引用链,因此整个的这些对象都是存活的。

那现在Eden区已经满了,而所有对象又都存在引用,GC没辙了只能把它们全拷贝到Suvivor区。更糟糕的是,一旦连Survivor区也满了,只能存到老生代里面了。你应该还记得,Eden区使用的是一种”抛弃一切”的清理策略,而老生代的GC则完全不同,它采用的是一种开销更大的方式。

Finalizer队列

只有在GC完成后,JVM才会意识到除了Finalizer对象已经没有人引用到我们创建的这些实例了,因此它才会把指向这些对象的Finalizer对象标记成可处理的。GC内部会把这些Finalizer对象放到java.lang.ref.Finalizer.ReferenceQueue这个特殊的队列里面。

完成了这些麻烦事之后,我们的应用程序才能继续往下走。这里有个线程你一定会很感兴趣——Finalizer守护线程。通过使用jstack进行thread dump可以看到这个线程的信息。

My Precious:~ demo$ jps
1703 Jps
1702 Finalizable
My Precious:~ demo$ jstack 1702

--- cut for brevity ---
"Finalizer" daemon prio=5 tid=0x00007fe33b029000 nid=0x3103 runnable [0x0000000111fd4000]
   java.lang.Thread.State: RUNNABLE
at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)
at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:101)
at java.lang.ref.Finalizer.access$100(Finalizer.java:32)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:190)
--- cut for brevity —



从上面可以看到有一个Finalizer守护线程正在运行。Finalizer线程是个单一职责的线程。这个线程会不停的循环等待java.lang.ref.Finalizer.ReferenceQueue中的新增对象。一旦Finalizer线程发现队列中出现了新的对象,它会弹出该对象,调用它的finalize()方法,将该引用从Finalizer类中移除,因此下次GC再执行的时候,这个Finalizer实例以及它引用的那个对象就可以回垃圾回收掉了。

现在我们有两个线程都在不停地循环。我们的主线程在忙着创建新对象。这些对象都有各自的看门狗也就是Finalizer,而这个Finalizer对象会被添加到一个java.lang.ref.Finalizer.ReferenceQueue中。Finalizer线程会负责处理这个队列,它将所有的对象弹出,然后调用它们的finalize()方法。

很多时候你可能磁不到内存溢出这种情况。finalize()方法的调用会比你创建新对象要早得多。因此大多数时候,Finalizer线程能够赶在下次GC带来更多的Finalizer对象前清空这个队列。但我们这个例子当中,显然不是这样。

为什么会出现溢出?因为Finalizer线程和主线程相比它的优先级要低。这意味着分配给它的CPU时间更少,因此它的处理速度没法赶上新对象创建的速度。这就是问题的根源——对象创建的速度要比Finalizer线程调用finalize()结束它们的速度要快,这导致最后堆中所有可用的空间都被耗尽了。结果就是——我们亲爱的小伙伴java.lang.OutOfMemoryError会以不同的身份出现在你面前。

如果你仍然不相信我的话,dump一下堆内存,看下它里面有什么。比如说,你可以使用-XX:+HeapDumpOnOutOfMemoryError参数启动我们这个小程序,在我的Eclipse中的MAT Dominator Tree中我看到的是下面这张图:

<img src="https://plumbr.eu/wp-content/uploads/2014/04/Dominator-tree-java-finalizer.png"/>

看到了吧,我这个64M的堆全给Finalizer对象给占满了。

结论

回顾一下,Finalizable对象的生命周期和普通对象的行为是完全不同的,列举如下:

- JVM创建Finalizable对象
- JVM创建 java.lang.ref.Finalizer实例,指向刚创建的对象。
-  java.lang.ref.Finalizer类持有新创建的java.lang.ref.Finalizer的实例。这使得下一次新生代GC无法回收这些对象。
- 新生代GC无法清空Eden区,因此会将这些对象移到Survivor区或者老生代。
- 垃圾回收器发现这些对象实现了finalize()方法。因为会把它们添加到java.lang.ref.Finalizer.ReferenceQueue队列中。
- Finalizer线程会处理这个队列,将里面的对象逐个弹出,并调用它们的finalize()方法。
- finalize()方法调用完后,Finalizer线程会将引用从Finalizer类中去掉,因此在下一轮GC中,这些对象就可以被回收了。
- Finalizer线程会和我们的主线程进行竞争,不过由于它的优先级较低,获取到的CPU时间较少,因此它永远也赶不上主线程的步伐。
- 程序消耗了所有的可用资源,最后抛出OutOfMemoryError异常。


这篇文章想告诉我们什么?下回如果你考虑使用finalize()方法,而不是使用常规的方式来清理对象的话,最好多想一下。你可能会为使用了finalize()方法写出的整洁的代码而沾沾自喜,但是不停增长的Finalizer队列也许会撑爆你的年老代,你需要重新再考虑一下你的方案。

原创文章转载请注明出处:http://it.deepinmind.com
英文原文链接
8
1
分享到:
评论
5 楼 asticx 2014-05-16  
4 楼 SMCwwh 2014-05-15  
百度“马进 finalize”
3 楼 zhanghq0717 2014-05-13  
看到一半快看不下去了。。。。不怎么接触这些东西。。学习新的东西总是需要费脑子的啊
2 楼 deepinmind 2014-05-13  
white_crucifix 写道
译帝的译文内容总是有很高的质量


惭愧啊。。。最近文章越来越难找了,快坚持不下去了。。
1 楼 white_crucifix 2014-05-13  
译帝的译文内容总是有很高的质量

相关推荐

    java使用JMAP定位代码内存泄漏在哪

    内存泄漏是导致程序性能下降,甚至引发Out of Memory (OOM)错误的主要原因之一。本文将详细介绍如何使用JMAP工具来定位Java代码中的内存泄漏问题。 首先,理解内存泄漏的概念:内存泄漏是指程序在申请内存后,无法...

    Java内存泄漏排除工具mat

    Java内存泄漏是开发过程中常见的问题,可能导致系统性能下降,甚至应用程序崩溃。为了有效地排查和解决这类问题,开发者通常会借助专业工具,而“Java内存泄漏排除工具MAT”(Memory Analyzer Tool)就是一个强大的...

    如何排查Java内存泄漏?看完我给跪了!

    Java内存管理是一个复杂而微妙的主题,尤其是当涉及到内存泄漏时。Java的自动垃圾回收机制虽然在大多数情况下工作得很好,但并不能完全防止内存泄漏的发生。内存泄漏通常发生在程序中,当不再需要的对象仍然被引用,...

    JAVA核心知识点整理学习.pdf

    Java是一种广泛使用的高级编程语言,它的核心知识点涵盖了Java编程语言的基础知识、Java虚拟机(JVM)的工作机制、Java的内存管理机制等方面。下面是对Java核心知识点的整理和学习。 目录 Java的目录结构是Java...

    java虚拟机.docx

    2. **内存管理**:Java提供了一种相对安全的内存管理和访问机制,能够有效避免内存泄露和指针越界等问题。 3. **性能优化**:JVM通过热点代码检测、即时编译(JIT)和运行时优化技术提高Java应用程序的执行效率。 ###...

    使用jmap分析Java程序性能问题

    这些问题包括但不限于内存泄漏、频繁的垃圾回收、内存溢出等,它们不仅影响程序的稳定运行,还可能导致服务中断。为了解决这类问题,Java提供了多种工具来辅助开发者进行诊断和调试,其中jmap就是一种非常实用且强大...

    JAVA白皮书(英文版)

    - **内存管理**:介绍Java如何管理内存以防止非法访问和溢出等问题。 ##### 6.2 类加载器中的安全检查 - **类加载器安全检查**:解释类加载器如何在加载类时执行安全检查。 ##### 6.3 字节码验证过程 - **字节码...

    内存管理,GC机制,内存释放过程

    4. 如果不在Finalizer2表上有记录,那么释放内存。 Finalizer的概念: 在.NET中,Destructor的概念已经不存在了,它变成了Finalizer。Finalizer是一个特殊的方法,它会在对象被回收前执行。在Finalizer中,我们...

    java虚拟机常用命令

    jconsole和jvisualvm是Java提供的图形化监控工具,可以监控虚拟机的运行状态、内存使用、线程运行情况等。它们为非命令行用户提供了直观的操作界面,可以方便地进行各种监控和诊断操作。 以上这些JVM命令工具是Java...

    java的一本好教材

    31. **垃圾回收机制(Garbage collection)**:Java的垃圾回收机制自动回收不再使用的内存,以避免内存泄漏。 32. **监控区域(Guarded region)**:在多线程编程中,监控区域是可能抛出异常或需要同步控制的代码段...

    实战JAVA虚拟机 JVM故障诊断与性能优化带源码

    1. **堆内存溢出**:当对象分配过多导致堆内存耗尽时,会出现OOM(Out of Memory)错误。诊断此类问题通常需要分析堆转储(Heap Dump)文件,识别哪些对象占用了大量内存。 2. **栈溢出**:线程栈大小有限,当递归过...

    java虚拟机垃圾回收详解.docx

    Java虚拟机(JVM)的垃圾回收(Garbage Collection, GC)是Java编程中的关键概念,它自动管理程序中的内存,避免程序员手动处理内存释放,从而减少内存泄露和程序崩溃的风险。垃圾回收机制的主要目标是识别并回收...

    第29讲Java内存模型中的happen-before1

    为了解决这些问题,Java 内存模型(JMM)应运而生,它提供了一种抽象的内存访问规则,确保了多线程环境下的正确性和可预测性。 Java 内存模型的主要目标是解决以下几个关键问题: 1. **可见性**:线程之间共享变量...

    对Java的思考(Thinking in Java) Java入门 java与C++对比 深入浅出

    讲解了如何通过句柄操纵对象,对象的创建和内存管理,特别是Java中特殊的主类型和数组。作者指出,Java不支持显式的对象清除,而是依赖于垃圾收集机制。此外,本章还介绍了类的定义,包括字段和方法,以及构建Java...

    Troubleshooting Memory Problems-Poonam Parhar.pdf

    Java应用程序中的内存问题故障排除 Java应用程序中的内存问题故障排除是Java开发人员和系统管理员需要掌握的重要技能。 Oracle公司的技术专家Poonam Parhar在她的技术文档中分享了Java应用程序中的内存问题故障排除...

    Java性能优化的45个细节

    23. **理解并利用Java内存模型(JMM)**:确保多线程环境下数据的一致性。 24. **避免在循环中创建对象**:提前创建并在循环外复用,减少垃圾收集的负担。 25. **使用流API(Stream)**:Java 8的流API能提供更...

Global site tag (gtag.js) - Google Analytics