windows线程优先级需权限且仅限同进程，linux需策略配合参数，std::thread须用原生api设置，实际性能提升有限，优化资源争用更有效。
Windows 下用 SetThreadPriority 设置线程优先级
Windows 提供了明确的 API 控制线程调度优先级，但必须注意：它只对当前线程或同进程内其他线程有效，且需有对应权限（如 SE_INC_BASE_PRIORITY_PRIVILEGE 才能设为高于 NORMAL）。
常见错误是调用后没检查返回值，导致误以为设置成功：
if (!SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_HIGHEST)) {
DWORD err = GetLastError(); // 实际常为 ERROR_ACCESS_DENIED
}
-
THREAD_PRIORITY_IDLE到THREAD_PRIORITY_TIME_CRITICAL是相对进程基础优先级的偏移，不是绝对值 - 主线程默认是
NORMAL，子线程继承创建者线程的优先级，不是自动重置为 NORMAL - 频繁切换优先级可能引发调度抖动，尤其在高负载时反而降低吞吐量
Linux 下用 pthread_setschedparam 配合调度策略
POSIX 线程不直接暴露“优先级”概念，而是通过调度策略（SCHED_FIFO、SCHED_RR、SCHED_OTHER）和参数协同控制。普通用户只能对 SCHED_OTHER 使用 nice 值（-20 到 +19），而实时策略需要 CAP_SYS_NICE 权限。
典型误用是只改策略不设参数，或忽略 pthread_attr_setinheritsched 导致子线程不继承属性：
立即学习“C++免费学习笔记（深入）”；
struct sched_param param; param.sched_priority = 50; // SCHED_FIFO/SCHED_RR 下才生效 pthread_setschedparam(thread, SCHED_FIFO, ¶m);
-
SCHED_OTHER下sched_priority必须为 0，否则调用失败 - 实时策略线程若不主动让出 CPU（如无 sleep / wait / block），会饿死其他线程
- 容器环境（如 Docker）中，
RLIMIT_RTPRIO可能限制实时调度能力，getrlimit(RLIMIT_RTPRIO, &rlim)应先检查
C++11 std::thread 无法直接设优先级
std::thread 是跨平台封装，标准库不提供优先级接口。想控制，必须在创建后立即获取原生句柄再调系统 API：
std::thread t([]{
// 工作函数
});
#ifdef _WIN32
SetThreadPriority(t.native_handle(), THREAD_PRIORITY_ABOVE_NORMAL);
#elif defined(__linux__)
pthread_setschedparam(t.native_handle(), SCHED_RR, ¶m);
#endif
- 必须在
t.join()或t.detach()前完成设置，否则native_handle()可能失效或未定义 - macOS 不支持
pthread_setschedparam的实时策略，仅允许SCHED_OTHER和setpriority() - 某些嵌入式或硬实时系统（如 QNX）有更细粒度的调度类，C++ 标准线程完全不覆盖这些场景
优先级设置对多线程性能的实际影响很有限
真正影响性能的往往不是单个线程的“高低优先”，而是资源争用模式：锁竞争、缓存行冲突、内存带宽饱和、NUMA 跨节点访问。盲目提高某线程优先级，可能加剧抖动甚至触发 OS 的饥饿保护机制（如 Linux 的 autogroup 调度）。
- 用
perf record -e sched:sched_switch观察线程实际调度延迟，比看优先级数字更有意义 - 高优先级线程若频繁做短时 I/O 或锁等待，调度器会快速降权，设置几乎无效
- 在 NUMA 架构上，绑定线程到特定 CPU（
pthread_setaffinity_np）通常比调优先级更能稳定延迟
优先级是微调手段，不是性能瓶颈的通用解药；多数情况下，优化数据结构局部性、减少同步粒度、避免虚假共享，收益远大于调整 THREAD_PRIORITY_HIGHEST。
