1. 项目概述为什么我们需要一个自己的C日志系统在C项目里摸爬滚打十几年我见过太多因为日志问题而导致的“午夜惊魂”。想象一下线上服务半夜突然崩溃你被紧急电话叫醒登录服务器一看日志文件要么空空如也要么被海量的调试信息淹没关键的错误踪迹像泥牛入海无处可寻。这种时候一个设计良好、稳定可靠的日志系统就是你的“救命稻草”。它不仅仅是程序运行状态的记录仪更是你理解程序行为、定位线上问题、分析性能瓶颈的“黑匣子”。市面上成熟的C日志库很多比如性能怪兽spdlog、功能强大的log4cplus、以及来自Google的glog。它们各有千秋直接拿来用当然省事。但为什么我还要建议你至少亲手实现一个简易的日志系统呢这就像学开车你当然可以直接开自动挡但了解手动挡的离合器、变速箱是如何工作的能让你在车子出现异常时心里更有底。自己动手实现一遍你会对日志的异步刷盘、日志分级、线程安全、性能开销这些核心概念有刻骨铭心的理解。当你再去使用或选型第三方库时你就能一眼看穿它的设计优劣知道它是否真的适合你的项目场景。这个教程就是带你从零开始搭建一个具备生产环境可用性的C日志系统。我们不追求大而全而是聚焦于最核心、最实用的功能支持多级别日志DEBUG, INFO, WARN, ERROR, FATAL、支持同步/异步两种写入模式、线程安全、支持输出到控制台和文件、并能按日期或大小自动滚动日志文件。最终你会得到一个代码量在500行左右但设计精巧、五脏俱全的日志库它完全可以作为中小型C项目的日志基础组件。2. 核心设计思路与架构选型在动手写代码之前我们必须把设计思路理清楚。一个日志系统的核心任务很简单接收一条消息按照既定格式包含时间、级别、线程ID、文件名行号等把它写到指定的地方控制台或文件。但要把这件事做得高效、可靠、易用就需要仔细考量几个关键设计点。2.1 日志前端与后端分离生产者-消费者模型这是现代高性能日志库的通用设计模式。我们把日志系统分为两部分前端 (Frontend) 供用户调用的API接口如LOG_INFO(“msg”)。它的职责是尽可能快地接收日志消息进行初步格式化如添加时间戳、级别标签然后将格式化后的日志字符串放入一个缓冲区队列。前端执行过程必须非常轻量不能阻塞业务线程。后端 (Backend) 一个或多个后台工作线程。它们从缓冲区队列中取出日志消息执行实际的I/O操作比如写入文件或打印到控制台。I/O操作尤其是文件写入相对较慢由独立的后台线程处理可以避免阻塞前端业务逻辑。这种分离实现了异步日志。对于前端业务线程来说调用日志接口的成本几乎就是一次内存拷贝和一次队列插入速度极快。而后端线程可以专心处理慢速的I/O即使文件写入偶尔卡顿也不会影响程序主流程。在实现上我们用一个线程安全的阻塞队列 (Blocking Queue)来连接前端和后端。2.2 日志级别管理编译期与运行期的权衡日志级别用于控制日志的输出粒度。常见的级别有TRACE, DEBUG, INFO, WARN, ERROR, FATAL。级别管理涉及两个决策级别过滤发生在何时有两种策略编译期过滤 通过宏定义在编译时就将低于某个级别的日志语句完全移除。例如如果定义LOG_LEVELINFO那么所有LOG_DEBUG的调用在预处理后就直接消失了。优点是零运行时开销缺点是级别无法动态调整需要重新编译。运行期过滤 在运行时判断日志级别。每条日志语句都会执行但在生成日志字符串前会检查当前级别如果低于输出级别则直接返回。优点是灵活可以运行时动态调整日志级别比如通过信号或配置文件缺点是每条日志语句都有一次条件判断的开销。在我们的实现中为了兼顾性能和灵活性可以采用混合策略。对于性能极其敏感的路径可以使用编译期过滤的宏同时提供运行时可配置的级别过滤作为默认行为。级别如何表示用一个枚举类 (enum class Level) 是最清晰安全的方式。2.3 输出目标与格式定制策略模式的应用日志可能输出到多个地方标准输出 (stdout/stderr)、单个文件、按日期滚动的文件、甚至网络Socket。一个好的设计应该支持轻松添加新的输出目标。这里很适合使用策略模式 (Strategy Pattern)。我们可以定义一个抽象的Sink槽基类它只有一个纯虚函数void log(const std::string formatted_message)。然后派生出StdoutSink,FileSink,RotatingFileSink等具体实现。日志器 (Logger) 对象内部持有一个Sink的列表写日志时遍历所有Sink即可。这样要增加一个输出到UDP的功能只需新写一个UdpSink类。日志格式同样需要可定制。一个典型的格式可能是[2023-10-27 14:30:25.678] [INFO] [thread_id: 1234] [file:main.cpp:50] Your log message here。我们可以设计一个Formatter类使用类似printf的格式化字符串语法如%Y-%m-%d %H:%M:%S表示时间来灵活定义输出格式。2.4 线程安全锁的选择与无锁队列的诱惑日志系统注定是多线程共享的。多个业务线程会同时调用LOG_INFO。因此前端的日志消息入队操作必须是线程安全的。最简单的办法是使用std::mutex保护队列。但在高并发场景下锁竞争可能成为瓶颈。更高级的方案是使用无锁队列 (Lock-free Queue)。C11 的std::atomic配合精心设计的算法可以实现一个多生产者-单消费者 (MPSC) 的无锁队列这能极大提升高并发下的日志吞吐量。不过无锁队列实现复杂容易出错。作为教程我们先从带锁的队列实现开始确保正确性后续可以将其替换为无锁实现作为性能优化选项。注意 对于文件写入的后端线程我们通常设计为单消费者。这样即使前端是多生产者后端也只有一个线程在操作文件避免了多线程写文件需要额外同步的麻烦也保证了日志文件内消息的顺序性虽然时间戳可能因为线程调度有微小交错。2.5 性能与资源考量避免动态内存分配日志调用可能非常频繁频繁的std::string构造和析构动态内存分配会成为性能杀手。常见的优化手段包括使用栈上缓冲区 在格式化日志时优先使用固定大小的栈上字符数组 (char buf[1024])配合snprintf进行格式化。只有当消息超长时才退回到动态分配。内存池 为日志消息对象或缓冲区设计一个简单的内存池复用内存块减少系统调用malloc/free的次数。时间戳缓存 获取系统时间如std::chrono::system_clock::now()也有开销。可以启动一个后台线程每毫秒或每10毫秒获取一次当前时间并缓存起来供前端日志调用使用这样大多数日志调用获取时间戳几乎无成本。当然这会牺牲一点时间精度毫秒级对于大多数应用完全可以接受。基于以上思路我们整个日志系统的核心架构图在脑海中如下用户通过宏或接口调用日志前端 - 前端在栈上格式化日志字符串 - 将字符串拷贝或移动到堆上的日志消息对象 - 将该对象指针推入线程安全的阻塞队列 - 后端线程循环从队列取出消息 - 调用每个注册的Sink进行输出如写文件。3. 核心模块实现与代码解析接下来我们进入具体的代码实现环节。我会分模块讲解关键代码并解释背后的设计决策。3.1 基础类型与常量定义 (log_level.h)首先定义日志级别和少量常量。// log_level.h #pragma once #include string #include array namespace mylog { // 日志级别枚举使用 enum class 避免污染命名空间且类型安全 enum class LogLevel : int { TRACE 0, DEBUG, INFO, WARN, ERROR, FATAL, OFF // 用于关闭所有日志 }; // 将级别转换为字符串便于输出 constexpr std::arrayconst char*, 7 LevelToString { TRACE, DEBUG, INFO, WARN, ERROR, FATAL, OFF }; // 全局默认日志级别可以在初始化时修改 extern LogLevel g_default_level; // 判断一条给定级别的日志是否应该被记录与当前级别比较 bool ShouldLog(LogLevel level); } // namespace mylogextern声明的全局变量在对应的.cpp文件中定义。ShouldLog函数实现运行期级别过滤。3.2 日志事件与格式化 (log_event.h,log_event.cpp)LogEvent类封装一条日志的所有元信息。// log_event.h #pragma once #include log_level.h #include string #include memory #include chrono namespace mylog { class LogEvent { public: using TimePoint std::chrono::system_clock::time_point; LogEvent(LogLevel level, const char* file, int line, const char* func, std::string message); LogLevel GetLevel() const { return level_; } const std::string GetMessage() const { return message_; } const TimePoint GetTime() const { return time_; } const char* GetFile() const { return file_; } int GetLine() const { return line_; } const char* GetFunc() const { return func_; } // 获取当前线程ID缓存起来避免每次调用系统调用 uint64_t GetThreadId() const; // 将时间格式化为字符串 std::string FormatTime(const char* fmt %Y-%m-%d %H:%M:%S) const; private: LogLevel level_; TimePoint time_; // 日志创建时间点 const char* file_; // 文件名使用 const char* 避免拷贝 int line_; // 行号 const char* func_; // 函数名 std::string message_; // 日志正文 }; } // namespace mylog在构造函数中我们捕获了日志的瞬间快照级别、时间、源代码位置和消息。注意file_和func_我们存储的是const char*因为它们通常是字符串字面量生命周期与程序一致直接存储指针避免了std::string的拷贝开销。message_使用移动语义传入减少一次拷贝。格式化是另一个核心。我们可以实现一个独立的Formatter类但为了简单先在LogEvent里提供一个ToString()方法按照固定格式生成字符串。// log_event.cpp 部分实现 std::string LogEvent::ToString() const { // 预估一个初始大小减少string重分配 std::string formatted; formatted.reserve(256); // 格式化时间 formatted.append(FormatTime()); formatted.append( ); // 添加级别 formatted.append([); formatted.append(LevelToString[static_castint(level_)]); formatted.append(] ); // 添加线程ID formatted.append([thread:); formatted.append(std::to_string(GetThreadId())); formatted.append(] ); // 添加源代码位置通常只在DEBUG级别输出这里作为示例 formatted.append([); formatted.append(file_); formatted.append(:); formatted.append(std::to_string(line_)); formatted.append(] ); // 添加日志正文 formatted.append(message_); formatted.append(\n); return formatted; }实操心得 这里使用reserve预分配内存是一个小优化。在性能测试中对于大量短日志频繁的内存分配/释放会显著影响性能。根据你日志的平均长度选择一个合理的预估值如256或512字节能提升不少性能。3.3 输出目标Sink的实现 (sink.h,sink.cpp)定义Sink接口和几个具体实现。// sink.h #pragma once #include string #include memory #include fstream #include mutex namespace mylog { // 抽象的Sink接口 class Sink { public: virtual ~Sink() default; virtual void Log(const std::string formatted_message) 0; virtual void Flush() 0; // 刷新缓冲区确保日志落地 }; // 输出到标准输出通常是控制台 class StdoutSink : public Sink { public: void Log(const std::string formatted_message) override; void Flush() override; }; // 输出到单个文件 class FileSink : public Sink { public: explicit FileSink(const std::string filepath); ~FileSink(); void Log(const std::string formatted_message) override; void Flush() override; private: std::ofstream file_stream_; std::mutex mutex_; // 文件流本身不是线程安全的需要加锁 }; // 按日期滚动的文件Sink例如每天生成一个新文件 class RotatingFileSinkByDate : public Sink { public: RotatingFileSinkByDate(const std::string base_name, const std::string ext .log); void Log(const std::string formatted_message) override; void Flush() override; private: std::string GetCurrentDateFileName() const; void RotateIfNeeded(); // 检查是否需要滚动例如日期变更 std::string base_name_; std::string ext_; std::string current_date_; std::unique_ptrFileSink current_file_sink_; std::mutex mutex_; }; } // namespace mylogFileSink的实现需要注意线程安全因为多个后端线程虽然我们通常只有一个或者Sink被多个Logger共享时可能会同时调用Log。简单的做法是用一个std::mutex保护file_stream_的写操作。RotatingFileSinkByDate的逻辑是每次写日志前检查当前日期是否与current_date_相同如果不同说明到了新的一天就关闭旧文件用新的日期创建新文件。注意事项 文件I/O是性能瓶颈。std::ofstream默认是有缓冲的这很好减少了系统调用次数。但这也意味着如果程序崩溃缓冲区中未写入磁盘的日志可能会丢失。我们的Flush方法就是用来强制刷盘的。在日志级别为FATAL或者程序正常关闭时应该调用所有Sink的Flush()方法。3.4 线程安全的阻塞队列 (blocking_queue.h)这是连接前端和后端的桥梁。我们实现一个模板化的阻塞队列。// blocking_queue.h #pragma once #include queue #include mutex #include condition_variable #include chrono namespace mylog { templatetypename T class BlockingQueue { public: using MutexLockGuard std::lock_guardstd::mutex; using UniqueLock std::unique_lockstd::mutex; BlockingQueue(size_t max_size 1000) : max_size_(max_size) {} // 入队如果队列满则阻塞 void Push(const T item) { UniqueLock lock(mutex_); not_full_.wait(lock, [this]() { return queue_.size() max_size_; }); queue_.push(item); not_empty_.notify_one(); } // 入队移动语义版本 void Push(T item) { UniqueLock lock(mutex_); not_full_.wait(lock, [this]() { return queue_.size() max_size_; }); queue_.push(std::move(item)); not_empty_.notify_one(); } // 出队如果队列空则阻塞 T Pop() { UniqueLock lock(mutex_); not_empty_.wait(lock, [this]() { return !queue_.empty(); }); T item std::move(queue_.front()); queue_.pop(); not_full_.notify_one(); return item; } // 尝试出队等待一段时间超时返回false bool TryPopFor(T item, std::chrono::milliseconds timeout) { UniqueLock lock(mutex_); if (!not_empty_.wait_for(lock, timeout, [this]() { return !queue_.empty(); })) { return false; // 超时 } item std::move(queue_.front()); queue_.pop(); not_full_.notify_one(); return true; } size_t Size() const { MutexLockGuard lock(mutex_); return queue_.size(); } bool Empty() const { MutexLockGuard lock(mutex_); return queue_.empty(); } private: mutable std::mutex mutex_; std::condition_variable not_empty_; std::condition_variable not_full_; std::queueT queue_; size_t max_size_; }; } // namespace mylog这个队列是经典的生产者-消费者模型实现。使用std::condition_variable让线程在队列空或满时等待避免忙等待消耗CPU。max_size_是一个重要的安全阀防止生产者速度远大于消费者时导致内存无限增长。当队列满时生产者线程会阻塞在Push操作上这会对业务线程产生背压 (back pressure)虽然会影响业务但避免了内存耗尽程序崩溃。你可以根据应用的内存情况调整这个值。3.5 异步日志器核心 (async_logger.h,async_logger.cpp)这是最复杂的部分它封装了前端API和后端线程。// async_logger.h #pragma once #include log_level.h #include log_event.h #include sink.h #include blocking_queue.h #include atomic #include thread #include vector #include memory namespace mylog { class AsyncLogger { public: AsyncLogger(LogLevel level LogLevel::INFO, std::vectorstd::shared_ptrSink sinks {}); ~AsyncLogger(); // 禁止拷贝和移动 AsyncLogger(const AsyncLogger) delete; AsyncLogger operator(const AsyncLogger) delete; void Log(LogLevel level, const char* file, int line, const char* func, std::string message); // 添加一个输出目标 void AddSink(std::shared_ptrSink sink); // 设置日志级别 void SetLevel(LogLevel level) { level_.store(level, std::memory_order_relaxed); } // 停止日志线程刷新所有缓冲日志 void Stop(); private: void BackendThreadFunc(); // 后端线程函数 std::atomicLogLevel level_; std::vectorstd::shared_ptrSink sinks_; BlockingQueuestd::unique_ptrLogEvent queue_; std::thread backend_thread_; std::atomicbool running_{false}; std::mutex sinks_mutex_; // 保护sinks_的动态增删 }; } // namespace mylog在构造函数中我们启动后端线程。在析构函数中我们调用Stop()来优雅停止线程。// async_logger.cpp 关键部分 AsyncLogger::AsyncLogger(LogLevel level, std::vectorstd::shared_ptrSink sinks) : level_(level), sinks_(std::move(sinks)), running_(true) { // 如果没有提供sink默认添加一个StdoutSink if (sinks_.empty()) { sinks_.push_back(std::make_sharedStdoutSink()); } backend_thread_ std::thread(AsyncLogger::BackendThreadFunc, this); } AsyncLogger::~AsyncLogger() { Stop(); } void AsyncLogger::Log(LogLevel level, const char* file, int line, const char* func, std::string message) { // 运行期级别过滤 if (static_castint(level) static_castint(level_.load(std::memory_order_relaxed))) { return; } // 创建日志事件使用移动语义 auto event std::make_uniqueLogEvent(level, file, line, func, std::move(message)); // 尝试非阻塞入队如果队列满则丢弃这条日志避免阻塞业务线程 // 这里也可以选择阻塞入队取决于你对可靠性和性能的权衡 if (queue_.Size() queue_.max_size()) { // 假设BlockingQueue暴露了max_size queue_.Push(std::move(event)); } else { // 队列满了可以输出到stderr或丢弃。生产环境可能需要更复杂的策略。 // fprintf(stderr, Log queue is full, dropping message: %s\n, message.c_str()); } } void AsyncLogger::BackendThreadFunc() { while (running_ || !queue_.Empty()) { // 即使stopping也要清空队列 std::unique_ptrLogEvent event; // 等待最多1秒以便定期检查running_状态和刷新缓冲区 if (queue_.TryPopFor(event, std::chrono::seconds(1))) { std::string formatted event-ToString(); std::lock_guardstd::mutex lock(sinks_mutex_); for (auto sink : sinks_) { sink-Log(formatted); } } else { // 超时刷新所有sink确保日志落地 std::lock_guardstd::mutex lock(sinks_mutex_); for (auto sink : sinks_) { sink-Flush(); } } } // 线程结束前最后刷新一次 std::lock_guardstd::mutex lock(sinks_mutex_); for (auto sink : sinks_) { sink-Flush(); } } void AsyncLogger::Stop() { running_.store(false, std::memory_order_relaxed); if (backend_thread_.joinable()) { backend_thread_.join(); } }关键点解析前端Log方法 先做级别过滤。然后创建LogEvent。入队操作这里采用了“队列满则丢弃”的策略。这是一个重要的设计抉择。在超高并发下如果队列满就阻塞Push可能导致业务线程卡住影响服务。丢弃日志虽然损失了信息但保证了业务主链路的可用性。另一种策略是分配一个“应急缓冲区”或者同步输出到stderr。你需要根据业务对日志完整性的要求来选择。后端线程BackendThreadFunc 这是日志系统的“心脏”。它在一个循环中尝试从队列取日志。使用TryPopFor带有超时有两个好处一是可以在超时时检查running_标志及时退出二是可以定期这里设定1秒调用Flush()即使没有新日志也能确保缓冲区里的内容写入磁盘避免日志丢失窗口期太长。停止序列Stop()方法设置running_为false然后等待 (join) 后端线程结束。后端线程在退出前会持续处理队列中剩余的日志并最后执行一次Flush。这确保了在程序关闭时所有已生成的日志都不会丢失。Sink管理 用sinks_mutex_保护sinks_容器。因为理论上可以在运行时动态添加或删除Sink虽然不常见所以需要锁。在日志输出的关键路径上后端线程循环内加锁是一个性能敏感点。如果Sink列表固定可以在初始化后就不变那么这里可以不用锁或者用std::shared_ptr的原子操作来管理。3.6 用户友好的宏接口 (log_macros.h)最后我们提供一组宏让用户使用起来像printf一样方便并且能自动捕获__FILE__,__LINE__,__func__这些宏。// log_macros.h #pragma once #include async_logger.h #include sstream // 声明一个全局的日志器实例单例模式简化版实际项目可能需要更优雅的单例 extern mylog::AsyncLogger g_logger; #define LOG_TRACE(msg) \ do { \ if (static_castint(mylog::LogLevel::TRACE) static_castint(g_logger.GetLevel())) { \ std::ostringstream oss; \ oss msg; \ g_logger.Log(mylog::LogLevel::TRACE, __FILE__, __LINE__, __func__, oss.str()); \ } \ } while(0) #define LOG_DEBUG(msg) \ do { ... } while(0) // 类似实现 #define LOG_INFO(msg) \ do { ... } while(0) #define LOG_WARN(msg) \ do { ... } while(0) #define LOG_ERROR(msg) \ do { ... } while(0) #define LOG_FATAL(msg) \ do { \ std::ostringstream oss; \ oss msg; \ g_logger.Log(mylog::LogLevel::FATAL, __FILE__, __LINE__, __func__, oss.str()); \ g_logger.FlushAll(); // FATAL级别立即刷新 \ std::abort(); // FATAL通常意味着不可恢复错误终止程序 \ } while(0)宏使用do { ... } while(0)包裹这是一个C/C的惯用法能确保宏在被展开后无论后面怎么跟分号其行为都像一个独立的语句避免语法错误和作用域问题。std::ostringstream用于处理流式输出让LOG_INFO(“value is: “ value)这样的语法成为可能。注意即使日志级别过滤不通过oss msg这行代码依然会执行因为宏展开是在编译期运行期过滤在Log函数内。如果msg的构造有副作用或成本很高这就是浪费。更极致的优化是使用编译期过滤宏这需要更复杂的宏技巧比如通过全局日志级别常量在预处理阶段判断这里为了清晰我们采用运行期过滤。4. 集成、使用与性能调优实战4.1 如何集成到你的项目获取代码 将上述头文件和源文件放入你项目的某个目录例如third_party/mylog/。初始化 在main函数开始处初始化全局日志器g_logger。#include “mylog/log_macros.h” #include “mylog/sink.h” mylog::AsyncLogger g_logger(mylog::LogLevel::INFO); int main() { // 添加一个按日期滚动的文件Sink auto file_sink std::make_sharedmylog::RotatingFileSinkByDate(“./logs/myapp”); g_logger.AddSink(file_sink); // 也可以同时输出到控制台 // g_logger.AddSink(std::make_sharedmylog::StdoutSink()); LOG_INFO(“Application started.”); // ... 你的业务逻辑 int err do_something(); if (err) { LOG_ERROR(“do_something failed with code: “ err); } LOG_INFO(“Application exiting.”); // 析构时g_logger的析构函数会调用Stop()确保日志写完 return 0; }编译 确保你的编译命令包含了mylog目录并链接了 pthread 库因为用了std::thread。例如对于gccg -stdc11 -I./third_party main.cpp mylog/*.cpp -pthread -o myapp。4.2 性能测试与调优技巧实现完成后我们需要验证它的性能。一个简单的性能测试是开多个线程每个线程循环写大量日志统计总耗时和吞吐量条/秒。测试中可能发现的问题及优化方向队列争用激烈 如果前端线程非常多比如上百个共用一个带锁的队列锁竞争会成为瓶颈。优化方案每个线程一个缓冲区 (Thread Local Buffer) 每个业务线程将自己的日志先写入线程局部的内存缓冲区比如一个std::vectorstd::string当缓冲区满或定时如每100ms时一次性将整个缓冲区提交给全局队列。这大大减少了入队次数和锁竞争。这就是很多高性能日志库如spdlog的异步模式采用的“批量提交”策略。换用无锁队列 如前所述实现一个MPSC无锁队列可以消除锁开销。格式化耗时std::ostringstream和std::to_string虽然方便但性能并非最优。对于性能要求极高的场景可以考虑使用fmt库 这是现代C高性能格式化的首选spdlog就集成了它。它比sprintf更安全比std::stringstream快得多。手动格式化数字 自己写整数转字符串的函数避免std::to_string的局部静态缓冲区等开销。时间戳获取std::chrono::system_clock::now()调用也有成本。优化方案缓存时间戳 如前所述启动一个高精度定时器线程每毫秒获取一次时间并存入一个全局原子变量。前端日志调用直接读取这个缓存的时间。这会导致日志时间有最多1毫秒的误差但对绝大多数应用是可接受的。文件写入性能设置更大的文件缓冲区std::ofstream可以设置内部缓冲区大小 (rdbuf()-pubsetbuf)。使用fwrite/write 直接使用C库或系统调用并配合O_APPEND标志有时比std::ofstream更快但牺牲了RAII和异常安全。考虑使用内存映射文件 (mmap) 对于超大日志量这是一个高级优化方向。4.3 与成熟日志库的对比与选择自己实现的这个日志系统具备了核心功能但在生态、高级特性、极端性能优化和跨平台兼容性上与spdlog、glog等成熟库仍有差距。spdlog 如果你的项目追求极致的性能并且喜欢现代C的API风格spdlog是首选。它的异步模式性能非常高格式库强大Sink种类丰富支持syslog, UDP等社区活跃。我们实现的很多思想异步、前端后端分离在spdlog里都有更精炼的实现。glog 如果你在Google的生态内或者需要一些非常特定的功能如基于严重级别的信号处理、失败时生成堆栈跟踪glog很合适。它的日志文件命名和滚动策略也很成熟。但它的API风格比较老派性能通常不如spdlog。log4cplus 如果你需要极其复杂和灵活的日志配置通过XML/属性文件或者你的团队从Java的log4j转过来log4cplus会很熟悉。它的功能最全但相应地体积和复杂度也最高性能可能不是最优。那么什么时候用自己实现的这个轮子呢学习目的 深刻理解日志系统原理这是最重要的。嵌入式或资源极度受限环境 你需要一个极度轻量、无外部依赖、可完全掌控的解决方案。有非常特殊的定制化需求 现有库难以满足且修改起来比自己写还麻烦。对于大多数应用级项目我建议直接使用spdlog。在充分理解了我们自己实现的这个系统之后你再去看spdlog的源码会更有收获也能更好地使用和配置它。5. 常见问题排查与实战心得在实际使用自己或第三方的日志系统时你肯定会遇到一些“坑”。这里记录几个我踩过的以及对应的解决思路。5.1 日志丢失或不完整现象 程序崩溃后最后几条关键日志没写到文件里。原因 日志还停留在应用层的缓冲区或操作系统的页面缓存中未来得及刷盘。解决确保在LOG_FATAL或程序收到终止信号如SIGTERM,SIGINT时调用所有Sink的Flush()方法。考虑设置定期自动刷盘就像我们后端线程每1秒做的那样。对于文件Sink可以尝试设置std::ofstream为无缓冲 (file_stream_.rdbuf()-pubsetbuf(nullptr, 0))但会严重降低性能慎用。5.2 多线程日志顺序错乱现象 两个线程的日志内容在文件里交织在一起比如[Thread A log 1][Thread B log 1][Thread A log 2]变成了[Thread A log [Thread B log 1]1][Thread A log 2]。原因 这不是我们系统的问题因为我们后端是单线程消费保证了每条完整日志的写入是原子的。这个问题通常出现在每条日志分多次写入且写入之间线程被切换。例如如果你用fprintf连续写时间戳和消息中间没有锁就可能被打断。解决 确保每条日志的格式化字符串在内存中先组合完成然后一次性写入。我们的LogEvent::ToString()和Sink::Log(const std::string)正是这样做的。如果你自己实现Sink也要遵循这个原则。5.3 性能突然下降现象 平时好好的某段时间日志吞吐量急剧下降程序变慢。排查检查磁盘IO 用iostat等工具看磁盘是否已满或者是否正进行其他高IO操作如备份。日志写入受磁盘速度制约。检查队列长度 在日志器中增加一个获取当前队列大小的接口。如果队列长期处于满的状态说明后端写入速度跟不上前端产生速度。可能需要优化后端换SSD或者调整前端的日志级别减少日志量。检查锁竞争 如果是我们带锁的队列实现在高并发下可能成为瓶颈。可以用性能分析工具如perf,vtune查看mutex的争用情况。5.4 日志文件无限增长现象 磁盘被日志文件占满。解决 实现日志滚动。我们的RotatingFileSinkByDate是按天滚动。你还可以实现按文件大小滚动如达到100MB就新建一个文件或者按两者结合。同时一定要实现日志清理策略比如只保留最近7天的日志或总大小超过10GB后删除最旧的文件。这个清理逻辑可以放在Sink里也可以用一个独立的定时任务。5.5 一个容易被忽略的“坑”静态初始化顺序现象 在全局或静态对象的构造函数中打日志程序可能崩溃或日志器未初始化。原因 C不同编译单元中全局对象的初始化顺序是未定义的。如果你的全局日志器g_logger在另一个全局对象之后初始化那么那个对象的构造函数中使用的g_logger可能还未构造。解决 使用“局部静态变量”模式的单例来获取日志器实例利用C11的Magic Static特性保证线程安全的初始化。AsyncLogger GetGlobalLogger() { static AsyncLogger logger(LogLevel::INFO); return logger; }这样第一次调用GetGlobalLogger()时logger才会被构造。确保在任何全局对象构造函数中通过调用这个函数来获取日志器而不是直接使用一个全局变量。亲手实现一遍这个日志系统虽然只有几百行代码但其中涉及的多线程同步、资源管理、性能权衡、API设计等知识点几乎涵盖了C中级工程师需要掌握的大部分核心技能。当你再遇到日志相关的问题时你不再是盲目地搜索和试错而是能清晰地分析出问题的可能根源并给出有效的解决方案。这才是这个“轮子”最大的价值。