JVM Process vs JVM Heap memory usage_问答_开发者

I have read through this Process Memory Vs Heap -- JVM and i have the same problem.

The jvm process memory usage keeps increasing and never shrinks.I checked by doing a top on the linux server. The application is scheduling jobs to a cluster ( Using Quartz + Sun Java DRMAA API )

The java heap space is staying within the limits during the application life cycle but the jvm process is showing a steady climb in memory usage and never coming down.

Is this a memory leak ? If so , why is heap space being within the limits. Can someone explain this.

UPDATE: I have -Xmx1600m -Xms1600m when i track through jconsole i can see the heap space well within this li开发者_如何转开发mit aroung 450m but the top command shows the process is using more than 900m.

The total virtual memory used is the sum of the maximum heap + thread stacks + direct memory + perm gen + share libraries. This never shrinks.

The actual main memory used depends on how much of the virtual memory has been occupied. Shared libraries are shared so having multiple JVMs won't result in this memory doubling etc.

The JVM never releases memory to the OS, however if main memory is not used for a long time it can be swapped out if this is need.

The actual memory consumption is more than what what you set with Xmx etc, that's normal. "java will allocate memory for other things, including a stack for each thread. It is not unusual for the total memory consumption of the VM to exceed the value of -Xmx."

The paramaters -Xmx1600m -Xms1600m tells the JVM to allocate 1600MB of memory at minimum and 1600MB of memory at maximum. So the JVM should allocate 1600MB on start up and the never release it.

If you want the JVM to release memory back to the OS then the -Xms should be as low, and you probably have to use Java 1.7 with the new G1 garbage collector. stefankrause.net/wp/?p=14.

Using Mac OS X 10.8 and Java 1.7 with -Xms32m -Xmx256m -XX:+UseG1GC -XX:MinHeapFreeRatio=5 -XX:MaxHeapFreeRatio=10 the memory is release back to the OS after a System.gc() is run.

In the heap the Java Virtual Machine (JVM) stores all objects created by the Java application, e.g. by using the "new" operator. The Java garbage collector (gc) can logically separate the heap into different areas, so that the gc can faster identify objects which can get removed

The memory for new objects is allocated on the heap at run time. Instance variables live inside the object in which they are declared.

Stack is where the method invocations and the local variables are stored. If a method is called then its stack frame is put onto the top of the call stack. The stack frame holds the state of the method including which line of code is executing and the values of all local variables. The method at the top of the stack is always the current running method for that stack. Threads have their own call stack.

As said earlier in Java objects are created in the heap. The programming language does not offer the possibility to let the programmer decide if an objects should be generated in the stack. But in certain cases it would be desirable to allocate an object on the stack, as the memory allocation on the stack is cheaper then the memory allocation in the heap, deallocation on the stack is free and the stack is efficiently managed by the runtime.

The JVM uses therefore internally escape analysis to check if an object is used only with a thread or method. If the JVM identify this it may decide to create the object on the stack, increasing performance of the Java program. (http://www.ibm.com/developerworks/java/library/j-nativememory-linux/)