Quill日志库中Logger创建与删除的线程安全问题解析

背景介绍

在使用高性能C++日志库Quill进行开发时，开发者可能会遇到一个典型的多线程场景：频繁创建和删除Logger实例。最近在实际项目集成中就发现了一个随机崩溃的问题，经过深入分析发现这与Quill内部对Logger管理的异步机制有关。

问题现象

当测试代码中连续执行以下操作时会出现随机崩溃：

1. 创建一个指定名称的Logger
2. 删除该Logger
3. 立即重新创建同名Logger

特别是在移除sleep延迟后，崩溃概率显著增加，这明显指向了一个线程安全问题。

技术原理

Quill采用异步设计来提高性能，其中Logger的删除操作remove_logger()是异步执行的。这意味着：

1. 调用remove_logger()后，Logger并不会立即从系统中移除
2. 在此期间如果尝试创建同名Logger，会返回即将被删除的旧Logger实例
3. 当后台线程最终处理删除操作时，可能导致程序访问已释放资源

解决方案

方案一：同步等待删除完成

通过检查Logger数量变化来确保删除操作完成：

size_t const total_loggers = quill::Frontend::get_number_of_loggers();
quill::Frontend::remove_logger(logger);

// 等待直到Logger实际被移除
while (quill::Frontend::get_number_of_loggers() != (total_loggers - 1))
{
    // 空循环等待
}

这种方法适用于测试环境，但在生产环境中可能影响性能。

方案二：使用唯一标识符

更推荐的做法是避免重复使用Logger名称，为每个新Logger生成唯一ID：

// 使用时间戳或UUID作为Logger名称
auto logger = quill::create_logger("logger_" + std::to_string(get_timestamp()));

最佳实践

1. 生产环境：优先创建新Logger而非删除后重建
2. 测试环境：如需精确控制，使用同步等待机制
3. 命名规范：为Logger设计合理的命名策略，避免冲突
4. 资源管理：理解Quill的Sink生命周期，合理规划Logger使用

总结

Quill的异步设计在提供高性能的同时，也要求开发者理解其内部机制。特别是在多线程环境下操作Logger时，需要特别注意创建和删除的顺序与同步问题。通过本文介绍的方法，开发者可以避免类似问题，构建更稳定的日志系统。