Java垃圾收集线程优先级

Question

我在面试中被问到以下问题:"垃圾收集线程的默认优先级是什么？" 我知道我们不能强制GC或改变它的优先级,虽然我从来没有听说过它的默认优先级.有人知道吗？

Answer 1

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

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

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

• http://www.javacoffeebreak.com/articles/thinkinginjava/abitaboutgarbagecollection.html
• 是否可以更改垃圾收集器线程的优先级？

Answer 2

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

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

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

我实际上还没有查看特定垃圾收集算法使用了哪些线程优先级（如果有）。但我的观点是，情况有些复杂，将关于垃圾收集器行为的任何假设建立在线程优先级上似乎很奇怪。

那些对线程优先级更感兴趣的人可能想看看我对线程优先级的影响进行的一些测量——不可否认，现在是几年前，而且这些材料可以更新。

更新：巧合的是，昨天在 YouTube 上发布了 Cliff Click的演讲。大约 35 分钟后，他准确地提到了这一点，即某些 JIT 和 GC 线程需要运行高优先级，以免它们被饿死。