HOWTO · Java

How to Use System.gc() for Garbage Collection in Java

This tutorial demonstrates how to use System.gc() for garbage collection in Java.

On this page

System.gc() is a Java API call that requests garbage collection from the Java Virtual Machine (JVM). It is equivalent to calling Runtime.getRuntime().gc(). The request does not directly delete objects or clear variables. An object is eligible for collection only when the program can no longer reach it through live references, and the JVM decides whether and when to reclaim eligible objects.

Use System.gc() to understand the request mechanism, not as a command that guarantees memory will be freed. A program can continue to hold references after making the call, and the JVM may defer or omit collection. The request also does not promise a particular collector, amount of reclaimed memory, pause duration, or ordering relative to other runtime work.

What System.gc() Does

The call asks the JVM to make an effort to reclaim memory occupied by objects that are no longer reachable. It does not remove objects that are still in use, and it does not make a variable release its reference. For example, if a collection remains reachable from a static field or a live stack frame, requesting collection does not make that collection eligible merely because the request was made.

This distinction matters when diagnosing memory use. Used heap can stay high after a request when objects remain reachable or the JVM has not collected them. Separately, the JVM may keep reclaimed heap space committed for later allocations; that retained space is committed heap, not used heap. A successful return from System.gc() is not a report of bytes reclaimed.

How to Call System.gc() in Java

Call the static method directly when you have a specific reason to send the request. This small Java program makes one request and then prints a message from the program. The message indicates only that execution continued after the call; it does not show that any object was collected. Run this example:

public class SystemGcRequest {
    public static void main(String[] args) {
        System.gc();
        System.out.println("Returned from the garbage-collection request.");
    }
}
Returned from the garbage-collection request.

The example has no objects whose reachability it measures, so it cannot demonstrate that memory was reclaimed. Keeping the example small makes the API call clear without implying that a particular amount of memory or a particular object will be collected.

Why a GC Request Does Not Guarantee Collection

System.gc() asks the runtime to make an effort toward garbage collection. The official Java API documentation for System.gc() describes the call as a suggestion to the JVM; it does not promise that a particular object or amount of memory will be reclaimed. A normal return from the method is not evidence that collection completed. Runtime settings can also disable explicit garbage-collection requests. Therefore, application correctness must not depend on this call freeing memory at a chosen time.

Finalization is not a reliable way to verify the request. Finalizers may run late or not run before the program exits, and their order is not guaranteed. Printing from a finalizer cannot establish that one call caused one collection. Avoid using finalizer output, a fixed collection count, or a before-and-after heap reading as proof that the call worked; other runtime activity and measurement timing affect those observations.

When to Use System.gc()

Most application code should let the JVM manage collection. Calling System.gc() repeatedly can add work or pause time without improving the program’s memory behavior, and using it to manage a cache does not replace removing entries or releasing references. Prefer explicit ownership and eviction policies for application data.

A request can be appropriate in controlled situations where an operator or tool has a specific reason to ask the runtime to attempt collection, such as an interactive diagnostic workflow. Treat it as a best-effort hint, and measure the workload before and after with suitable JVM monitoring or profiling tools. If memory remains high, investigate which objects are reachable and where references are retained. Do not make correct program behavior depend on System.gc() or on finalization timing.