1. Overview
In this tutorial, we're going to investigate the System.gc() method located in the java.lang package.
Explicitly calling System.gc() is known for being a bad practice. Let's try to understand why and if there are any use cases when calling this method might be useful.
2. Garbage Collection
The Java Virtual Machine decides to perform garbage collection when there are indications to do so. Those indications differ from one GC implementation to another. They are based on different heuristics. However, there are a few moments when GC will be executed for sure:
- New generation (Tenured space) is full, which triggers minor GC
- Old generation (Eden + Survivor0 + Survivor1 spaces) is full, which triggers major/full GC
The only thing that is independent of the GC implementation is object eligibility to be garbage collected.
Now, we'll have a look at the System.gc() method itself.
3. System.gc()
An invocation of the method is simple:
System.gc()
The official Oracle documentation states that:
Calling the gc method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse.
There is no guarantee that the actual GC will be triggered.
System.gc() triggers a major GC. Hence, there is a risk of spending some time on the stop-the-world phase, depending on your garbage collector implementation. As a result, we have an unreliable tool with a potentially significant performance penalty.
Existence of explicit garbage collection invocation should be a serious red flag for everyone.
We can prevent System.gc() from doing any work by using the -XX:DisableExplicitGC JVM flag.
3.1. Performance Tuning
It's worth noting that just before throwing an OutOfMemoryError, the JVM will perform a full GC. Therefore, an explicit call to System.gc() will not save us from failure.
Garbage collectors nowadays are really smart. They have all knowledge about memory usage and other statistics to be able to make proper decisions. Hence, we should trust them.
In case of memory issues, we have a bunch of settings we can change to tune our application — starting from choosing a different garbage collector, through setting desired application time/GC time ratio, and finally, ending with setting fixed sizes for memory segments.
There are also ways to mitigate the effects of Full GC caused by an explicit call. We can use one of the flags:
-XX:+ExplicitGCInvokesConcurrent
or:
-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses
If we really want our app to work properly, we should solve the real underlying memory problem.
In the next chapter, we'll see a practical example when explicitly calling System.gc() seems to be useful.
4. Usage Example
4.1. Scenario
Let's write a test app. We want to find a situation when calling System.gc() might be useful.
Minor garbage collection happens more often than the major one. So, we should probably focus on the latter. A single object is moved to tenured space if it “survived” a few collections and is still reachable from GC roots.
Let's imagine we have a huge collection of objects that are alive for some time. Then, at some point, we're clearing the collection of objects. Maybe it's a good moment to run System.gc()?
4.2. Demo Application
We'll create a simple console app that will allow us to simulate that scenario:
public class DemoApplication {
private static final Map<String, String> cache = new HashMap<String, String>();
public static void main(String[] args) {
Scanner scanner = new Scanner(System.in);
while (scanner.hasNext()) {
final String next = scanner.next();
if ("fill".equals(next)) {
for (int i = 0; i < 1000000; i++) {
cache.put(randomUUID().toString(), randomUUID().toString());
}
} else if ("invalidate".equals(next)) {
cache.clear();
} else if ("gc".equals(next)) {
System.gc();
} else if ("exit".equals(next)) {
System.exit(0);
} else {
System.out.println("unknown");
}
}
}
}
4.3. Running the Demo
Let's run our application with a few additional flags:
-XX:+PrintGCDetails -Xloggc:gclog.log -Xms100M -Xmx500M -XX:+UseConcMarkSweepGC
The first two flags are needed to log GC information. The next two flags are setting initial heap size and then maximum heap size. We want to keep the heap size low to force GC to be more active. Finally, we're deciding to use CMS – Concurrent Mark and Sweep garbage collector. It's time to run our app!
First, let's try to fill tenured space. Type fill.
We can investigate our gclog.log file to see what happened. We'll see around 15 collections. The line logged for single collections looks like:
197.057: [GC (Allocation Failure) 197.057: [ParNew: 67498K->40K(75840K), 0.0016945 secs] 168754K->101295K(244192K), 0.0017865 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] secs]
As we can see, the memory is filled.
Next, let's force System.gc() by typing gc. We can see memory usage didn't change significantly:
238.810: [Full GC (System.gc()) 238.810: [CMS: 101255K->101231K(168352K); 0.2634318 secs] 120693K->101231K(244192K), [Metaspace: 32186K->32186K(1079296K)], 0.2635908 secs] [Times: user=0.27 sys=0.00, real=0.26 secs]
After a few more runs, we'll see that memory size stays at the same level.
Let's clear the cache by typing invalidate. We should see no more log lines appear in the gclog.log file.
We can try to fill cache a few more times, but no GC is happening. This is a moment when we can outsmart the garbage collector. Now, after forcing GC, we'll see a line like:
262.124: [Full GC (System.gc()) 262.124: [CMS: 101523K->14122K(169324K); 0.0975656 secs] 103369K->14122K(245612K), [Metaspace: 32203K->32203K(1079296K)], 0.0977279 secs] [Times: user=0.10 sys=0.00, real=0.10 secs]
We've released an impressive amount of memory! But was it really necessary right now? What happened?
According to this example, calling System.gc() might seem tempting when we're releasing big objects or invalidating caches.
5. Other Usages
There are very few reasons when an explicit call to the System.gc() method might be useful.
One possible reason is cleaning memory after server startup — we're starting a server or application which does a lot of preparation. After that, there are a lot of objects to be finalized. However, cleaning after such preparation shouldn't be our responsibility.
Another is memory leak analysis — it's more a debugging practice than something we would like to keep in the production code. Calling System.gc() and seeing heap space still being high might be an indication of a memory leak.
6. Summary
In this article, we investigated the System.gc() method and when it might seem useful.
We should never rely on it when it comes to the correctness of our app. GC in most cases is smarter than us, and in case of any memory problems, we should consider tuning the virtual machine instead of making such an explicit call.
As usual, the code used in this article can be found over on GitHub.