Introduction

Runtime.getRuntime().totalMemory() and freeMemory() describe the Java heap that the JVM has currently allocated, not all memory your process could ever use. They are useful for rough runtime inspection, but they are often misunderstood because they do not directly mean "total RAM" and "RAM still free on the machine."

What totalMemory() Means

totalMemory() returns the amount of heap memory the JVM has currently reserved from the operating system. It is not the maximum heap size. It is the current allocated heap space that the JVM is managing right now.

So if the JVM started with a smaller heap and can still grow, totalMemory() may be much lower than the eventual maximum allowed by -Xmx.

What freeMemory() Means

freeMemory() returns how much of that already allocated heap is currently unused. It does not include memory the JVM could request later from the OS. It only answers the narrower question: inside the heap we already have, how much space is free right now?

That is why freeMemory() can look small even when the JVM is still capable of growing the heap further.

The Useful Derived Number

If you want approximate used heap within the currently allocated heap:

Runtime rt = Runtime.getRuntime();
long used = rt.totalMemory() - rt.freeMemory();
System.out.println(used);

That gives you used heap inside the current allocation, not full process memory and not full machine memory.

Example Program

1public class MemoryExample {
2    public static void main(String[] args) {
3        Runtime rt = Runtime.getRuntime();
4
5        System.out.println("totalMemory = " + rt.totalMemory());
6        System.out.println("freeMemory  = " + rt.freeMemory());
7        System.out.println("maxMemory   = " + rt.maxMemory());
8        System.out.println("usedHeap    = " + (rt.totalMemory() - rt.freeMemory()));
9    }
10}

maxMemory() is often the missing piece. It tells you the upper bound the heap may grow to, subject to JVM configuration.

Why These Numbers Move

The JVM changes heap usage over time because of:

• object allocation
• garbage collection
• heap expansion
• heap shrink behavior

So calling these methods twice in a row can produce very different results, especially around allocation spikes or GC cycles.

That is why they are useful for rough diagnostics, but not a substitute for proper profiling tools.

It also means benchmark code can mislead you if you read these numbers at arbitrary times. Memory snapshots around startup, after warmup, and after a forced GC can tell very different stories even when the application code did not change.

That context is easy to miss when people print the values once and assume they are stable.

In practice, these methods are best used for quick observations during debugging or logging, not as the sole basis for capacity planning.

What They Do Not Tell You

These values do not include every memory category the Java process uses. They do not directly measure thread stacks, native allocations, direct byte buffers, code cache, or full OS-level process RSS. If you need a complete memory picture, you need more than these two runtime methods.

Common Pitfalls

• Thinking totalMemory() means total machine memory.
• Thinking freeMemory() means memory free on the host OS.
• Forgetting that maxMemory() is different from totalMemory().
• Treating one snapshot as a stable truth in a garbage-collected runtime.
• Using these methods as a replacement for real memory profiling.

Summary

• 'totalMemory() is the heap currently allocated by the JVM.'
• 'freeMemory() is unused space inside that currently allocated heap.'
• 'totalMemory() - freeMemory() approximates used heap within the current allocation.'
• 'maxMemory() is the upper bound the heap may grow toward.'
• These methods are helpful for quick diagnostics, not full memory analysis.