Practice of exit(0) in C and System.exit(0) in Java

Question

To use exit(0) in C is not a good practice, if there are alternatives, since it does not free resources for example. But to use System.exit(0) in Java - how is it here? Could one trust the garbage collector in this context?

C language:

 exit(0);

Java:

 System.exit(0)

Answer 1

But to use System.exit(0) in java - how is it here? Could one trust the garbage-collector in this context?

When you call System.exit in Java, the garbage collector is not normally run¹. However, in any JVM that I've ever heard of, there is something else that reclaims all of the objects that were allocated. (Typically it is handled at the operating system level.)

The fact that the GC doesn't run is only significant if you are relying on object finalizers to so something important before the JVM terminates.

Hypothetically, if your Java application used JNI (etc) to call native methods, then those methods could access system resources that might be problematic. However:

1. As a general rule the operating system does take care of such things. At least it does for modern versions of Linux and UNIX, AFAIK.

2. The garbage collector has no knowledge of those resources anyway. If the OS can't reclaim them, then the Java garbage collector won't help.

If you did need to clean up such resources acquired by a Java program (via native code) then the best approach would be to implement the cleanup in native code methods, and use a "shutdown hook" to run them. The shutdown hooks will be run if you call System.exit.

---

^{1 - A garbage collection will be performed on JVM exit if you have previously called runFinalizersOnExit(true). However, this is a deprecated method. The Oracle site explains it like this:}

^{Q: Why is Runtime.runFinalizersOnExit deprecated?}

^{A: Because it is inherently unsafe. It may result in finalizers being called on live objects while other threads are concurrently manipulating those objects, resulting in erratic behavior or deadlock. While this problem could be prevented if the class whose objects are being finalized were coded to "defend against" this call, most programmers do not defend against it. They assume that an object is dead at the time that its finalizer is called.}

^{Further, the call is not "thread-safe" in the sense that it sets a VM-global flag. This forces every class with a finalizer to defend against the finalization of live objects!}

^{In short, this is a dangerous approach, and it won't directly deal with the kind of resources that the OP is worried about.}