多线程情况下慎用localtime_r

最近有个需求，需要提升日志模块的性能。当前日志模块每秒钟处理的日志数量大概在55w左右，于是进行优化，在日志的IO线程中将sprintf剥离，提前将时间、日志等级等格式化处理。

于是这样就产生了一个问题，在IO线程中频繁的使用localtime_r来获取日期时间，在单线程中性能影响可能不大，然而我将localtime_r移动到各工作线程后，首先在windows下性能还是有55%左右的提升的，大概从56w到87w，而在linux下面，发现日志处理量居然只有20w左右，反而下降了50%，真是一件非常奇怪的事情。

在每个地方进行瓶颈测试，发现在localtime_r中消耗了大量的时间，造成了工作线程丢入IO线程的量降低了，其实IO的效率是高了，但是工作线程的效率却降低不少。后来查询了不少资料，发现在localtime_r中有锁，而多个工作线程同时请求时候，就造成了有些线程等待，性能确实会下降不少。

于是改成用gettimeofday来计算时间，日志的精度只需要到秒而已，这个函数够用了。唯一需要注意的是它的第二个参数有个时区的域，本机返回的值是-480，就是北京时间相对于格林威治时间提前了480分钟，所以根据时间戳计算日期时间的时候需要将时间戳偏移的时间加上一起算。