tags:

views:

349

answers:

4

I want to calculate the heap usage for my app. I would like to get a procent value of Heap size only.

How do I get the value in code for the current running app?

EDIT

There was an upvoted answer that was NOT complete/correct. The values returned by those methods include stack and method area too, and I need to monitor only heap size.
With that code I got HeapError exception when I reached 43%, so I can't use those methods to monitor just heap

Runtime.getRuntime().totalMemory()
+2  A: 

dbyme's answer is not accurate - these Runtime calls give you an amount of memory used by JVM, but this memory does not consist only of heap , there is also stack and method area e.g.

binary_runner
This is true. I get Heap memory error, when I reached 43% of usage.
Pentium10
Good call. I am really interested to know the correct answer now.
dbyrne
+1  A: 

This information is exposed over the JMX management interface. If you simply want to look at it, JConsole or visualvm (part of the JDK, installed in JAVA_HOME/bin) can display nice graphs of a JVM's memory usage, optionally broken down into the various memory pools.

This interface can also be accessed programmatically; see MemoryMXBean.

meriton
Since I am on Android, I don't have access to those.
Pentium10
Try using the interface directly, then. I added a link to get you started.
meriton
A: 

There really is no good answer, since how much heap memory the JVM has free is not the same as how much heap memory the operating system has free, which are both not the same as how much heap memory can be assigned to your application.

This is because the JVM and OS heaps are different. When the JVM runs out of memory, it may run garbage-collection, defragment its own heap, or request more memory from the OS. Since unused non-garbage-collected objects still exist, but are technically "free", they make the concept of free memory a bit fuzzy.

Also, heap memory fragments; how/when/if memory is defragmented is up to the implementation of the JVM/OS. For example, the OS-heap may have 100MB of free memory, but due to fragmentation, the largest available contiguous space may be 2MB. Thus, if the JVM requests 3MB, it may get an out-of-memory error, even though 100MB are still available. It is not possible for the JVM to know ahead of time that the OS won't be able to allocate that 3MB.

BlueRaja - Danny Pflughoeft
How can you detect that your app is in critical mood, reaching that level?
Pentium10
@Pentium10: [Start Java with a large heap](http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html#0.0.0.%20Total%20Heap|outline), then when you want to check, run the garbage collector manually and check the free space afterwards. I would say anything under 40% is bad, but as you saw it's possible to run out of memory with even more free memory than that. Also, running the garbage collector manually is *extremely* slow, and not something you'd want to do in any actual application. Why are you doing this?
BlueRaja - Danny Pflughoeft
@BlueRaja I have a sort of backtracking generation process run on Android mobile device, where I can't start Java with large heap. I need to stop the generation process before it's too late.
Pentium10
@Pentium10: What are you doing that you're taking up so much memory? A backtracking algorithm shouldn't be allocating too much on the heap...
BlueRaja - Danny Pflughoeft
@BlueRaja generating some text, that is causing the problems
Pentium10
+1  A: 

MemoryMXBean bean = ManagementFactory.getMemoryMXBean(); bean.getHeapMemoryUsage().getUsed();