学过C++后，写过和看过的C++代码还是比较有限，因此便想着学习一些开源项目。spdlog这个项目代码量不大，而且它所实现的功能理解起来也很容易，不需要太多的其他背景知识（毕竟是个日志库嘛），所以就选择了它。在学习这个项目期间，除了看源码外，也看了不少相关的博客，还有也尝试自己实现一个简单的日志库。最后实现了一大半，放弃了。毕竟跟着敲代码只是帮助更深刻理解源码的手段而不是目的。本人水平有限，有写得不对地方欢迎大家指出或者一起讨论。碎碎念结束，接下来进入正题。

总览

spdlog是一个支持多平台的日志库，使用十分方便。既支持header-only version，也支持compiled version。header-only的全部代码都在项目的include文件夹下，直接将里面的内容copy到自己的项目里就能用。因为我是在ubuntu系统下使用的该库，所以之后代码的解析部分如果遇到有不同平台存在不同实现的情况，默认只考虑在ubuntu系统下的情况。并且因为header-only的代码阅读起来更为方便，所以代码解析也只涉及此部分。

spdlog主要由logger（也包括async_logger）、sink、formatter、registry这四个部分组成，它们之间的基本逻辑结构如下图所示：

spdlog log API —— 是建立在logger之上的，只是对logger使用的封装，目的只是为了能够像官网给的示例代码spdlog::info(“Welcome to spdlog!”);那样，让用户能够以最简单的方式使用spdlog打印出log。这是一种从用户使用维度出发的程序设计思想。
logger —— 是spdlog开始处理日志的入口。sync-logger主要负责日志信息的整理，将格式化（通过第三方库fmt）后的日志内容、日志等级、日志时间等信息“整理”到一个名为log_msg结构体的对象中，然后再交给下游的sink进行处理。而对于async-logger，则是在将整理后的log_msg对象交给线程池，让线程池去处理后续的工作。
sink —— 接收log_msg对象，并通过formatter将对象中所含有的信息转换成字符串，最后将字符串输出到指定的地方，例如控制台、文件等，甚至通过tcp/udp将字符串发送到指定的地方。sink译为“下沉”，扩展一下可以理解为“落笔”，做的是把日志真正记录下来的事情。
formatter —— 负责将log_msg对象中的信息转换成字符串，例如日志等级、时间、实际内容等。时间的格式和精度、等级输出显示的颜色等都是由formatter决定的。支持用户自定义格式。
registry —— 负责管理所有的logger，包括创建、销毁、获取等。通过registry用户还可以对所有的logger进行一些全局设置，例如设置日志等级。

sync-logger

这部分的代码都在logger.h和logger-inl.h中，对应logger类。logger要做的事情就是将要记录的内容通过函数调用层层传递，最后到sink。以logger中成员函数info两种调用情况为例，展示logger的调用过程。

// 调用例如spdlog::info("Welcome to spdlog!");
// 或者spdlog::info(num);
template <typename T> void info(const T &msg)
{ log(level::info, msg); }  // 确定log等级为info

// 调用例如spdlog::info("Support for floats {:03.2f}", 1.23456);
// 或者spdlog::info("Positional args are {1} {0}..", "too", "supported");
template <typename... Args> void info(format_string_t<Args...> fmt, Args &&...args)
{ log(level::info, fmt, std::forward<Args>(args)...); }  // 确定log等级为info

template <typename T> void log(level::level_enum lvl, const T &msg)
{ log(source_loc{}, lvl, msg); }  // 接着再确定日志调用的位置（文件、函数名、行号）

template <typename... Args>
void log(level::level_enum lvl, format_string_t<Args...> fmt, Args &&...args)
{ log(source_loc{}, lvl, fmt, std::forward<Args>(args)...); }  // 接着再确定日志调用的位置（文件、函数名、行号）

template <typename T> void log(source_loc loc, level::level_enum lvl, const T &msg)
{ log(loc, lvl, "{}", msg); } // 因为spdlog::info(num);可以等价为spdlog::info("{}", num);，所以这里加了一个“{}”

template <typename... Args>
void log(source_loc loc, level::level_enum lvl, format_string_t<Args...> fmt, Args &&...args)
{ log_(loc, lvl, details::to_string_view(fmt), std::forward<Args>(args)...); }  // 成员函数info两种调用过程都会汇集到此处

为了方便展示，在不影响理解代码逻辑的情况下，我对代码做了一些删减，后续的代码展示同理。从上述代码可以看出，logger的调用过程是层层传递的，传递过程中不断添加各种信息，最后两种方式的调用都汇集到log_函数中。学习上述代码过程中需要关注的点是“完美转发”，这是一种通过万能引用来减少拷贝的技术，即上述代码中的“Args &&…args”和“std::forward(args)…”。具体不展开，大家感兴趣可以自行搜索。

接下来我们看看log_函数的实现：

template <typename... Args>
void log_(source_loc loc, level::level_enum lvl, string_view_t fmt, Args &&...args)
{
    bool log_enabled = should_log(lvl);
    bool traceback_enabled = tracer_.enabled();
    if (!log_enabled && !traceback_enabled) { return; }
    memory_buf_t buf;
    fmt::vformat_to(fmt::appender(buf), fmt, fmt::make_format_args(args...));
    details::log_msg log_msg(loc, name_, lvl, string_view_t(buf.data(), buf.size()));
    log_it_(log_msg, log_enabled, traceback_enabled);
}

首先判断是否需要记录日志should_log(lvl)，以及是否需要traceback，如果都不需要则直接返回。判断逻辑是当前log等级是否大于logger的log等级。比如代码开发过成功会输出debug等级的日志，但是生产环境只输出info及以上等级的日志。这样就只需要调整logger的log等级，就能控制日志输出的情况。因此这里要做此判断。而traceback是spdlog的另一个功能，对我们理解spdlog的调用过程相关程度不高，可不必细究。

接着使用第三方的fmt库做格式化，例如将(“num {:.2f}”, 1.23456)格式化成”num 1.23”，这样有效内容就转换成了字符串。再把各种信息都封装到log_msg对象中，最后再调用log_it_函数。

至此logger完成了它的主要工作，最后很剩下的工作就是把log_msg对象交给下游的sink进行处理了，就是上面最后一句代码“log_it_(log_msg, log_enabled, traceback_enabled);”要做的事。这部分代码如下：

void logger::log_it_(const spdlog::details::log_msg &log_msg,
                     bool log_enabled,
                     bool traceback_enabled)
{
    if (log_enabled) { sink_it_(log_msg); }
    if (traceback_enabled) { tracer_.push_back(log_msg); }
}

void logger::sink_it_(const details::log_msg &msg)
{
    for (auto &sink : sinks_)
    {
        if (sink->should_log(msg.level)) { sink->log(msg); }
    }

    if (should_flush_(msg)) { flush_(); }
}

void logger::flush_()
{
    for (auto &sink : sinks_) { sink->flush(); }
}

log_it函数又进一步调用了sink_it函数。在sink_it函数中，首先遍历了sinks_中的所有sink，在把msg交由每个sink去处理。sinks_是logger的成员变量，其声明为“std::vector sinks_;”。可以看出一个logger是可以对应多个sink的，同时sink实际上还是指针形式保存在logger中的，意味着也可以存在多个logger都指向同一个sink的情况。这样日志的输入端（logger）和输出端（sink）就解耦了。这样方便我们扩展，比如现在想让日志同时输出到文件和控制台，只需要在创建logger的时候把两个sink都添加进去就可以了。

同时还看到sink_it函数中还调用了flush_函数，这个函数的作用是让所有sink都进行一次flush操作。前面的sink->log(msg)这是写入了缓冲区，而sink->flush()是将缓冲区的内容进一步写入到文件或者控制台等最终目的地。而且在sink_it函数调用fluah_函数之前，还调用了should_flush_函数，函数中判断了msg的等级和flush_level_的关系，如果msg的等级大于flush_level_则返回true，否则返回false。这么做的目的是减少不必要的flush操作。例如我们像保存info及其以上等级的日志，但是绝大多数时候我们并会实时地查看info级别的日志，但是error级别的日志我们却希望能够及时展示出来。那么我们可以将flush_level_设置为error，这样只有error级别的日志才会进行flush操作。

async-logger

async-logger的代码在asyn_logger.h和async_looger-inl.h中，对应async_logger类。async_logger继承自logger，前面关于接受日志内容整理log_msg对象中的工作照常做，将对sink的调用（包括sink->log(msg)和sink->flush()）都交由线程池去执行了，由此便实现了异步。代码如下：

void spdlog::async_logger::sink_it_(const details::log_msg &msg)
{
    if (auto pool_ptr = thread_pool_.lock())
    {
        pool_ptr->post_log(shared_from_this(), msg, overflow_policy_);
    }
    else
    {
        throw_spdlog_ex("async log: thread pool doesn't exist anymore");
    }
}

// thread_pool_ 的声明
std::weak_ptr<details::thread_pool> thread_pool_;

线程池通过pool_ptr->post_log(shared_from_this(), msg, overflow_policy_);这句代码持有了当前asyn_logger的shared_ptr。那这样asyn_logger就不能再以shared_ptr的形式持有线程池了，因为会存在交叉引用带来的内存泄露问题。所以这里使用weak_ptr来持有线程池。

async_logger肯定是比logger快的，毕竟sink中的工作还需要实际IO，这部分相对耗时，交给线程池去做，主线程就可以继续往下执行了。毫无疑问，async_logger实现的重点是线程池。线程池里面要有一个多生产多消费的线程安全队列，用来存放日志内容。可以有多个async_logger（即生产者）向里面生产日志，又同时又多个线程（即消费者）从里面消费日志。这个队列的容量应该是有限的，当队列满了之后向里面生产日志可以有不同的策略，spdlog提供了三种策略：阻塞、丢弃新日志和丢弃旧日志。为方便实现这个需求，用循环队列来实现。

循环队列

循环队列的代码在circular_q.h中，实现起来不难。这里只提两点可能在没开始动手实现之前可能想不起来的点：

circular_q应设计成类模板，使其能够支持各种数据类型；
circular_q中实际存数据的std::vector vec_的大小应该比circular_q能存的数据大小多一个，这样才能判断队列是满的还是空的，两个状态不会混淆。

多生产多消费的线程安全队列

这部分代码在mpmc_blocking_q.h中，我们先来看一下其中的成员变量：

class mpmc_blocking_queue
{
private:
    std::mutex queue_mutex_;
    std::condition_variable push_cv_;
    std::condition_variable pop_cv_;
    spdlog::details::circular_q<T> q_;
};

一眼看出queue_mutex_就是用来保护队列的q_。push_cv_和pop_cv_是用来实现生产者消费者模型的关键，其存在的目的是当q_为空或满时，消费者线程或生产者线程是阻塞式等待，而不是空转。我们看看向mpmc_blocking_queue中生产和消费数据的代码：

void enqueue(T &&item)
{
    {
        std::unique_lock<std::mutex> lock(queue_mutex_);
        pop_cv_.wait(lock, [this] { return !this->q_.full(); });
        q_.push_back(std::move(item));
    }
    push_cv_.notify_one();
}

void dequeue(T &popped_item)
{
    {
        std::unique_lock<std::mutex> lock(queue_mutex_);
        push_cv_.wait(lock, [this] { return !this->q_.empty(); });
        popped_item = std::move(q_.front());
        q_.pop_front();
    }
    pop_cv_.notify_one();
}

enqueue也用了万能引用和完美转发，它首先获取了queue_mutex_的锁，然后通过pop_cv_.wait阻塞直到q_非满状态，然后item给move进q_中，最后先释放锁才通过push_cv_通知消费者。dequeue则做了类似的反向操作。

spdlog线程池

线程池的代码在thread_pool.h和thread_pool-inl.h中，这里的线程池跟那些通用的线程池实现相比，核心没变，每个线程都是负责从队列里面取东西然后执行。不同是线程池因为是专门做日志输出工作的，所以去从队列里取的东西是日志相关的东西，通用的线程池一般取的是函数指针。而且spdlog线程池的线程安全保证都封装在上述的mpmc_blocking_queue（多生产多消费的线程安全队列）里了，所以spdlog线程池的代码逻辑反而简单了。

如果有不熟悉通用线程池实现的朋友，自荐另外一篇文章：梨li狸：C++定时器与线程池的实现与详解

我们就简单看看每个线程（worker）做的是事情：

void thread_pool::worker_loop_()
{
    while (process_next_msg_()) { }
}

bool thread_pool::process_next_msg_()
{
    async_msg incoming_async_msg;
    q_.dequeue(incoming_async_msg);

    switch (incoming_async_msg.msg_type) {
        case async_msg_type::log: {
            incoming_async_msg.worker_ptr->backend_sink_it_(incoming_async_msg);
            return true;
        }
        case async_msg_type::flush: {
            incoming_async_msg.worker_ptr->backend_flush_();
            return true;
        }
        case async_msg_type::terminate: {
            return false;
        }
        default: {
            assert(false);
        }
    }

    return true;
}