因为每次滚动都触发文件关闭、重命名、新建，磁盘i/o和系统调用开销大，高并发时fwrite可能阻塞数毫秒，且滚动期间其他线程写入易丢日志或触发ebadf错误。
为什么直接用 fopen + fclose 做日志滚动会卡住？
因为每次滚动都触发文件关闭 + 重命名 + 新建，磁盘 I/O 和系统调用开销大，尤其在高并发写入时，fwrite 可能阻塞数毫秒甚至更久。更糟的是，如果滚动期间有其他线程正在写，还可能丢日志或触发 EBADF 错误。
- 避免每条日志都检查滚动条件——改用「写前预判」：记录上次滚动时间 + 当前缓冲区剩余空间，仅当满足时间/大小阈值且缓冲区即将满时才触发滚动
- 滚动操作必须原子化：先
rename旧文件，再fopen(..., "wb")新文件，中间不能穿插写入；推荐用dup2替换 fd（Linux）或freopen（跨平台但需加锁） - 不要依赖
stat查文件大小来判断是否滚动——它本身是系统调用，且无法反映内核缓冲区未刷盘的数据量
std::ofstream 能否安全用于高频滚动？
不能直接用。默认构造的 std::ofstream 在析构或 close() 时会 flush + sync，而 sync_with_stdio(false) 对它无效；更关键的是，C++ 标准库流不提供底层 fd 访问接口，无法做 dup2 或 fsync 控制。
- 若坚持用
std::ofstream，必须自己管理生命周期：滚动前调用flush()，再用rdbuf()->pubsync()确保内核写入，最后close()；但仍有fclose阻塞风险 - 更稳妥的做法是封装
int fd，配合writev批量写、fsync按需刷盘，并用posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED)减少 page cache 占用 - 注意：Windows 上
_open/_write不支持writev，得用WriteFile+FILE_FLAG_NO_BUFFERING（要求对齐），兼容性成本高
如何避免多进程/多线程下滚动冲突？
单靠文件名时间戳不够——NTP 调整、虚拟机时钟漂移、进程启动延迟都可能导致两个进程生成相同时间戳文件，覆盖或报 EEXIST。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 滚动时用
link或rename原子操作：先写到临时名（如app.log.20240501-123456.tmp），再rename成目标名；失败则重试 + 退避 - 跨进程需额外同步：Linux 下可用
open(..., O_EXCL | O_CREAT)创建带进程 PID 的锁文件（如app.log.lock），滚动前lockf加锁，完成后unlink - 线程安全别只靠 mutex——写缓冲区和滚动标志位必须用
std::atomic（如std::atomic_bool rolling_in_progress{false}），否则可能一个线程刚判断完要滚动，另一个线程已开始写新文件
滚动后旧日志压缩该放在哪一步？
绝不能在滚动主路径里做 gzip —— 压缩是 CPU 密集型操作，会把写日志的延迟从微秒级拉到毫秒甚至百毫秒级。
- 滚动完成后，立刻 fork 子进程（Linux）或启动独立线程池处理压缩，父进程/主线程完全不等待
- 压缩目标文件名应含哈希后缀（如
app.log.20240501-123456.gz.b8f3a），避免多个压缩任务同时处理同一文件 - 注意磁盘空间水位：压缩前先
statvfs检查剩余空间，低于阈值（如 1GB）时跳过压缩并告警，防止因压缩失败导致日志堆积填满磁盘
真正难的不是滚动逻辑本身，而是滚动触发时机与写入路径的解耦程度——多数 crash 都发生在「以为滚动完了，其实还有线程正往旧 fd 写」这种竞态里。留好 fd 复制和 close 的顺序断点，比优化压缩算法重要得多。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
