The question to me was whether is ever made sense to do a
System.gc(), and, more specifically, whether it made sense to do
I can't claim it is always wrong. It suffers from what some people call the Politician's syllogism: Something must be done, this is something, therefore we must do it. There's no control over GC other than a big red button labeled "System.gc()", so this is always the something that must be done.
In practice, the biggest problem with
System.gc()is that what it does is rather unpredictable. In fact, there's no guarantee that it will do anything. In fact, Hotspot has a
-XX:DisableExplicitGCflag to stop it from doing anything. So, it can sometimes solve an immediate problem in a system-dependent way, but you are introducing a significant source of overhead with ill-defined behavior into your code, and that behavior can change with a change of flags or a change of runtime.
Using the concurrent collector (our default at G),
System.gc()forces a Full, stop-the-world GC instead of a concurrent GC. By calling
System.gc(), you are stopping the world for potentially much longer than just letting a concurrent collection happen would. At G, our Full STW GC under CMS is parallel, and the rest of the world's is serial, so it will finish faster for us than it will for everyone else. Except the rest of the world has the parallel GC by default, so it will be parallel. Except that they're changing it to G1 for Java 9, which has a serial full STW GC, so it won't be parallel.
Of course, if you are using the concurrent collector, it matters if the user passes
-XX:+ExplicitGCInvokesConcurrent, in which case
System.gc()will happen concurrently, which would mean that the application will continue executing, and you will probably call runFinalization() before the GC has enqueued the finalizable objects.
It should be relatively clear at this point that you can't depend on it for performance, because you can't guarantee its performance, and you can't depend on it for correctness, because you have no idea what it is going to do.
If you really want to wait for a GC to occur and for some percentage of objects to be finalized, you probably to do something like:
- Create a CountDownLatch with a count of 1.
- Create an object whose finalizer calls countDown().
- Make the object garbage immediately (bearing in mind that object lifetimes aren't what you think they might be).
- Call System.gc().
- Call await() on the CountDownLatch.
- Call runFinalization to make sure all of the pending finalizers are finished (but do it in a loop with a timeout!)
In short, usage should be carefully considered.
runFinalization: it suffers from the same "I have one button for this" issue. What it does (in Hotspot) is add a thread as a worker for processing finalization, and then return when that thread is done (i.e., the finalization queue is empty, although note that the finalization queue being empty is not the same as all finalizers having been run, since there are two other threads processing them).
How much are you buying by blocking until the finalization queue is empty? Do you really want to stop the application for this? Is it going to do what you think it is going to do? Are you sure the finalizer you care about is enqueued?
Hey, if you have lots of GCs, and expensive finalizers, one could even imagine the finalization queue not ever being empty. This is fairly unlikely, in practice, but would be really, really nasty if it happened.
Anyway, let the buyer beware. Google tells me that the first couple of hits for "System.gc()" are also nasty warnings, but I had already written this, so there is no harm in posting it anyway.