Java Garbage Collection thread priority

I have been asked in an interview the following question: "What is the default priority of the Garbage Collect开发者_如何学运维ion thread?" I know we cannot force a GC or change its priority, though I never heard about its default priority. Does anyone know?

Probably the answer that the interviewer was looking for is that the GC is on a low-priority, background process. The reason for this is that running the GC is expensive, but it is not (typically) a critical process, so it should only be done when the system has time to do it rather than interrupt critical tasks. (A similar idea exists in real-time systems - do the unimportant processes in the background task, and all critical processes in the foreground - all of which will have higher priority than the background task.)

With that said, if you read Sun literature on garbage collection, just running GC as a low-priority thread is not quite right. In actuality, the GC may not be just a single thread. Instead, the GC runs when memory is low (although, determining when memory is low is still probably done in a background thread - maybe someone else can clarify this).

Here are some good links for reading on GC:

• http://www.javacoffeebreak.com/articles/thinkinginjava/abitaboutgarbagecollection.html
• Is it possible to change the priority of garbage Collector thread?

I would say the correct answer to this question is "if you think you need to worry about the thread priority of the garbage collector, you're probably doing something wrong".

Remember that thread priority isn't necessarily directly related to how much CPU time a process gets. It varies from system to system, but on Windows, thread priority is essentially used to determine the ORDER in which threads that are waiting to run are scheduled on to the available CPUs, so that high-priority threads can pre-empt low-priority threads, assuming that both threads are actually competing for CPU. There's no real rule to "give CPUs with lower priority less CPU time". (For what it's worth, on Linux, there is a little bit more of a direct relationship between thread priorities (nice values) and allocated CPU time.)

With thread priorities used as they are in Windows, for a background thread like a garbage collector, a more appropriate solution may-- perhaps paradoxically-- to give it a HIGH priority and then control the proportion of CPU usage by some other means (essentially, deliberately sleeping for appropriate proportions of time or waiting for appropriate signals). Specifically, the high priority is appropriate for a background thread that doesn't need to do anything most of the time, but when it does need to do something, it needs to do it as soon as possible.

I actually haven't looked at what thread priorities are used, if any, by particular garbage collection algorithms. But my point is that the situation is somewhat complex and it seems odd to base any assumptions about the behaviour of the garbage collector on thread priorities.

Those interested more in thread priorities may like to look at some measurements of the effect of thread priorities that I took-- admittedly a couple of years ago now and this material could do with being updated.

Update: by coincidence, a talk by Cliff Click was posted on YouTube yesterday. About 35 minutes in, he mentions precisely this point, that certain JIT and GC threads need to run high priority so that they don't get starved.

It is low priority thread (not sure about exact priority). The point here is to avoid GC to slow down ordinary thread where possible. I would say it has lower than normal priority :)

Maybe the question was aiming at the actual implementation of the JVM. As you can read in online references there are multiple ways to implement a garbage collector and it may change from version to version. That's why everyone tells you not to rely on the behavior of the GC. It might work differently on another JVM.

At least in Java RTS, the priority of the garbage collection thread(s) can be adjusted based on need. Priority adjustment (and thread scheduling in general) is also rather different with multiple CPUs than with just one.

For the moment, I'll assume a multiple-CPU configuration, since that's (by far) the most common anymore. I'm also talking only about the default scheduler -- other schedulers can do things entirely differently. Your threads basically fall into two classes: critical and non-critical priority (you can also have "no-heap real-time" threads, which are higher than either, but since they don't/can't use the heap, they have little relevance to GC). The garbage collection thread(s) normally run(s) at lower priority than either of those, but can be boosted to higher priority than your non-critical threads when/if needed. The GC thread priority always stays lower than that of your critical real-time threads though.

I've been a bit vague about the delineation between "critical" and "non-critical" priorities for a reason: that's open to tuning. You can select what priorities of your threads can be preempted by the GC, and what can't. The intent is that critical threads get hard real time response, and non-critical threads get soft real-time response. It's up to you to decide/configure which threads fall into which category.