我曾经被要求增加线程优先级来解决问题。我拒绝，说更改它是危险的，而不是问题的根本原因。

我的问题是，在什么情况下应该考虑更改线程的优先级？

解决方案

不多。我唯一必须朝积极方向更改线程优先级的时间是使用用户界面线程。用户界面必须非常灵活，才能使应用程序感觉良好，因此很多时候最好将绘画线程的优先级设置为高于其他线程。例如，默认情况下，Swing Event Dispatch线程以优先级6运行(比默认值高1)。

我确实将线程优先级降低了很多。同样，这通常是为了在某些长时间运行的后台进程执行其操作时保持UI响应。但是，有时这也适用于轮询守护程序等，我知道我不想干扰任何东西，而不管干扰有多小。

我要说的是，当我们对线程的原始设计假设不再有效时。

线程优先级主要是关于什么工作最重要的设计决策。因此，对于何时重新考虑的一些示例：如果添加了可能需要其自己的线程变得更重要的新功能，则重新考虑线程优先级。如果某些要求发生变化，迫使我们重新考虑正在执行的工作的优先级，请重新考虑。或者，如果我们进行性能测试并且意识到设计中指定的"高优先级工作"没有获得所需的性能，则可以调整优先级。

否则，它通常是一个hack。

我们的应用程序使用后台线程下载数据，我们不希望它干扰单核计算机上的UI线程，因此我们特意优先考虑较低的线程。

列出要使用的线程后，并为其定义优先级顺序，这对它们的工作意义重大。

如果我们在这里和那里轻推线程以解决问题，最终他们将被列为最高优先级，并且我们回到了起点。不要认为我们确实可以在需要锁定的情况下使用优先级修复竞争条件，因为我们可能只是在友好的条件下修复了竞争条件。仍然可能会失败，例如，由于另一个高优先级线程正在等待它持有的另一个锁，因此低优先级线程已经进行了优先级继承。

如果我们按照"这些线程填充音频缓冲区"，"这些线程使我的应用程序响应系统事件"，"这些线程使我的应用程序响应用户"，以及并会在它们准备好并准备就绪时进行报告"，然后应该相应地对线程进行优先级排序。

最后，它取决于操作系统。如果线程优先级完全落后于进程优先级，那么对线程进行优先级排序不应"危险"：唯一让CPU饿死的事情就是自己。但是，如果高优先级线程优先于其他不相关应用程序的普通优先级线程运行，那么我们将承担更广泛的责任。我们只应提高执行少量紧急工作的线程的优先级。 "小型"的定义取决于我们所使用的3GHz多核处理器所使用的设备种类，而我们却经常遇到这种情况，但是移动设备可能会对用户级应用程序可能会崩溃的伪实时期望。

不过，保持音频缓冲区服务是何时具有较高优先级的典型示例，因为小的欠载通常会导致令人讨厌的crack啪声。长下载(或者其他慢速I / O)是何时将优先级降低的典型示例，因为如果下一个数据无论如何也不会老化，则无需紧急处理此数据块。如果我们要编写设备驱动程序，则需要做出更复杂的决定，以与他人保持良好的关系。

我认为这取决于我们要更改优先级的方向。

通常，除非有充分的理由，否则永远不要增加线程优先级。增加线程优先级可能会导致应用程序的线程开始占用其他应用程序的时间，这可能不是用户想要的。如果线程正在使用大量CPU，则可能会导致计算机难以使用，因为某些标准UI线程可能会开始饿死。

我想说的是，我们应该将优先级提高到比正常情况高的唯一情况是，如果用户明确告诉应用程序这样做，但是即使这样，我们仍然希望阻止"无知"的用户这样做。也许，如果应用程序通常不会使用太多CPU，但是可能会短暂爆发真正重要的活动，那么可以增加优先级就可以了，因为通常不会降低用户的总体体验。

降低优先级是另一回事。如果应用所做的事情需要占用大量CPU并可以长时间运行，但并不是很关键，那么降低优先级就可以了。通过降低优先级，我们可以在需要时将CPU用作其他用途，这有助于保持系统快速响应。只要系统除了应用程序之外大部分时间都处于闲置状态，我们仍将获得大部分CPU时间，但不会占用比我们更多的任务。这样的一个例子是一个索引硬盘驱动器的线程(想想谷歌桌面)。