How to change Garbage collection thread's prio

问题:

This question is duplicate of Is it possible to change the priority of garbage Collector thread?

It is an old question and things might have changed a lot since then. Also it doesn't clarifies everything.

Is it possible to change GC thread priority? I have seen thread dumps with different GC thread priority. How does that happen if we cannot change it? Also, I understand that High frequency trading platforms want to keep GC thread priority very low so that main threads run most of the time and "Stop the world" event doesn't occur very often.

回答1:

Short answer : thread priorities cannot be used to avoid GC interference with the application threads.

Long answer:

The Java thread priorities are not respected by the JVM and the underlying OS. This is a well known problem which was addressed e.g. by RTSJ.

Java thread priority requirements are:

• specially designed VM that supports Java priorities, and
• a real-time OS.

Without both of these, the thread priorities will be used only as a hint and there are no guarantees that a higher priority thread will not be preempted by a lower priority thread.

GC threads priorities are set by the VM when creating the GC threads and cannot be modified from the user space.

Finally, the key techniques for high frequency trading or avoiding the GC stop-the-world pauses in general are a careful GC tuning and selecting a proper GC algorithm - both of these can be done in a comodity VM (e.g. HotspotVM).

回答2:

Is it possible to change GC thread priority?

I really think that this is the wrong question. You don't want to affect the priority of such a critical background operation. This could, depending on the thread architecture, starve the GC thread and bring down the JVM.

I think the right way to reduce the amount of CPU that the GC system uses is to reduce your object bandwidth -- reduce the number of objects that are being created and reclaimed. You should use a memory profiler to see what parts of your system are consuming too much memory or using too many temporary objects.

There are many ways to reduce the object bandwidth:

• changing to use mutable objects when appropriate (i.e. where the objects aren't shared between threads)
• clearing and reusing collections as opposed to reconstructing them
• using StringBuilder as opposed to serial String appends
• using slf4j type {} logging
• possibly using ThreadLocal to store state objects that can be reset and reused
• etc..

There are many ways to reduce the object bandwidth of your code and that ultimately will have much more impact on the memory performance of the JVM as opposed to playing with the thread priorities of the background system threads.

See @Voo's comment below for a good caveat to this however.