热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

java内存泄漏的故障排除:终结?-Troubleshootingajavamemoryleak:finalization?

Ihaveamisbehavingapplicationthatseemstoleak.Afterabriefprofilerinvestigation,mostmemo

I have a misbehaving application that seems to leak. After a brief profiler investigation, most memory (80%) is held by java.lang.ref.Finalizer instances. I suspect that finalizers fail to run.

我有一个行为不当的应用程序,似乎泄露了。经过简短的分析器调查,大多数内存(80%)由java.lang.ref保存。终结器实例。我怀疑终结器不能运行。

A common cause of this seems to be exceptions thrown from the finalizer. However, the javadoc for the finalize method of the Object class (see here for instance) seems to contradict itself: it states

一个常见的原因似乎是终结器抛出的异常。但是,对象类的finalize方法的javadoc(例如在这里看到)似乎自相矛盾:它声明

If an uncaught exception is thrown by the finalize method, the exception is ignored and finalization of that object terminates.

如果finalize方法抛出未捕获的异常,则会忽略该异常,该对象的终结。

but later, it also states that

但后来,它也指出了这一点

Any exception thrown by the finalize method causes the finalization of this object to be halted, but is otherwise ignored.

finalize方法抛出的任何异常都会导致该对象的终结,但在其他情况下会被忽略。

What should I believe (i.e., is finalization halted or not?), and do you have any tips on how to investigate such apparent leaks?

我应该相信什么?你对如何调查这些明显的泄漏有什么建议吗?

Thanks

谢谢

5 个解决方案

#1


6  

My first step would be to establish whether this is a genuine memory leak or not.

我的第一步是确定这是否是一个真正的内存泄漏。

The points raised in the previous answers all relate to the speed at which objects are collected, not the question of whether your objects are collected at all. Only the latter is a genuine memory leak.

在前面的回答中提出的要点都与收集对象的速度有关,而不是您的对象是否被收集的问题。只有后者才是真正的内存泄漏。

We had a similar predicament on my project, and ran the application in "slow motion" mode to figure out if we had a real leak. We were able to do this by slowing down the stream of input data.

在我的项目中,我们遇到了类似的困境,并以“慢动作”模式运行应用程序,以确定是否出现了真正的泄漏。我们可以通过减慢输入数据流来实现这一点。

If the problem disappears when you run in "slow motion" mode, then the problem is probably one of the ones suggested in the previous answers, i.e. the Finalizer thread can't process the finalizer queue fast enough.

如果在运行“慢动作”模式时,问题消失了,那么问题可能是在前面的答案中提出的问题之一,即终结器线程不能足够快地处理终结器队列。

If that is the problem, it sounds like you might need to do some non-trivial refactoring as described in the page Bringer128 linked to, e.g.

如果这是问题所在,听起来您可能需要做一些重要的重构,如在链接到的页面Bringer128中所描述的。

Now let's look at how to write classes that require postmortem cleanup so that their users do not encounter the problems previously outlined. The best way to do so is to split such classes into two -- one to hold the data that need postmortem cleanup, the other to hold everything else -- and define a finalizer only on the former

现在让我们看看如何编写需要进行死后清理的类,以便他们的用户不会遇到前面提到的问题。最好的方法是将此类类分为两类——一个用于保存需要事后清理的数据,另一个用于保存其他所有内容——并仅在前者上定义终结器

#2


9  

Both quotes say:

这两个报价说:

An exception will cause finalization of this object to be halted/terminated.

一个异常将导致这个对象的终结被停止/终止。

Both quotes also say:

两个报价也说:

The uncaught exception is ignored (i.e. not logged or handled by the VM in any way)

未被捕获的异常被忽略(例如,没有被记录或被VM以任何方式处理)

So that answers the first half of your question. I don't know enough about Finalizers to give you advice on tracking down your memory leak though.

这就回答了你问题的前半部分。我对Finalizers的了解还不够多,我想给你一些关于追踪内存泄漏的建议。

EDIT: I found this page which might be of use. It has advice such as setting fields to null manually in finalizers to allow the GC to reclaim them.

编辑:我找到了这个可能有用的页面。它提供了一些建议,比如在终结器中手动将字段设置为null,以允许GC回收它们。

EDIT2: Some more interesting links and quotes:

更多有趣的链接和引用:

From Anatomy of a Java Finalizer

从Java终结器的剖析

Finalizer threads are not given maximum priorities on systems. If a "Finalizer" thread cannot keep up with the rate at which higher priority threads cause finalizable objects to be queued, the finalizer queue will keep growing and cause the Java heap to fill up. Eventually the Java heap will get exhausted and a java.lang.OutOfMemoryError will be thrown.

终结器线程在系统上没有获得最大优先级。如果“终结器”线程无法跟上高优先级线程导致可终结对象排队的速度,那么终结器队列将继续增长,并导致Java堆填满。最终,Java堆将被耗尽,并使用Java .lang。就会抛出OutOfMemoryError。

and also

it's not guaranteed that any objects that have a finalize() method are garbage collected.

不能保证任何具有finalize()方法的对象都是垃圾收集的。

EDIT3: Upon reading more of the Anatomy link, it appears that throwing exceptions in the Finalizer thread really slows it down, almost as much as calling Thread.yield(). You appear to be right that the Finalizer thread will eventually flag the object as able to be GC'd even if an exception is thrown. However, since the slowdown is significant it is possible that in your case the Finalizer thread is not keeping up with the object-creation-and-falling-out-of-scope rate.

EDIT3:在阅读了更多的解剖学链接之后,似乎在终结器线程中抛出异常会降低它的速度,几乎与调用thread .yield()一样慢。即使抛出异常,终结器线程最终也将标记对象为GC,这似乎是正确的。但是,由于放缓是显著的,所以在您的示例中终结器线程可能没有跟上对象创建和超出范围的速度。

#3


3  

The item 7 of Effective Java second edition is: "Avoid finalizers". I strongly recommend you to read it. Here is an extract that may help you:

有效的Java第二版的第7项是:“避免终结器”。我强烈建议你读一读。这里有一个可以帮助你的摘录:

"Explicit termination methods are typically used in combination with try-finally construct to ensure termination"

“显式终止方法通常与try-finally结构结合使用,以确保终止”

#4


0  

I have same issue with you (below picture). For our case, it because an object has wait(0) in its finalize and it never get notified, which block the java.lang.ref.Finalizer$FinalizerThread. More reference

我和你有同样的问题(下图)。对于我们的例子来说,因为对象在其finalize中等待(0),而它永远不会得到通知,从而阻塞了java.lang.ref.Finalizer$FinalizerThread。更多的参考

  • The Secret Life Of The Finalizer
  • 终结者的秘密生活
  • java/lang/ref/Finalizer.java
  • java / lang / ref / Finalizer.java

objects retained by Finalizer

#5


0  

i have once see a similar problem, that is the finalizer thread can not catch up with the rate of generating finalizable objects.

我曾经遇到过一个类似的问题,那就是终结器线程无法赶上生成可终结对象的速度。

my solution is the make a closed loop control, by use the MemoryMXBean .getObjectPendingFinalizationCount(), a PD( proportinal and diffrential) control algo to control the speed we generate the finalizable objects, since we have a single entry to create it, just sleep number of seconds with the result of pd algo. it works well, though you need to tune the paramter for pd algo.

我的解决方案是使用MemoryMXBean . getobjectpendingfinalizationcount(),一个PD(proportinal和diffrential)控件algo,通过它来控制生成可终结对象的速度,因为我们只有一个条目来创建它,使用PD algo的结果只需要睡眠数秒。它工作得很好,尽管你需要为pd algo调整参数。

hope it helps.

希望它可以帮助。


推荐阅读
  • 2019年后蚂蚁集团与拼多多面试经验详述与深度剖析
    2019年后蚂蚁集团与拼多多面试经验详述与深度剖析 ... [详细]
  • MongoDB Aggregates.group() 方法详解与编程实例 ... [详细]
  • 本文提供了 RabbitMQ 3.7 的快速上手指南,详细介绍了环境搭建、生产者和消费者的配置与使用。通过官方教程的指引,读者可以轻松完成初步测试和实践,快速掌握 RabbitMQ 的核心功能和基本操作。 ... [详细]
  • 深入解析十大经典排序算法:动画演示、原理分析与代码实现
    本文深入探讨了十种经典的排序算法,不仅通过动画直观展示了每种算法的运行过程,还详细解析了其背后的原理与机制,并提供了相应的代码实现,帮助读者全面理解和掌握这些算法的核心要点。 ... [详细]
  • 开发心得:深入探讨Servlet、Dubbo与MyBatis中的责任链模式应用
    开发心得:深入探讨Servlet、Dubbo与MyBatis中的责任链模式应用 ... [详细]
  • Java 中优先级队列的轮询方法详解与应用 ... [详细]
  • 本文作为“实现简易版Spring系列”的第五篇,继前文深入探讨了Spring框架的核心技术之一——控制反转(IoC)之后,将重点转向另一个关键技术——面向切面编程(AOP)。对于使用Spring框架进行开发的开发者来说,AOP是一个不可或缺的概念。了解AOP的背景及其基本原理,对于掌握这一技术至关重要。本文将通过具体示例,详细解析AOP的实现机制,帮助读者更好地理解和应用这一技术。 ... [详细]
  • Java 9 中 SafeVarargs 注释的使用与示例解析 ... [详细]
  • 深入解析零拷贝技术(Zerocopy)及其应用优势
    零拷贝技术(Zero-copy)是Netty框架中的一个关键特性,其核心在于减少数据在操作系统内核与用户空间之间的传输次数。通过避免不必要的内存复制操作,零拷贝显著提高了数据传输的效率和性能。本文将深入探讨零拷贝的工作原理及其在实际应用中的优势,包括降低CPU负载、减少内存带宽消耗以及提高系统吞吐量等方面。 ... [详细]
  • Java 8 引入了 Stream API,这一新特性极大地增强了集合数据的处理能力。通过 Stream API,开发者可以更加高效、简洁地进行集合数据的遍历、过滤和转换操作。本文将详细解析 Stream API 的核心概念和常见用法,帮助读者更好地理解和应用这一强大的工具。 ... [详细]
  • 在软件开发领域,“池”技术被广泛应用,如数据库连接池、线程池等。本文重点探讨Java中的线程池ThreadPoolExecutor,通过详细解析其内部机制,帮助开发者理解如何高效利用线程池管理任务执行。线程池不仅能够显著减少系统资源的消耗,提高响应速度,还能通过合理的配置,如饱和策略,确保在高负载情况下系统的稳定性和可靠性。文章还将结合实际案例,展示线程池在不同应用场景下的具体实现与优化技巧。 ... [详细]
  • Android ListView 自定义 CheckBox 实现列表项多选功能详解
    本文详细介绍了在Android开发中如何在ListView的每一行添加CheckBox,以实现列表项的多选功能。用户不仅可以通过点击复选框来选择项目,还可以通过点击列表的任意一行来完成选中操作,提升了用户体验和操作便捷性。同时,文章还探讨了相关的事件处理机制和布局优化技巧,帮助开发者更好地实现这一功能。 ... [详细]
  • 本文深入剖析了ScheduledThreadPoolExecutor的并发执行机制及其源代码,详细解读了该线程池如何在指定延时或定期执行任务,探讨了其内部的工作原理和优化策略,为开发者提供了宝贵的参考和实践指导。 ... [详细]
  • 本课程详细解析了Spring AOP的核心概念及其增强机制,涵盖前置增强、后置增强和环绕增强等类型。通过具体示例,深入探讨了如何在实际开发中有效运用这些增强技术,以提升代码的模块化和可维护性。此外,还介绍了Spring AOP在异常处理和性能监控等场景中的应用,帮助开发者更好地理解和掌握这一强大工具。 ... [详细]
  • 在启用分层编译的情况下,即时编译器(JIT)的触发条件涉及多个因素,包括方法调用频率、代码复杂度和运行时性能数据。本文将详细解析这些条件,并探讨分层编译如何优化JVM的执行效率。 ... [详细]
author-avatar
蓬从蓉Tahirah
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有