After consecutive Full GC(Ergonomics), the size of heap didn't change

Question

There are a lot of threads in my program, one of which keeps asking for memory and doesn't release it. As gc log show, I found consecutive Full GC (Ergonomics), but the program did not get more memory, and all threads stopped, except for the JVM garbage collection thread. I read the official documentation, GC Ergonomics tries to grow or shrink the heap to meet a special goal such as minium pause time and/or throughput. However, after Full GC (Ergonomics) , as gc log show, heap The size of the space has not changed, both old and young.

I wander why the size of heap didn't change after Full GC(Ergonomics)

My computer has 16G memory and no swap. No other application run in this computer

JVM Args: -XX:+PrintGCDateStamps -Xloggc:gc.log -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.managementote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Xmx10G -XX:+HeapDumpOnOutOfMemoryError -XX:+PrintGCDetails gc log: gc log

heap usage after gc

Answer 1

There are a couple of things to look at here.

The first is that the way you describe your application appears to be a classic memory leak (even if this is deliberate). If you have a thread that keeps allocating objects that it maintains references to, eventually you will run out of heap space. Looking at the GC log and heap graph that's exactly what is happening. The full GCs are running continuously to try and reclaim space to keep your application going. The collector is not reclaiming any space, which actually makes me surprised that the VM does not stop with an OutOfMemoryError. An OutOfMemoryError will result if the heap is continuously 98% or more full and the GC cannot reclaim more than 2% of space. The GC log shows this to be true.

The next question is why the heap space does not expand above 8Gb. You set the -Xmx option to 10Gb so logically you would expect the heap to grow to that size if required. On a 16Gb machine, there is no reason for this not to happen. I would add the option -Xms to set the initial size to 10Gb as well, which will force the JVM to reserve all that space at launch.

As has been pointed out in the comments, you should profile your application to get a better understanding of which objects you are maintaining references to and if there is some way you can reduce this. With an unbounded dataset, you will always reach a point at which the application will be unable to continue.