使用 Jconsole 处理内存泄漏答案

【问题标题】：Using Jconsole for Memory Leak使用 Jconsole 处理内存泄漏
【发布时间】：2010-11-15 06:07:00
【问题描述】：

我正在尝试诊断 J2EE 服务器中的一些内存问题。我已经在我们的实时服务器上设置了 jconsole，我正在尝试通过它来监控 tomcat 服务器的状态。我有一个关于 jconsole 中的 Threads 选项卡的快速问题。我可以在线程列表中看到一个名为 Finalizer 的线程。此线程中的“总被阻止”数量不断增加。例如，现在是 4,049，一小时前是 3,867。

Name: Finalizer State: WAITING on java.lang.ref.ReferenceQueue$Lock@1b79cfd Total blocked: 4,049 Total waited: 1,579

这个线程是什么意思？它与GC有某种关系吗？我已经下载了一个堆转储，其中显示等待完成的对象数量为零。

目前我的服务器的最大堆大小为 200MB，堆大小保持在 100 到 150 MB 之间，当我单击“执行 GC”时，我可以看到一些堆空间被释放。但是，这不会改变 Windows 任务管理器中这个 tomcat 进程占用的内存量，目前它消耗了超过 700 MB。

任何关于我应该如何去做的提示将不胜感激。如果您需要有关我的服务器设置的更多信息，请向我提问。

提前致谢。

【问题讨论】：

标签： java spring tomcat memory-leaks jconsole

【解决方案1】：

我想我已经找到了问题的答案。 “总阻塞”和“总等待”只是线程等待或被阻塞的次数。 JConsole 正在从 ThreadInfo 获取此信息。

阻塞计数是线程阻塞进入或重新进入监视器的总次数。 IE。线程处于 java.lang.Thread.State.BLOCKED 状态的次数。

Waited count 是线程等待通知的总次数。即线程处于 java.lang.Thread.State.WAITING 或 java.lang.Thread.State.TIMED_WAITING 状态的次数。

【讨论】：

顺便说一下，在我的测试中，时间是以秒为单位的。

【解决方案2】：

名称：终结器状态：WAITING on java.lang.ref.ReferenceQueue$Lock@1b79cfd 阻止总数：4,049 等待总数： 1,579

ReferenceQueue 正在维护所有未使用对象的引用（等待终结），换句话说，有 4049 个对象在等待垃圾回收。

在寻找内存泄漏时，一定要在进行转储之前进行一次完整的 GC（或多次 GC，直到没有任何东西无法回收）

【讨论】：

【解决方案3】：

windows 任务管理器显示虚拟内存大小，大多数时候不准确。我已经看过很多次了，JConsole 显示的足迹是正确的内存足迹。

有关 JConsole 的更多信息，请查看here。

【讨论】：

感谢您的链接。我以前也看过那个页面。它有一个我正在谈论的 Finalizer 线程的屏幕截图（图 3-8）。但是，它没有详细介绍线程或 Total Blocked、Total Waited 属性。

【解决方案4】：

在我看来像一个死锁： http://download.oracle.com/javase/tutorial/essential/concurrency/deadlock.html

您是否有任何可能无限等待的同步方法？

【讨论】：

好吧，我在 jconsole 中使用了检测死锁功能，但找不到任何东西。它说没有检测到死锁。