When does garbage collection work in java?

问题:

I knew that there are a lot of articles about java garbage collection but after searching I don't know exactly "when dose the garbage collection run in a java application?(when the application restart or while it still running)".

回答1:

Garbage Collector is a dameon thread. A dameon thread runs behind the application. It is started by JVM. The thread stops when all non-dameon threads stop.

The JVM controls the Garbage Collector; it decides when to run the Garbage Collector. JVM runs the Garbage Collector when it realizes that the memory is running low. The behavior of GC can be tuned by passing parameters to JVM.

One can request the Garbage Collection to happen from within the java program but there is no guarantee that this request will be taken care of by jvm.Check How to force garbage collection in Java?

Learn More ..

回答2:

Garbage collection runs regularly alongside the program. It is part of the JVM.

When exactly does it run though? Well, that's unpredictable, version-dependent, and should be treated as if it could run at any time.

When a variable goes out of scope, the application tells the JVM it's done with that piece of memory. Then, when the garbage collector runs it will free those resources for the OS to use.

For example

String capitalizeAll(String s) {
    char[] chars = s.toCharArray();
    for(int i = 0; i < chars.length; i++)
        chars[i] -= 32;
    return new String(chars);
}

As soon as the method returns, the char[] chars allocated within the method will go out of scope. The program tells the JVM it's done with those resources and next time GC runs they will be freed.

Interesting stuff though, the JVM takes into account how much the app has told it is ready to be collected. That means that if your app does a lot of unnecessary copying or boxing, JVM will run often and cause your app to take a performance hit.

回答3:

This is mostly implementation-specific.

The most primitive type of garbage collector, the serial GC will be triggered when it fails to find sufficient free space during an allocation (with generational GCs this usually means the young generation is full). It then suspends the entire JVM by triggering a safepoint on mutator threads and does its work on a single thread, this is called a "stop the world pause" In this case you can say that GCs can be caused by any allocation.

On top of that some GCs may also do background work concurrently to mutators, such as Hotspot's CMS. But it still needs stop the world pauses for some work, they just tend to be shorter than in the serial GC. For CMS it's still triggered by allocations but also does some of its work on background thread(s).

Azul Zing's concurrent compacting collector also does - as its name says - concurrent collecting on dedicated threads more or less all the time. It still needs cooperation from the mutator threads but does so without STW pauses. So this case one could say that the GC is running all the time in the background and does a little work in the foreground.

There are other collectors out there, so this isn't a comprehensive overview. But in general it's an implementation detail, subject to change and not something one should rely on. Some GCs even ignore System.gc() by default because it would mess up their heuristics.

回答4:

This is from Kathy Sierra and Bert Bates' book SCJP Study Guide:

"The garbage collector is under the control of the JVM. The JVM decides when to run the garbage collector. From within your Java program, you can ask the JVM to run the garbage collector, but there are no guarantees, under any circumstances, that the JVM will comply. Left to its own devices, the JVM will typically run the garbage collector when it senses that memory is running low. Experience indicates that when your Java program makes a request for garbage collection, the JVM will usually grant your request in short order, but there are no guarantees. Just when you think you can count on it, the JVM will decide to ignore your request."