Java垃圾收集线程优先级

Question

我在接受采访时被问到以下问题： “垃圾收集线程的默认优先级是什么？” 我知道我们不能强制GC或改变它的优先级，虽然我从来没有听说过它的默认优先级。有谁知道吗？

Answer 1

面试官正在寻找的答案可能是GC处于低优先级的后台流程。这样做的原因是运行GC很昂贵，但它（通常）不是一个关键过程，所以只有在系统有时间做而不是中断关键任务时才应该这样做。 （在实时系统中存在类似的想法 - 在后台任务中执行不重要的过程，在前台执行所有关键过程 - 所有这些过程的优先级都高于后台任务。）

话虽如此，如果您阅读有关垃圾收集的Sun文献，只需将GC作为低优先级线程运行就不会完全。实际上，GC可能不仅仅是一个线程。相反，GC在内存不足时运行（尽管，确定内存何时仍然可能在后台线程中完成 - 也许其他人可以澄清这一点。）

以下是阅读GC的一些很好的链接：

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

Answer 2

我想说这个问题的正确答案是“如果你认为你需要担心垃圾收集器的线程优先级，你可能做错了什么”。

请记住，线程优先级不一定与进程获得的CPU时间直接相关。它因系统而异，但在Windows上，线程优先级主要用于确定等待运行的线程被调度到可用CPU的ORDER，以便高优先级线程可以抢占低优先级线程假设两个线程实际上都在争夺CPU。没有真正的规则来“为CPU提供更低优先级的CPU时间”。 （对于它的价值，在Linux上，线程优先级（漂亮的值）和分配的CPU时间之间存在更多的直接关系。）

对于在Windows中使用的线程优先级，对于像垃圾收集器这样的后台线程，一个更合适的解决方案可能 - 也许是矛盾的 - 给它一个高优先级，然后通过其他一些来控制CPU使用的比例意味着（基本上，故意在适当的时间内睡觉或等待适当的信号）。具体来说，高优先级适用于大多数时候不需要做任何事情的后台线程，但是当它确实需要做某事时，它需要尽快完成。

我实际上没有通过特定的垃圾收集算法查看使用了什么线程优先级（如果有的话）。但我的观点是情况有点复杂，基于对线程优先级的垃圾收集器行为的任何假设似乎很奇怪。

那些对线程优先级更感兴趣的人可能会想看一下我所采用的measurements of the effect of thread priorities - 几年前就已经承认了，而且这些材料可以用来更新。

更新：巧合，昨天在YouTube上发布了talk by Cliff Click。大约35分钟后，他提到了这一点，某些JIT和GC线程需要高优先级，以免它们变得饥饿。

Answer 3

也许问题是针对JVM的实际实现。正如您可以在在线参考中阅读的那样，有多种方法可以实现垃圾收集器，它可能会随版本而变化。这就是为什么每个人都告诉你不要依赖GC的行为。它可能在另一个JVM上有所不同。

Answer 4

它是低优先级线程（不确定确切的优先级）。这里的要点是尽可能避免GC减慢普通线程。我会说它的优先级低于正常值：）

Answer 5

至少在Java RTS中，可以根据需要调整垃圾收集线程的优先级。优先级调整（以及一般的线程调度）与多个CPU相比也有所不同，只有一个。

目前，我将假设一个多CPU配置，因为那是（到目前为止）最常见的配置。我也只谈论默认调度程序 - 其他调度程序可以完全不同地做事情。你的线程基本上分为两类：关键优先级和非关键优先级（你也可以拥有“无堆实时”线程，这些线程高于其中任何一个，但由于它们没有/不能使用堆，它们与GC无关）。垃圾收集线程通常以低于其中任何一个的优先级运行，但是当/如果需要时，可以提升到比非关键线程更高的优先级。 GC线程优先级始终低于关键实时线程的优先级。

我对“关键”和“非关键”优先级之间的划分有点模糊，原因是：这对于调整是开放的。您可以选择GC可以抢占哪些线程优先级，哪些不可以。目的是关键线程获得硬实时响应，非关键线程获得软实时响应。由您来决定/配置哪些线程属于哪个类别。