java.exe进程使用更多内存而不释放它

Question

I have a java application which when in idle state before any complex executions, uses 23 MB in Heap and the java.exe process size in TaskManager was around 194 MB. After some complex operations, the size of java.exe grew up to around 500MB and the heap size also grew up. The Heap size is reduced back to 23MB after a few full GC by calling System.gc() method. But the size of java.exe reduced to around 237MB from around 600MB which still have around 43 MB of data in it. Is there a way to reduce this? Or is that due to some behavior?

Answer 1

This is normal, don't worry. JVM acquires memory when it needs to execute some complex logic. When java is done processing the tasks the JVM will still keep that memory as a reserved space and is not released back to the OS. This architecture helps in performance because JMV does not have to request the same memory again from the underlying OS. It will still be within the range you define in -Xmx JVM parameter.

See this IBM link for some interesting details. http://www-01.ibm.com/support/docview.wss?uid=swg21326774

Unfortunately this is one of the grey areas of JVM; you really don't have much of a control on how OS and JVM share memory between each other. Think of JVM as a Virtual OS that requires some memory to run. Both your parent OS and the VM are hungry for resources and want to hang on to the acquired resources the as much memory as possible. Requesting for more memory from OS is a time consuming operation so most of the JVMs do not release the memory back to the OS even when they don't need it anymore.

See this white paper from Oracle for more details on internal JVM memory management. http://www.oracle.com/technetwork/java/javase/memorymanagement-whitepaper-150215.pdf

I would suggest you to read the IBM link first and then you can delve into the weird world of memory explained in the white paper. Both of these links are very informative and interesting.

Answer 2

OS footprint of java process are composed from

• java heap (it's size in limited by -Xmx )
• java classes related metadata (or permanent generation in HotSpot JVM)
• non-heap memory accessible via NIO
• stack space for java threads

Some garbage collection algorithms are returning free memory back to OS, other do not. In HotSpot JVM, serial old space collector (usually enabled by default) are returning memory back to OS (so you can see shrinking of process). Though, other collector such as -XX:+UseParallelOldGC or -XX:+UseConcMarkSweepGC will never return unused heap memory to OS.

HotSpot JVM has options to manage / limit all memory areas mentioned above, you can find comprehensive list of JVM options related to memory sizing and GC tuning in my blog .