不能直接限制单个线程的CPU使用率百分比，操作系统不提供该粒度接口；可行方法是通过sleep_for控制循环节奏、绑定核心隔离缓存、或调低调度优先级间接实现目标占用效果。
不能直接限制单个线程的 CPU 使用率百分比，操作系统不提供该粒度的控制接口；真正可行的是通过主动让出时间片、绑定核心或调整调度优先级来间接达成目标占用效果。
用 std::this_thread::sleep_for 控制循环节奏
这是最常用、最可控的方式，适用于工作-休眠交替明确的任务（如采集、渲染主循环、状态轮询）。
- 原理是“做一点，停一会儿”，靠实测调整休眠时长来逼近目标占用率，比如想压到 40%，就让线程每秒忙 400ms + 休 600ms
- Windows 下
sleep_for(1ms)实际可能延迟 10–15ms，Linux 可接近 1ms，但别用sleep_for(1ns)或sleep_for(1us)—— 系统会向上取整，导致“假休眠真忙等” - 工作耗时必须实测：先注释掉 sleep，用
std::chrono::steady_clock测单次循环真实开销，再反推休眠值 - 示例：若单次处理平均耗时 2.3ms，目标 30% 占用，则建议
sleep_for(5ms)（因为 2.3 / (2.3 + 5) ≈ 32%），再微调
用 SetThreadAffinityMask 或 sched_setaffinity 隔离核心
这不是降占用，而是把线程钉死在某个逻辑核心上，防止它跨核迁移造成缓存失效，同时便于外部监控和资源配额管理。
- Windows 调用前必须用
GetCurrentThread()获取有效句柄，否则SetThreadAffinityMask返回 0 失败 - Linux 下
cpu_set_t必须先CPU_ZERO(&set)再CPU_SET(2, &set)，漏掉CPU_ZERO会导致未定义行为 - 绑定后若该核心被中断或高优进程霸占，你的线程仍会被频繁抢占，
top显示的 %CPU 可能虚高，不代表真实计算量 - 适合混部场景：比如一个服务进程里，把日志线程绑到 core 0，主业务线程绑到 cores 1–7，避免互相干扰
用 setpriority 或 SetThreadPriority 降低调度权重
让系统“不太想”调度你，本质是让出 CPU 时间片，但无法精确对应到百分比数字，效果受整体负载影响大。
立即学习“C++免费学习笔记（深入）”；
- Linux 上
setpriority(PRIO_PROCESS, 0, 10)把当前进程优先级调低（值越大越低），POSIX 里默认范围是 -20（最高）到 19（最低） - Windows 中
THREAD_PRIORITY_BELOW_NORMAL是安全下限，THREAD_PRIORITY_IDLE虽然更低，但可能导致 UI 响应卡顿（哪怕你程序没界面） - 慎与
sleep_for混用：低优先级 + 长休眠 = 唤醒延迟陡增，不适合需要准时触发的定时任务（如信号 handler、心跳包） - 适合后台型任务：归档压缩、离线日志分析、非实时数据聚合等对响应时间不敏感的场景
为什么不用 nanosleep 或 clock_nanosleep 替代 sleep_for
没必要手动切底层系统调用——C++ 标准库的 sleep_for 在 libstdc++ 和 libc++ 中已直接封装 nanosleep 或 clock_nanosleep，精度和行为基本一致。
-
nanosleep需要自己处理EINTR重试逻辑，sleep_for已内置处理，更安全 -
clock_nanosleep支持指定时钟源（如CLOCK_MONOTONIC），但sleep_for默认就用单调时钟，无额外收益 - 强行绕过标准库调用系统接口，反而增加可移植性风险和维护成本
真正难的不是选哪个函数，而是准确测量工作耗时、理解目标平台的调度粒度、并在绑定核心/调低优先级/插入休眠之间做权衡——这些环节一环错，占用率就失控。尤其在 NUMA 架构服务器上，亲和性配置错误带来的性能损失，远比多占几个百分点 CPU 更致命。
