C++标准库的std::this_thread::sleep_for在Linux上实际最小可分辨延迟为1–15毫秒，远非纳秒级，因其底层依赖内核调度器tick机制（如CONFIG_HZ=250对应4ms一tick）和CFS调度延迟，传入纳秒值会被向上取整至最近调度粒度，导致休眠不可控、不可重复。
为什么 std::this_thread::sleep_for 在 Linux 上通常达不到纳秒级精度
直接说结论：C++ 标准库的 std::this_thread::sleep_for（底层依赖 clock_nanosleep 或 nanosleep）在绝大多数 Linux 发行版上，**实际最小可分辨延迟是 1–15 毫秒**，远非纳秒级。这不是代码写得不对，而是内核调度器的 tick 机制（如 CONFIG_HZ=250 → 4ms 一 tick）和 CFS 调度延迟共同决定的。即使你传入 1ns，系统也会向上取整到最近的可调度粒度，最终休眠时间不可控、不可重复。
用 std::chrono::high_resolution_clock 做忙等（busy-wait）实现亚微秒可控延迟
当真正需要纳秒/亚微秒级等待（比如硬件同步、实时采样触发、锁竞争优化），唯一可靠路径是「忙等 + 高精度计时器」。注意：这不是“睡眠”，而是让 CPU 循环检查时间戳，会占用一个核心。
关键点：
-
std::chrono::high_resolution_clock在 Linux x86_64 上通常映射为CLOCK_MONOTONIC（或CLOCK_MONOTONIC_RAW），其分辨率可达 ~1ns（取决于rdtsc或 TSC 稳定性） - 必须禁用编译器过度优化：对循环变量加
volatile或用asm volatile("" ::: "memory")内存屏障，否则整个循环可能被优化掉 - 起始时间必须用
.time_since_epoch().count()获取原始整数，避免浮点运算引入误差
clock_nanosleep(CLOCK_MONOTONIC_RAW, TIMER_ABSTIME, ...)
-
CLOCK_MONOTONIC_RAW比CLOCK_MONOTONIC更少受 NTP 调整干扰，更适合精确间隔 - 必须用
TIMER_ABSTIME模式，传入绝对时间点（不是相对值），避免因调度延迟导致二次累积误差 - 需手动处理
EINTR并重试，glibc 封装已帮你做了，裸 syscall 不会 - 仍受限于内核 timerfd 分辨率（通常 ≥ 1μs），纳秒级仍是理论值，实测抖动常达几百纳秒
struct timespec ts;
clock_gettime(CLOCK_MONOTONIC_RAW, &ts);
ts.tv_nsec += 1000; // 加 1μs；注意 tv_nsec 溢出处理（≥1e9 时进位）
if (ts.tv_nsec >= 1000000000) {
ts.tv_sec++;
ts.tv_nsec -= 1000000000;
}
clock_nanosleep(CLOCK_MONOTONIC_RAW, TIMER_ABSTIME, &ts, nullptr);
实际工程中怎么选：看场景，别迷信“纳秒”字面意义
所谓“纳秒级延迟”在用户态几乎无法稳定达成。真正该关心的是：你的延迟容忍度是多少？是否允许 CPU 占用？能否接受 jitter？是否运行在实时内核上？
- 硬件驱动 / FPGA 触发等硬实时场景 → 忙等 + RDTSC 或
__rdtscp()是主流做法，但需绑定 CPU 核心（pthread_setaffinity_np）并关闭频率调节（cpupower frequency-set -g performance） - 普通后台服务中“微调线程唤醒时机” → 用
std::this_thread::sleep_for+std::chrono::steady_clock足够，追求纳秒反而增加复杂度和功耗 - 测试测量类应用 → 忙等 +
CLOCK_MONOTONIC_RAW计时更可控，但务必在 real-time priority（sched_setscheduler）下运行，否则调度延迟直接吞掉精度
最常被忽略的一点：即使你代码里写了 100ns，现代 CPU 的指令执行时间、缓存未命中、TLB miss、中断响应都可能引入 >100ns 的不确定性 —— 纳秒级控制，本质是软硬协同的系统工程，不是单靠一个函数能解决的。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
