本文主要是介绍多线程情况下慎用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分钟，所以根据时间戳计算日期时间的时候需要将时间戳偏移的时间加上一起算。
这篇关于多线程情况下慎用localtime_r的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
