为什么*不*更改 ThreadPool（或任务）线程的优先级？
在网络和 Stack Overflow 上的许多地方，人们不鼓励更改 ThreadPool 线程或 TPL Task 的优先级。特别是：
"您无法控制线程池线程的状态和优先级。 ”
“运行时管理线程池。您无法控制线程的调度，也无法更改线程的优先级。”
“您不应该更改 PoolThread 的文化或优先级或......。就像您不粉刷或重新装饰租赁的汽车一样。”
“有几种情况适合创建和管理您自己的线程，而不是使用线程池线程：（例如......）您需要线程具有特定的优先级。”
“ThreadPool 中的每个线程都以默认优先级运行，更改 ThreadPriority 的代码没有任何效果。”
然而，这样做很简单，调试器显示更改确实有效 em> 似乎坚持（只要该值可以读回）。
Thread.CurrentThread.Priority = ThreadPriority.AboveNormal;
那么问题来了，这种特殊禁忌的具体原因是什么？
我的怀疑：这样做会扰乱池的微妙负载平衡假设。但这并不能解释为什么有些消息来源说您无法更改它。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
线程池，尤其是.NET 4.0线程池，有很多技巧，是一个相当复杂的系统。添加任务和任务调度程序以及工作窃取和各种其他事情，现实是您不知道发生了什么。线程池可能会注意到您的任务正在等待 I/O，并决定在您的任务上快速安排某些任务或挂起您的线程以运行更高优先级的任务。您的线程可能以某种方式依赖于更高优先级的线程（您可能知道也可能不知道）并最终导致死锁。您的线程可能会以某种异常方式死亡并且无法恢复优先级。
如果您有一个长时间运行的任务，并且您认为线程最好具有较低的优先级，那么线程池可能不适合您。虽然算法在 .NET 4.0 中得到了改进，但它仍然最适合用于短期任务，其中创建新线程的成本与任务的长度不成比例。如果您的任务运行时间超过一两秒，则创建新线程的成本微不足道（尽管管理可能很烦人）。
The thread pool, especially the .NET 4.0 thread pool, has many tricks up its sleeve and is a rather complicated system. Add in tasks and task schedulers and work stealing and all sorts of other things and the reality is you don't know what is going on. The thread pool may notice that your task is waiting on I/O and decide to schedule something quick on your task or suspend your thread to run something of higher priority. Your thread may somehow be a dependency for a higher-priority thread (that you may or may not be aware of) and end up causing a deadlock. Your thread may die in some abnormal way and be unable to restore priority.
If you have a long-running task such that you think it would be best that your thread have a lower priority then the thread pool probably isn't for you. While the algorithms have been improved in .NET 4.0, it is still best used for short-lived tasks where the cost of creating a new thread is disproportional to the length of the task. If your task runs for more than a second or two the cost of creating a new thread is insignificant (although management might be annoying).
我已经对尺寸减小的线程池进行了一些实验，这似乎表明线程的优先级一旦返回到池中就会重置回正常状态。 这个关于线程的资源似乎证实了这一点。所以即使你这样做，效果似乎也很有限。
I've done some experimentation with a reduced-size thread pool which seems to indicate that the thread's priority is reset back to normal once returned to the pool. This resource on threading seems to confirm it. So the effect seems to be very limited even if you do.
降低优先级也可能导致意想不到的后果。
想象一下，您在应用程序中安排了一个任务，但也调用了一个库来安排其他几个任务。假设您在应用程序任务运行时降低线程优先级。如果池没有产生很多线程，那么您可能会在库中等待低优先级任务完成，但是如果其余的线程，则低优先级线程可能不会获得太多的 CPU 时间。系统有许多普通优先级线程想要运行。
增加池线程的数量可以缓解这种情况，但代价是在堆栈上浪费更多内存并在上下文切换上花费更多 CPU 时间。
Lowering the priority could also lead to unexpected consequences.
Imagine you schedule a task in an application, but also call into a library that schedules several other tasks. Say you lower the thread priority while the app task runs. You could then end up with the normal priority tasks in the lib waiting for that low priority task to finish, if the pool doesn't spawn many threads, but the low priority thread it may not be given much CPU time if the rest of the system has many normal priority threads that want to run.
Increasing the number of pool threads would alleviate this, at the cost of wasting more memory on stacks and spending more CPU time on context switches.
如果您确实想要的话，当然可以更改它，但考虑到线程池线程被重用，下一个运行的代码可能不会期望发生更改。
You certainly can change it if you really want to, but given that the thread pool threads are re-used, the next code that runs might not expect the change.
如果您确实更改了任何内容，请使用 try/finally 来确保将其保留为您发现的样子。
If you do change anything, use try/finally to make sure you leave it as you found it.
不鼓励这样做，特别是当您提高优先级时，因为它会影响系统的整体性能。
并不是要提供过于复杂的答案，但总的来说，线程优先级是一个复杂的主题。例如，Windows有2个相关的描述符：线程优先级和进程优先级。两者的范围从空闲（最低）到时间关键（最高）。当您启动一个新进程时，它被设置为默认值，中间范围（具有正常线程优先级的正常进程优先级）。
另外，线程优先级是相对的，这意味着即使在繁忙的系统中将线程的优先级设置为最高也不能确保它“实时”运行。 DotNET 对此不提供保证，Windows 也不提供保证。由此您可以看出为什么最好不要使用线程池，因为 99.9% 的情况下，它最了解:)
话虽如此，如果任务涉及长时间计算，则可以降低线程的优先级。这不会影响其他进程。
然而，只有对于需要快速反应且执行时间短的任务才应该增加优先级，因为这可能会对其他进程产生负面影响。
It's discouraged, specially if you're upping the priority, because it can affect the overall performance of your system.
Not to offer an overcomplicated answer, but in general, thread priority is a complex topic. For example, Windows has 2 related descriptors: thread priority and process priority. Both range from Idle, the lowest, to Time critical, the highest. When you start a new process, it's set to the default, the mid-range (a normal process priority with a normal thread priority).
Plus, thread priorities are relative, meaning that even setting a thread's priority to the highest in a busy system won't ensure that it will run in 'real-time'. DotNET offers no guarantees on this, neither does Windows. From that you can see why it's better to leave the threadpool alone, since, 99.9% of the time, it knows best :)
All that said, it's ok to lower a thread's priority if the task involves a long computation. This won't affect other processes.
Increasing priority, however, should only be done for tasks that need to react quickly, and have a short execution time, because this can negatively affect other processes.