We have some memory leak issues on VMs in production which are running Java applications, the Old Gen heap usage grows fast every day, so I want to create heap dump to analyze it.
However, I noticed that VisualVM will perform full GC before heap dump which will clean the Old Gen, in that case, the heap dump would be useless.
I also tried to use the following command:
jmap -dump:live,format=b,file=heap.bin
It will also trigger a full GC.
May I ask if there is a way that heap dump can be created without full GC (or without GC)? Or is there any better way to analyze the memory leak?
JDK version: 1.7.0_45
Thanks.
A dump can be taken on demand (using the jmap JDK utility) or when an app fails with OutOfMemoryError (if the JVM was started with the -XX:+HeapDumpOnOutOfMemoryError command line option). A heap dump is a binary file of about the size of your JVM's heap, so it can only be read and analyzed with special tools.
One of the core benefits of Java is the JVM, which is an out-of-the-box memory management. Essentially, we can create objects and the Java Garbage Collector will take care of allocating and freeing up memory for us. Nevertheless, memory leaks can still occur in Java applications.
A Memory Leak is a situation where there are objects present in the heap that are no longer used, but the garbage collector is unable to remove them from memory, and therefore, they're unnecessarily maintained.
Memory profilers are tools that can monitor memory usage and help detect memory leaks in an application. Profilers can also help with analyzing how resources are allocated within an application, for example how much memory and CPU time is being used by each method.
The answer marked as correct isn't correct anymore. As Sumit says, it will cause a Full GC only when the live option is used (in both histo & dump operations).
Java 7 and Java 8 have this option
-histo[:live]
Prints a histogram of the heap. For each Java class, the number of objects, memory size in bytes, and the fully qualified class names are printed. The JVM internal class names are printed with an asterisk (*) prefix. If the live suboption is specified, then only active objects are counted.
-dump:[live,] format=b, file=filename
Dumps the Java heap in hprof binary format to filename. The live suboption is optional, but when specified, only the active objects in the heap are dumped. To browse the heap dump, you can use the jhat(1) command to read the generated file.
You could aldo use the jcmd command with the operation GC.heap_dump and the option -all
GC.heap_dump Generate a HPROF format dump of the Java heap. Impact: High: Depends on Java heap size and content. Request a full GC unless the '-all' option is specified.
Permission: java.lang.management.ManagementPermission(monitor)
Syntax : GC.heap_dump [options]
Arguments: filename : Name of the dump file (STRING, no default value)
Options: (options must be specified using the or = syntax) -all : [optional] Dump all objects, including unreachable objects (BOOLEAN, false)
Example: jcmd 3181 GC.heap_dump -all dump
You could add the -XX:+PrintGCDetails
flag to see if a Full GC is hapenning.
For example, when I use jcmd without -all I see something like this.
200,658: [Full GC (Heap Dump Initiated GC) 200,658: [CMS: 5040K->4158K(18432K), 0,0171885 secs] 11239K->4158K(25856K), [Metaspace: 18053K->18053K(1064960K)], 0,0173941 secs] [Times: user=0,01 sys=0,00, real=0,02 secs]
You can trigger HeapDump using JMX bean HotSpotDiagnostic and second parameter of method set to false.
See this answer for a more detailed response: https://stackoverflow.com/a/35575793/236528
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With