使用Jconsole解决内存泄漏
我正在尝试诊断 J2EE 服务器中的一些内存问题。我已经在我们的实时服务器上设置了 jconsole，并且我正在尝试通过它来监视 tomcat 服务器的状态。我有一个关于 jconsole 中“线程”选项卡的快速问题。我可以在线程列表中看到一个名为 Finalizer 的线程。该线程中的“被阻止总数”不断增加。例如，现在是 4,049，一小时前是 3,867。
名称：终结器
状态：等待 java.lang.ref.ReferenceQueue$Lock@1b79cfd
阻塞总数：4,049 等待总数：1,579
这个线程是什么意思？和GC有什么关系吗？我下载了一个堆转储，其中显示等待最终确定的对象数量为零。
目前我的服务器的最大堆大小为 200MB，堆大小保持在 100 到 150 MB 之间，当我单击“执行 GC”时，我可以看到一些堆空间被释放。但是，这不会改变 Windows 任务管理器中该 tomcat 进程占用的内存量，该进程目前消耗超过 700 MB。
任何关于我应该如何去做的建议将不胜感激。如果您需要有关我的服务器设置的更多信息，请向我提问。
提前致谢。
I'm trying to diagnose some memory issues in our J2EE server. I've setup jconsole on our live server and I'm trying to monitor the status of the tomcat server through it. I've a quick question about the Threads tab in jconsole. I can see a thread named Finalizer in the threads list. The 'Total blocked' number in this thread keeps on increasing. For example, it's now 4,049, an hour ago it was 3,867.
Name: Finalizer
State: WAITING on java.lang.ref.ReferenceQueue$Lock@1b79cfd
Total blocked: 4,049 Total waited: 1,579
What does this thread mean? Is it somehow related to the GC? I've downloaded a heap dump where it shows number of objects pending for finalization is zero.
The max heap size of my server is 200MB at the moment, the heap size remains between 100 and 150 MB and when I click on 'Perform GC', I can see some heap space getting freed. However this doesn't change the amount of memory taken by this tomcat process in windows task manager, which is consuming over 700 MB right now.
Any tips on how I should go about it will be much appreciated. Please ask me questions if you need further info on my server setup.
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我想我已经找到了问题的答案。 “总阻塞次数”和“总等待次数”只是线程等待或被阻塞的次数的计数。 JConsole 正在从 ThreadInfo。
I think I've found the answer to my question. The 'Total blocked' and 'Total waited' are simply counts for the number of times the thread waited or was blocked. JConsole is taking this information from ThreadInfo.
ReferenceQueue 正在维护所有未使用对象的引用（等待最终确定），换句话说，有 4049 个对象正在等待垃圾回收。
当寻找内存泄漏时，一定要在转储之前执行完整的 GC（或多次 GC，直到没有任何内容无法回收）
The ReferenceQueue is maintaining a reference for all unused objects (waiting for finalization), in other words there is 4049 objects waiting for a garbage collection.
When hunting for memory leaks, be sure to do a full GC (or many GC until nothing can't be reclaimed) before doing the dump
Windows 任务管理器显示虚拟内存大小，但大多数情况下并不准确。我已经看过很多次了，JConsole 显示的占用空间是正确的内存占用空间。
有关 JConsole 的更多信息，请查看此处。
The windows task manager shows the virtual memory size and is most of the time not accurate. I have seen this a lot of time, what JConsole shows as the footprint is the right memory footprint.
For more information regarding JConsole check here.
对我来说似乎是一个僵局：
http://download.oracle.com/javase/tutorial/essential/concurrency /deadlock.html
您是否有任何可能无限等待的同步方法？
Looks like a Deadlock to me:
http://download.oracle.com/javase/tutorial/essential/concurrency/deadlock.html
Do you have any synchronized methods that might be waiting infinitely?