线程优先级不是执行顺序的保证，而是调度器的“偏好提示”
设置
Thread.Priority = ThreadPriority.Highest并不会让线程“一定先跑完”，它只是告诉 Windows 调度器：“如果当前有多个就绪线程，**请优先考虑这个**”。实际是否能立刻执行，取决于：是否有更高优先级的系统线程（如 GUI 响应、网络中断处理）、当前 CPU 是否空闲、该线程是否正被阻塞（比如在
WaitHandle.WaitOne()或
lock中）。 优先级只在“就绪态线程之间竞争 CPU 时间片”时起作用 一旦高优先级线程进入等待状态（如
Thread.Sleep(10)、I/O、锁争用），低优先级线程立刻可能获得调度机会 Windows 会动态提升前台进程 UI 线程的优先级（称为“前台 boost”），你手动设为
Highest可能反而被系统覆盖或抵消
ThreadPriority 枚举值的实际效果差异很小
ThreadPriority的五个值：
Lowest、
BelowNormal、
Normal、
AboveNormal、
Highest，**并不是等距的权重值**，而是映射到 Windows 底层的 32 级线程优先级中的几个固定档位（例如
Normal对应进程基础优先级 +0，
Highest对应 +2）。这意味着： 在大多数普通应用中，
AboveNormal和
Highest的行为几乎没区别——除非系统极度繁忙且存在大量同进程内线程竞争
Lowest不等于“永不执行”，只是会被排到最后；但若其他线程全在 sleep/block，它照样能跑 跨进程比较无意义：你的
Highest线程仍可能输给系统服务进程里的
Normal线程
什么时候真该调优先级？别乱设
真正值得干预优先级的场景极少，且通常只出现在特定架构中：
UI 线程保响应：主线程（尤其 WinForms/WPF）保持Normal即可，系统已自动 boost；手动设
AboveNormal可能引发后台任务饿死 实时数据采集线程：传感器读取、音频采样等对延迟敏感的任务，可设
AboveNormal，但必须配合无锁设计和短耗时逻辑 后台日志/归档等非关键任务：明确设为
BelowNormal或
Lowest，避免拖慢主线程 绝对不要：在
async/await代码里调
Thread.Priority（因为 await 后可能切到任意线程池线程，设置无效）；也不要在
Task.Run()创建的委托里改——线程池线程的优先级由系统管理，修改会被忽略
常见错误现象与验证方式
你以为设了
Highest就该“飞快执行”，结果发现输出顺序还是乱的？这不是 bug，是预期行为。验证是否生效，不能靠 Console.WriteLine 次序（受缓冲、锁竞争干扰），而要看： 用 Windows 性能监视器（PerfMon）添加计数器：
Thread(*)\Priority Current，确认目标线程显示值是否匹配（注意括号里要填真实线程名或 ID） 观察 CPU 占用分布：用 Process Explorer 查看线程列表，列中
Priority列是否更新（右键 → Properties → Threads tab） 典型误操作：
thread.Start()后立即设
Priority—— 此时线程可能已启动并进入等待队列，优先级变更不生效；应在
Start()前设置
Thread worker = new Thread(() =>
{
for (int i = 0; i < 1000000; i++)
DoWork();
});
worker.Priority = ThreadPriority.AboveNormal; // ✅ 必须在 Start 前
worker.Start();
线程优先级是个窄通道工具——它解决不了同步问题、掩盖不了设计缺陷、也替代不了正确使用 Task、
Channel或锁机制。多数时候，与其纠结
ThreadPriority，不如检查是不是用了太多阻塞调用，或者有没有把本该异步的 I/O 写成了同步阻塞。
