In a java heap dump how do I know exactly where in the code/which thread caused the dump?
-
The causes are anything which is using memory (which is a lot) What you are looking for is objects which are using more memory than you think they should. I use YourKit to trace allocation so I can see which code is creating the most data (or the data I am concerned about) – Peter Lawrey Aug 03 '12 at 08:03
-
If the application is behaving correctly, the cause could be that the maximum heap size is too low. – Peter Lawrey Aug 03 '12 at 08:04
3 Answers
For reading the memory dumps:
I would recommend you to try "eclipse memory analyzer" From here
Another option (free) would be opening this with JVisualVM (available at $JAVA_HOME/bin) jhat is cool too but was already recommended :)
Now, you're asking about the thread that caused memory heap-dump and not about how to proceed with memory dump... It depends on how did you obtain the memory dump. There are different ways to obtain the dump.
On your process you can instruct the JVM to produce memory dump once OutOfMemory error is encountered, in this case I believe it will be the JVM itself.
You can trigger the heap dump creation from the MBean given you have a JMX Server running along with your JVM Example
You can even use system calls (on linux) externally to your application:
kill -3 _YOUR_JAVA_PROCESS_ID_
will generation the heapdump.
But I hardly can imagine why would you need such an information. Later in comments you mention 'exact line of code' but these ways are usually external to your JVM... Are you sure you need a line of code that generated heap dump itself, or you're trying to identify the real issue?
Hope this helps

- 1
- 1

- 39,963
- 4
- 57
- 97
-
I am asking the following:Having a heap dump, how do I find in it the exact line in code and thread that caused the error and therefore made JVM produce the dump? – Jim Aug 03 '12 at 07:16
-
Ah, I see. So you have an error, usually , its OutOfMemory, right? In this case its just a heap dump analysis. If you use the MAT, the chances that it will identify possible bottelenecks/suspious code for you. Usually it boils down to a memory leak, but there is no silver-bullet solution. Its different for each system. Try to see how many objects of each type do you have, maybe something will look 'weird' and you'll get a clue how to proceed... – Mark Bramnik Aug 03 '12 at 07:20
In java you create object some where, use it in many places and the let GC to collect it back. There is no single line causing a leak.
What you should look for in tools like MAP is objects count and heap used by them. Pick each of the target class and see why they are not garbage collected. (some one is holding reference more than needed- say a static field )
You may find instructions from this page more useful - http://scn.sap.com/people/krum.tsvetkov/blog/2007/07/02/finding-memory-leaks-with-sap-memory-analyzer (also linked from MAT homepage)

- 18,003
- 15
- 89
- 143
Try to use Java Heap Analysis Tool(jhat) or jconsole (that is in your JAVA_HOME\bin).

- 6,622
- 12
- 47
- 65