Using Jconsole for Memory Leak

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.

---

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.

Blocked count is the total number of times that the thread blocked to enter or reenter a monitor. I.e. the number of times a thread has been in the java.lang.Thread.State.BLOCKED state.

Waited count is the total number of times that the thread waited for notification. i.e. the number of times that a thread has been in the java.lang.Thread.State.WAITING or java.lang.Thread.State.TIMED_WAITING state.

---

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

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

---

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.

---

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?