std::this_thread::sleep_for在Linux上无法达到纳秒级精度，因内核调度粒度为1–15毫秒；真正逼近纳秒级需忙等待或timerfd+epoll，前者耗CPU，后者有syscall开销；实时内核可压至几十微秒，仍非纳秒级。
为什么 std::this_thread::sleep_for 在 Linux 上实际达不到纳秒级精度
因为 Linux 内核调度器本身不支持真正纳秒级休眠，std::chrono::nanoseconds(1) 传给 sleep_for 会被内核向上取整到至少 1–15 毫秒（取决于 HZ 和 CFS 调度粒度），实测中哪怕写 sleep_for(1ns)，返回时往往已过去几毫秒。这不是 C++ 标准库的 bug，而是系统限制。
真正能逼近纳秒级的只有两类方式：忙等待（busy-wait）或调用高精度定时器 + 信号（如 timerfd_create + epoll_wait），前者耗 CPU，后者需系统支持且有 syscall 开销。
- 普通桌面/服务器 Linux 默认调度周期通常为 1–10 ms，
nanosleep系统调用底层仍走内核定时器队列，无法绕过该粒度 -
std::this_thread::sleep_for底层在 glibc 中多数映射为nanosleep，所以精度瓶颈一致 - 实时内核（PREEMPT_RT）+
SCHED_FIFO进程可将延迟压到几十微秒，但依然不是纳秒级，且部署成本高
用 std::chrono::high_resolution_clock 做忙等待实现亚微秒级可控延迟
适用于对精度要求极高、且能接受单核满载的场景（如硬件同步、FPGA 触发、高频采样对齐）。核心思路是读取高精度时钟，循环空转直到目标时间到达。
注意：high_resolution_clock 在大多数平台（Linux/gcc、Windows/MSVC）下底层是 clock_gettime(CLOCK_MONOTONIC) 或 QueryPerformanceCounter，分辨率可达纳秒级，但读取本身有几十纳秒开销，需计入误差。
// 示例：等待恰好 5000 纳秒（5 微秒） auto start = std::chrono::high_resolution_clock::now(); auto target = start + std::chrono::nanoseconds(5000); while (std::chrono::high_resolution_clock::now()
- 必须用
high_resolution_clock，不能用steady_clock或system_clock—— 后两者在某些平台分辨率只有毫秒 - 循环体里避免任何函数调用、内存分配、分支预测失败操作，否则延迟不可控
- 在超线程开启的 CPU 上，同一物理核上的两个逻辑核互相干扰会导致抖动增大，建议绑核（
pthread_setaffinity_np）
用 timerfd_create 实现低开销、高精度的纳秒级等待（Linux only）
这是比 nanosleep 更优的系统级方案：内核维护独立定时器对象，通过文件描述符通知超时，配合 epoll_wait 可与其他 I/O 复用，无忙等待、无线程阻塞，精度由内核高精度定时器（hrtimer）保障，典型误差
注意：它不直接支持纳秒参数，但 itimerspec 的 tv_nsec 字段允许设到 999999999，只要总时长 ≥ 1ms，精度就远优于 nanosleep；若需
int tfd = timerfd_create(CLOCK_MONOTONIC, TFD_NONBLOCK);
struct itimerspec ts = {};
ts.it_value.tv_sec = 0;
ts.it_value.tv_nsec = 5000; // 5000 ns = 5 µs
timerfd_settime(tfd, 0, &ts, nullptr);
uint64_t expirations;
ssize_t s = read(tfd, &expirations, sizeof(expirations)); // 阻塞直到触发
close(tfd);
-
CLOCK_MONOTONIC是必须的，CLOCK_REALTIME可被系统时间调整影响，导致等待异常延长或跳过 -
TFD_NONBLOCK配合read是最简用法；若集成进事件循环，改用epoll_ctl注册tfd即可 - glibc 2.26+ 才完全支持
timerfd_create的纳秒级设置，旧版本会向下取整到毫秒
跨平台纳秒延迟封装要注意的三个硬伤
没有银弹。想写一个“一次编写、到处纳秒精度”的延迟函数，会撞上三堵墙：
- Windows 上
QueryPerformanceCounter分辨率虽高，但WaitForSingleObject或Sleep最小单位仍是 1–15 ms；唯一办法是 QueryPC + 忙等待，但不同 CPU 的RDTSC行为差异大（是否受频率缩放影响、是否乱序执行） - macOS 不提供
timerfd，mach_absolute_time可读高精度时间，但nanosleep和usleep同样受 mach 调度器限制，最低有效延迟约 10–30 µs - 所有平台的编译器优化都可能把忙等待循环整个优化掉（尤其未用
volatile或未访问易变内存），必须用asm volatile("" ::: "memory")或std::atomic_signal_fence防止重排
真正工程中，如果你需要稳定 ≤ 1 µs 的延迟，基本只能接受忙等待 + 绑核 + 实时优先级，并接受它吃满一个 CPU 核——精度和资源消耗在这里是强耦合的。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
