最近项目需要一个log库，同事推荐google glog，源码地址：https://github.com/google/glog。网上说性能很好，既然要用那就抱着学习的态度研究下源码，这样用起来心里也有底。

glog的使用我就不罗嗦了，网上一大堆。这里我主要说说它在多线程安全的前提下如何提高性能（纯属个人见解欢迎拍砖）。下面会讲到glog使用的线程本地存储和placement new两个酷炫的技术。

glog打日志一般是这么写的：LOG(INFO) << "hello world";我们带着问题看代码，glog流式输入，他是什么时候写的文件，又是如何做到在行末替我们加上endl?

LOG宏定义如下：

图片发自简书App

猜猜为什么使用宏定义？因为日志中要加入文件名和行号，使用函数的话是做不到的。

我们把这个宏展开看看：

LOG(INFO)展开成：COMPACT_GOOGLE_LOG_ INFO.stream()

COMPACT_GOOGLE_LOG_ INFO的定义如下：

图片发自简书App

COMPACT_GOOGLE_LOG_ INFO.stream()展开成：google::LogMessage( __FILE__, __LINE__).stream()

最终我们的LOG(INFO) << "hello world";展开之后是这样的：

google::LogMessage( __FILE__, __LINE__).stream() << "hello world";

从上面的代码我们可以看到每打一条日志就会构造一个LogMessage对象。我的天哪，这样怎么会高效呢？

我们看看LogMessage的定义：

图片发自简书App

可以看到LogMessage有一个LogMessageData* data_成员而LogMessageData的定义如下：

图片发自简书App

可以看到LogMessageData的下面两个成员：

char message_text_[LogMessage::kMaxLogMessageLen+1];

LogStream stream_;

图片发自简书App

不禁又要感叹“我的天哪”,难道每打一条日志就要创建这么个大家伙。先别慌，大名鼎鼎的glog，大牛写的代码怎么可能这么low嘛。那就让我们再来看看LogMessage的构造函数：

图片发自简书App

再看看初始化函数

图片发自简书App

又要感叹了“我的天哪”，还真是每次都new一个LogMessageData。再定定神GLOG_THREAD_LOCAL_STORAGE里面的两个new怎么看起来怪怪的跟一般的new不太一样啊。data_ = new (&thread_msg_data) LogMessageData;噢恍然大悟这是placement new啊，不用分配内存，会在&thread_msg_data这块内存上构造一个对象，它只会调LogMessageData构造函数。这下明白了每打一条日志其实只是调一下LogMessageData的构造函数，不会分配内存这样就快多了，跟普通的函数调用差不多。大牛果然不一样。我们来看看thread_msg_data的定义：

static GLOG_THREAD_LOCAL_STORAGE std::aligned_storage<sizeof(LogMessage::LogMessageData),alignof(LogMessage::LogMessageData)>::type thread_msg_data;

std::aligned_storage<sizeof(LogMessage::LogMessageData),alignof(LogMessage::LogMessageData)>::type我就不详细说了，C++11的一个新特性，定义一块内存对其的缓冲区。

不好了，thread_msg_data是一个静态全局变量，要是在多线程打日志的时候不是就 乱套了嘛。这次我就不感叹“我的天哪”，大牛肯定有办法的。我们再仔细看下thread_msg_data有一个GLOG_THREAD_LOCAL_STORAGE 宏修饰。我们通过这个宏的名字就能知道他是线程本地存储的意思。看看这个宏的定义：

/* Define to necessary thread-local storage attribute. */

#define GLOG_THREAD_LOCAL_STORAGE __declspec(thread)

哦原来这就是线程本地存储啊，是不是很神奇。有了他修饰那么每个线程就都会有一个thread_msg_data实例，每个线程修改的都是自己的线程本地对象。现在来回答下我们前面的问题，glog是什么时候写的文件，又是如何做到在行末替我们加上endl的？现在看来LogMessage构造的时候已经把文件名、行号等信息通过ostream写入thread_msg_data buffer了，我们自定义的日志也会通过ostream写入buffer。那我们就可以大胆的猜想一定是在LogMessage析构的时候加上endl并写入文件的，我们来看看LogMessage的析构函数：

图片发自简书App

果然会调用一个Flush()函数。我们等会再看Flush()函数，先看看这个data_->~LogMessageData();居然显式调用LogMessageData析构函数。这又是placement new跟普通new不同的地方，因为没有分配内存所以也不能delete,只能显式调用析构函数。下面我们看看Flush()函数：

图片发自简书App

跟我们的猜想一样Flush()函数里会为我们加上回车并调用LogMessage构造的时候传入的send_method_回调函数写入文件。最后大牛还为了安全起见，在写完文件之后还把回车去掉恢复了ostrstream buffer原来的样子：

图片发自简书App

好了今天扯了这么多，我的水平有限，大家如果觉得我没说清楚，那么就自己看看源码吧。能看到这个地方的都是真爱啊。