GoogleLog(GLog)源码分析

        GLog是Google开发的一套日志输出框架。由于其具有功能强大、方便使用等特性，它被众多开源项目使用。本文将通过分析其源码，解析Glog实现的过程。

        该框架的源码在https://github.com/google/glog上可以获取到。本文将以目前最新的0.3.3版本源码为范例进行分析。（转载请指明出于breaksoftware的csdn博客）

        首先我们介绍下Glog简单的使用方法。Glog暴露了很多方法供使用者调用，一般它们都是通过宏的形式提供的。这些方法的功能包括：参数设置、判断、日志输出、自定义行为。基于重要性的考虑，我并不准备在本文中介绍参数设置和判断两个特性的函数。而将重点放在Glog的核心——日志输出和自定义行为上。而且在日志输出环节，我们将重点关注于文件形式的输出。下文中很多未加设定的场景一般都是以文件输出为例说明的。

        我们以一个简单的例子作为开始

int _tmain(int argc, _TCHAR* argv[]){    google::InitGoogleLogging(argv[0]);    FLAGS_log_dir = "D:\\Dev\\glog-0.3.3\\glog-0.3.3\\Debug\\log";    LOG(INFO) << "INFO";    LOG(INFO) << "INFO1";    LOG(WARNING) << "WARNING";    LOG(WARNING) << "WARNING1";    LOG(ERROR) << "ERROR";    LOG(ERROR) << "ERROR1";    LOG(FATAL) << "FATAL";    google::ShutdownGoogleLogging();return 0;}

        第3和12行是对称的，用于初始化和关闭Glog系统。这两个过程的实现也非常简单，其比较有意义的是ShutdownGoogleLogging中实现了对过程中新建对象的清理。即调用了

static LogDestination* log_destinations_[NUM_SEVERITIES];void LogDestination::DeleteLogDestinations() {  for (int severity = 0; severity < NUM_SEVERITIES; ++severity) {    delete log_destinations_[severity];    log_destinations_[severity] = NULL;  }}

        LogDestination是是GLog非常核心的一个类。按英文翻译过来，它就是“日志目标”类。正如它名称，我们对日志的输出最终将落到该类上去执行。之后我们将一直和它打交道。

        上面main函数的04行对Glog的全局变量重新赋值，它用于标记日志文件的生成路径。这类全局变量在logging.h中暴露了很多，它们很多是以DECLARE_bool、DECLARE_int32或DECLARE_string等宏声明的。这些就是我前文所述的“参数”。我们先只要知道FLAGS_log_dir的作用就行了。

        05到11行向GLog系统中输出了4中类型的日志，即INFO、WARNING、ERROR和FATAL。GLog框架一共提供了上述四种类型的日志，这些日志将被分别输出到四个文件中。如本例我们将生成如下四个文件：

glog_test.exe.computername.username.log.ERROR.20160510-153013.9704glog_test.exe.computername.username.log.FATAL.20160510-153013.9704glog_test.exe.computername.username.log.INFO.20160510-153013.9704glog_test.exe.computername.username.log.WARNING.20160510-153013.9704

        其中computername是设备的ID，username是登录用户的名称。

        这种设计是非常有意义的。在我们开发过程中，我们可以通过INFO类型的日志进行过程分析。在自测阶段，我们可能更多要关注于是否存在WARNING类型的日志。而上线后，可能会出现一些我们认为不合法或者异常的场景，则这个时候就要关注ERROR和FATAL类型的日志了。这四种日志并不是相互独立的，而是存在包含关系。按照重要性，INFO日志文件将包含INFO、WARNING、ERROR和FATAL日志，因为在开发过程中我们需要关注所有信息。WARNING日志文件将包含WARNING、ERROR和FATAL日志。ERROR日志将包含ERROR和FATAL日志。FATAL日志文件里只有FATAL类型的日志。这种层级关系将非常有助于我们在不同时期关注不同性质的问题。我们看下INFO日志文件的内容

Log file created at: 2016/05/10 15:30:13Running on machine: COMPUTERNAMELog line format: [IWEF]mmdd hh:mm:ss.uuuuuu threadid file:line] msgI0510 15:30:13.564411 11392 glog_test.cpp:11] INFOI0510 15:30:13.566411 11392 glog_test.cpp:12] INFO1W0510 15:30:13.566411 11392 glog_test.cpp:13] WARNINGW0510 15:30:13.566411 11392 glog_test.cpp:14] WARNING1E0510 15:30:13.567411 11392 glog_test.cpp:15] ERRORE0510 15:30:13.567411 11392 glog_test.cpp:16] ERROR1F0510 15:30:13.568413 11392 glog_test.cpp:17] FATAL

        眼尖的同学可能发现INFO、ERROR和WARNING日志都有两条，而FATAL日志只有一条。这个地方引出FATAL类型日志的使用场景问题。一般情况下，如果出现程序已经无法执行的场景才使用FATAL日志用于记录临死之前的事情。所以如果我们在项目中发现日志中出现一连串的FATAL日志，往往是对Glog的错误使用。
        Glog的基本使用我们讲完了，我们开始进行源码的讲解。

        我们先看下LOG宏的定义

#define LOG(severity) COMPACT_GOOGLE_LOG_ ## severity.stream()

        可以见得，LOG宏的等级参数和COMPACT_GOOGLE_LOG_联合在一块组成一个宏。比如INFO则对应于COMPACT_GOOGLE_LOG_INFO；FATAL对应于COMPACT_GOOGLE_LOG_FATAL。这些宏最终都将对应于一个google::LogMessage对象，比如

#define LOG_TO_STRING_ERROR(message) google::LogMessage( \      __FILE__, __LINE__, google::GLOG_ERROR, message)

        通过对不同日志类型的LogMessage构造对象对比说明，它们是通过LogMessage的第三个参数进行区分的，上例中ERROR日志的等级就是google::GLOG_ERROR。在log_severity.h文件中，定义了GLog四个等级对应的值。

const int GLOG_INFO = 0, GLOG_WARNING = 1, GLOG_ERROR = 2, GLOG_FATAL = 3,  NUM_SEVERITIES = 4;

        这四个值并非随便定义的。它们这样设计，将有助于完成之前所说的日志包含输出问题。在将日志输出到文件的函数LogDestination::LogToAllLogfiles中

for (int i = severity; i >= 0; --i)      LogDestination::MaybeLogToLogfile(i, timestamp, message, len);  }

        这段简单的for循环，让日志输出到自己以及低于自己等级的日志文件中。

        在现实使用中，我们往往会通过一个临时变量或者宏，来区分开发环境和线上环境。比如开发环境我们需要INFO级别的日志，而线上环境我们需要ERROR及其以上等级的日志。当我们测试完毕，准备上线前，我们不可能将输出INFO类型日志的语句删掉——因为可能很多、很分散且删除代码是不安全的。那么我们就需要使用一种手段让INFO和WARNING等级的日志失效。GLog是这么做的

#if GOOGLE_STRIP_LOG == 0#define COMPACT_GOOGLE_LOG_INFO google::LogMessage( \      __FILE__, __LINE__)#define LOG_TO_STRING_INFO(message) google::LogMessage( \      __FILE__, __LINE__, google::GLOG_INFO, message)#else#define COMPACT_GOOGLE_LOG_INFO google::NullStream()#define LOG_TO_STRING_INFO(message) google::NullStream()#endif#if GOOGLE_STRIP_LOG <= 1#define COMPACT_GOOGLE_LOG_WARNING google::LogMessage( \      __FILE__, __LINE__, google::GLOG_WARNING)#define LOG_TO_STRING_WARNING(message) google::LogMessage( \      __FILE__, __LINE__, google::GLOG_WARNING, message)#else#define COMPACT_GOOGLE_LOG_WARNING google::NullStream()#define LOG_TO_STRING_WARNING(message) google::NullStream()#endif#if GOOGLE_STRIP_LOG <= 2#define COMPACT_GOOGLE_LOG_ERROR google::LogMessage( \      __FILE__, __LINE__, google::GLOG_ERROR)#define LOG_TO_STRING_ERROR(message) google::LogMessage( \      __FILE__, __LINE__, google::GLOG_ERROR, message)#else#define COMPACT_GOOGLE_LOG_ERROR google::NullStream()#define LOG_TO_STRING_ERROR(message) google::NullStream()#endif#if GOOGLE_STRIP_LOG <= 3#define COMPACT_GOOGLE_LOG_FATAL google::LogMessageFatal( \      __FILE__, __LINE__)#define LOG_TO_STRING_FATAL(message) google::LogMessage( \      __FILE__, __LINE__, google::GLOG_FATAL, message)#else#define COMPACT_GOOGLE_LOG_FATAL google::NullStreamFatal()#define LOG_TO_STRING_FATAL(message) google::NullStreamFatal()#endif

        我们可以通过定义GOOGLE_STRIP_LOG的值，来控制相应宏的定义。比如我们给GOOGLE_STRIP_LOG赋值2，则COMPACT_GOOGLE_LOG_WARNING会被定义为google::NullStream()，从而不会进行输出。ERROR和FATAL都将定义为LogMessage的临时对象进行之后的业务逻辑。

        以一个常用的LogMessage的构造函数来看临时对象的初始化

LogMessage::LogMessage(const char* file, int line, LogSeverity severity)    : allocated_(NULL) {  Init(file, line, severity, &LogMessage::SendToLog);}

        该函数中传入了执行语句所在的文件名和行号，这些我们都将在输出的日志中见到过。第三个参数是日志等级，即GLOG_INFO等值。Init传入的第四个参数是该类的一个成员函数地址。它才是我们关注的重点。
        LogMessage::SendToLog函数主要执行的是下面这段代码

    // log this message to all log files of severity <= severity_    LogDestination::LogToAllLogfiles(data_->severity_, data_->timestamp_,                                     data_->message_text_,                                     data_->num_chars_to_log_);    LogDestination::MaybeLogToStderr(data_->severity_, data_->message_text_,                                     data_->num_chars_to_log_);    LogDestination::MaybeLogToEmail(data_->severity_, data_->message_text_,                                    data_->num_chars_to_log_);    LogDestination::LogToSinks(data_->severity_,                               data_->fullname_, data_->basename_,                               data_->line_, &data_->tm_time_,                               data_->message_text_ + data_->num_prefix_chars_,                               (data_->num_chars_to_log_                                - data_->num_prefix_chars_ - 1));

        这段代码分别是：尝试向文件中输出、尝试向标准错误流中输出、尝试发送邮件、尝试向用户自定义池中输出。

        尝试发送邮件的方式我们很少使用到，它实际是借用了linux系统上/bin/mail程序去发送邮件，所以对这块有兴趣的同学，可以主要关注下邮件内容的组装和发送命令的使用。

        LogToAllLogfiles函数不仅具有向文件输出的能力，还有向标准错误流中输出的能力。

inline void LogDestination::LogToAllLogfiles(LogSeverity severity,                                             time_t timestamp,                                             const char* message,                                             size_t len) {  if ( FLAGS_logtostderr ) {           // global flag: never log to file    ColoredWriteToStderr(severity, message, len);  } else {    for (int i = severity; i >= 0; --i)      LogDestination::MaybeLogToLogfile(i, timestamp, message, len);  }}

        else中的for循环就是之前我们讲解的日志包含的实现。

        MaybeLogToLogfile方法将让一个全局的LogDestination对象执行日志输出逻辑

inline void LogDestination::MaybeLogToLogfile(LogSeverity severity,                                              time_t timestamp,      const char* message,      size_t len) {  const bool should_flush = severity > FLAGS_logbuflevel;  LogDestination* destination = log_destination(severity);  destination->logger_->Write(should_flush, timestamp, message, len);}

        log_destination方法将通过日志等级新建并返回或者获取一个保存在全局区域中LogDestination指针

LogDestination* LogDestination::log_destinations_[NUM_SEVERITIES];inline LogDestination* LogDestination::log_destination(LogSeverity severity) {  assert(severity >=0 && severity < NUM_SEVERITIES);  if (!log_destinations_[severity]) {    log_destinations_[severity] = new LogDestination(severity, NULL);  }  return log_destinations_[severity];}

        如此可见，我们的测试代码将新建四个LogDestination对象，并将指针保存在全局数组log_destinations_中。这四个指针分别对应于INFO、WARNING、ERROR和FATAL日志的输出目标对象。所以，不管在多线程还是在单线程环境中，我们日志输出都将调用到这四个对象指针。
       LogDestination类有个用于实际输出日志的成员变量

  LogFileObject fileobject_;  base::Logger* logger_;      // Either &fileobject_, or wrapper around it

        Logger是个接口类，其暴露出来的方法都是纯虚。所以实际操作的是其继承类。LogFileObject继承于Logger接口，对于文件类型的输出，logger_指向fileobject_对象。

LogDestination::LogDestination(LogSeverity severity,                               const char* base_filename)  : fileobject_(severity, base_filename),    logger_(&fileobject_) {}

        LogFileObject的Write的实现非常简单，除了在文件不存在的情况下新建了日志文件，还有就是日志个格式化输出。它的整个逻辑是在锁内部完成的，这样可以保证多线程写操作是安全的。
        我们分析完LogToAllLogfiles的实现，再探索下它是在何处被调用的。之前我们讲过LOG宏构建了一个LogMessage临时对象。这个临时对象的生命周期就是C++语句中其所在的那一行的执行周期。

    LOG(ERROR) << "ERROR";    LOG(ERROR) << "ERROR1";

        上述两行，就构建了两个LogMessage临时对象。第一行的临时对象在第二行执行之前就消亡了，第二行的临时对象在之后一行执行之前就消亡了。而对LogToAllLogfiles的调用就是在LogMessage的析构函数中（实际是Flush中）。

LogMessage::~LogMessage() {  Flush();  delete allocated_;}

        Flush中的核心代码是

  {    MutexLock l(&log_mutex);    (this->*(data_->send_method_))();    ++num_messages_[static_cast<int>(data_->severity_)];  }  LogDestination::WaitForSinks(data_);

        注意在调用send_method_所指向的函数（保存为文件时默认的就是LogToAllLogfiles方法）之前上了锁。这个锁非常必要，可以保证之后的操作是受到保护的。否则之前在全局区域保存LogDestination对象指针的逻辑就存在多线程访问的问题。

        我们可以总结下，每条日志的输出都通过一个LogMessage临时对象的析构，传递到全局变量log_destinations_中相应等级对应的LogDestination指针所指向的对象。那么LogDestination对象又是在何时进行日志写入文件的呢？我们知道文件的Write方法并不一定马上把内容写入文件，而是存在一定的缓存中，再根据系统的判断或者用户主动调用fflush，将数据实际写入文件。LogFileObject提供了两个Flush方法

void LogFileObject::Flush() {  MutexLock l(&lock_);  FlushUnlocked();}void LogFileObject::FlushUnlocked(){  if (file_ != NULL) {    fflush(file_);    bytes_since_flush_ = 0;  }  // Figure out when we are due for another flush.  const int64 next = (FLAGS_logbufsecs                      * static_cast<int64>(1000000));  // in usec  next_flush_time_ = CycleClock_Now() + UsecToCycles(next);}

        一个是通过锁保证多线程安全的版本，一个是不安全的版本。它们都是执行了fflush，并计算了下一次flush时间。在LogFileObject的Write方法末尾，通过该时间的判断，确定是否真的将缓存写入文件中。

  // See important msgs *now*.  Also, flush logs at least every 10^6 chars,  // or every "FLAGS_logbufsecs" seconds.  if ( force_flush ||       (bytes_since_flush_ >= 1000000) ||       (CycleClock_Now() >= next_flush_time_) ) {    FlushUnlocked();#ifdef OS_LINUX    if (FLAGS_drop_log_memory) {      if (file_length_ >= logging::kPageSize) {        // don't evict the most recent page        uint32 len = file_length_ & ~(logging::kPageSize - 1);        posix_fadvise(fileno(file_), 0, len, POSIX_FADV_DONTNEED);      }    }#endif  }

        还有一种强制写入文件的方法，就是LogDestination::FlushLogFilesUnsafe和LogDestination::FlushLogFiles方法，它们的实现是

inline void LogDestination::FlushLogFilesUnsafe(int min_severity) {  // assume we have the log_mutex or we simply don't care  // about it  for (int i = min_severity; i < NUM_SEVERITIES; i++) {    LogDestination* log = log_destination(i);    if (log != NULL) {      // Flush the base fileobject_ logger directly instead of going      // through any wrappers to reduce chance of deadlock.      log->fileobject_.FlushUnlocked();    }  }}inline void LogDestination::FlushLogFiles(int min_severity) {  // Prevent any subtle race conditions by wrapping a mutex lock around  // all this stuff.  MutexLock l(&log_mutex);  for (int i = min_severity; i < NUM_SEVERITIES; i++) {    LogDestination* log = log_destination(i);    if (log != NULL) {      log->logger_->Flush();    }  }}

        使用者可以通过这两个函数人为主动的刷新缓冲区，让内容落地。
        以上，我们讲解了GLog主要使用方法及其实现原理。实际GLog作为一个框架，也不失灵活性。

        比如我们可以通过SetLogger方法修改不同等级的日志输出方法。

base::Logger* base::GetLogger(LogSeverity severity) {  MutexLock l(&log_mutex);  return LogDestination::log_destination(severity)->logger_;}void base::SetLogger(LogSeverity severity, base::Logger* logger) {  MutexLock l(&log_mutex);  LogDestination::log_destination(severity)->logger_ = logger;}

        下面代码是其使用的一个实例

struct MyLogger : public base::Logger {  string data;  virtual void Write(bool /* should_flush */,                     time_t /* timestamp */,                     const char* message,                     int length) {    data.append(message, length);  }  virtual void Flush() { }  virtual uint32 LogSize() { return data.length(); }};static void TestWrapper() {  fprintf(stderr, "==== Test log wrapper\n");  MyLogger my_logger;  base::Logger* old_logger = base::GetLogger(GLOG_INFO);  base::SetLogger(GLOG_INFO, &my_logger);  LOG(INFO) << "Send to wrapped logger";  FlushLogFiles(GLOG_INFO);  base::SetLogger(GLOG_INFO, old_logger);  CHECK(strstr(my_logger.data.c_str(), "Send to wrapped logger") != NULL);}

        我们还可以使用AddLogSink和RemoveLogSink方法自定义处理日志的逻辑。AddLogSink最终会调用到

inline void LogDestination::AddLogSink(LogSink *destination) {  // Prevent any subtle race conditions by wrapping a mutex lock around  // all this stuff.  MutexLock l(&sink_mutex_);  if (!sinks_)  sinks_ = new vector<LogSink*>;  sinks_->push_back(destination);}

        其中sinks_是全局vector指针。它是独立于之前介绍的log_destinations_数组管理的日志输出方式。

  // arbitrary global logging destinations.  static vector<LogSink*>* sinks_;

        最终它会在SendToLog方法中的LogToSinks中被调用。

inline void LogDestination::LogToSinks(LogSeverity severity,                                       const char *full_filename,                                       const char *base_filename,                                       int line,                                       const struct ::tm* tm_time,                                       const char* message,                                       size_t message_len) {  ReaderMutexLock l(&sink_mutex_);  if (sinks_) {    for (int i = sinks_->size() - 1; i >= 0; i--) {      (*sinks_)[i]->send(severity, full_filename, base_filename,                         line, tm_time, message, message_len);    }  }}

        作为使用者，我们需要定义send方法，并根据日志等级的不同，处理不同的逻辑。下面是GLog测试代码中的一个例子

  virtual void send(LogSeverity severity, const char* /* full_filename */,                    const char* base_filename, int line,                    const struct tm* tm_time,                    const char* message, size_t message_len) {    // Push it to Writer thread if we are the original logging thread.    // Note: Something like ThreadLocalLogSink is a better choice    //       to do thread-specific LogSink logic for real.    if (pthread_equal(tid_, pthread_self())) {      writer_.Buffer(ToString(severity, base_filename, line,                              tm_time, message, message_len));    }  }

        最后介绍LOG_TO_SINK和LOG_TO_SINK_BUT_NOT_TO_LOGFILE宏，它是设置单个Sink的方式（AddLogSink是设置一个到多个sink的方式）

#define LOG_TO_SINK(sink, severity) \  google::LogMessage(                                    \      __FILE__, __LINE__,                                               \      google::GLOG_ ## severity,                         \      static_cast<google::LogSink*>(sink), true).stream()#define LOG_TO_SINK_BUT_NOT_TO_LOGFILE(sink, severity)                  \  google::LogMessage(                                    \      __FILE__, __LINE__,                                               \      google::GLOG_ ## severity,                         \      static_cast<google::LogSink*>(sink), false).stream()

        它调用的是5个参数版本的LogMessage构造函数

LogMessage::LogMessage(const char* file, int line, LogSeverity severity,                       LogSink* sink, bool also_send_to_log)    : allocated_(NULL) {  Init(file, line, severity, also_send_to_log ? &LogMessage::SendToSinkAndLog :                                                &LogMessage::SendToSink);  data_->sink_ = sink;  // override Init()'s setting to NULL}

        构造函数中true或false标识是否需要调用之前分析过的SendToLog()方法，还是只是调用SendToSink方法

void LogMessage::SendToSink() EXCLUSIVE_LOCKS_REQUIRED(log_mutex) {  if (data_->sink_ != NULL) {    RAW_DCHECK(data_->num_chars_to_log_ > 0 &&               data_->message_text_[data_->num_chars_to_log_-1] == '\n', "");    data_->sink_->send(data_->severity_, data_->fullname_, data_->basename_,                       data_->line_, &data_->tm_time_,                       data_->message_text_ + data_->num_prefix_chars_,                       (data_->num_chars_to_log_ -                        data_->num_prefix_chars_ - 1));  }}

        至此，我们便将Glog的实现原理分析完毕了。

        在阅读代码和实验其使用过程中，可以发现GLog是一个非常优秀的日志开源库。但是如果想让GLog灵活的应用于产品中，其实还有很多事情可以做。比如我们可以将参数放到配置文件中，这样不至于我们每次修改参数时要重新编译代码。再比如我们可以定制自己的Sink，将日志数据发送到指定机器。