由于一些第三方平台/服务的API都升级成了Https，导致原来Tars自带的Http库无法直接使用了，于是引进了 libcurl （ github地址 ）。
但是发现在对应模块长时间运行后，其占用内存一直稳定上升，存在内存泄漏。首先排除掉一些不太可能的泄漏点：Tars、std::string、std::map、std::vector常规使用，无显式的new/malloc。
那么只剩下模块引入的动态库libcurl了，而程序实现严格按照libcurl按照官方文档的样例做法：
- 在主线程curl_global_init；
- 业务线程每次进行业务处理时调用curl_easy_init获得新的CURL，设置好选项后调用curl_easy_perform；
- 业务处理完毕后调用curl_easy_cleanup，curl_slist_free_all（如果有用到curl_slist）释放资源；
- 如果主线程退出调用curl_global_cleanup释放资源；
开始一度以为是libcurl用法有问题，后来用valgrind跑程序发现是libcurl真有泄漏，github上1W+Star的开源库有泄漏，这是什么操作？
发生泄漏时服务器环境：
系统：Centos 7.2 64位
Gcc版本：gcc version 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC)
libcurl动态库版本：7.29.0（通过yum install curl & yum install libcurl-devel安装）
curl官方的 Mailing Lists 上面也有很多提到内存泄漏的问题，大多是围绕OpenSSL展开，也有一些只言片语提到尝试开启OpenSSL，但是本地通过valgrind测试观察异常日志，函数调用并没有进入OpenSSL相关函数，这是怎么回事？让我们找找源头：
libcurl的默认安装配置在目录/usr/lib64/pkgconfig，里面有其配置文件libcurl.pc
注意红框部分–without-ssl，原来默认OpenSSL是没有开启的。
解决步骤
1、下载libcurl，这里是 下载的7.63zip安装包 ；
2、./configure –with-ssl –libdir=/usr/lib64 –includedir=/usr/include；
3、make；
4、sudo make install；
5、相关模块重启；
步骤2的配置参数可以根据按需选择，然后观察SSL support: enabled (OpenSSL)这一栏是不是绿灯。
更新之后程序运行几天稳定，并内存占用正常。
最后强调一下，不同linux版本的libcurl默认配置可能不一样，这个问题与解决可能无法直接套用在其他linux版本。
（全文结束）
转载文章请注明出处：漫漫路 - lanindex.com