谨慎使用STL
最近解决了一个因为大量使用STL造成的严重内存泄漏问题，再次记录下。
上周上线了基于用户tag的推荐，没天服务器会自动生成新的tag数据，然后scp到指定目录下，推荐服务中，对文件做了监控，如果改变就会重新加载解析。
函数代码如下：
void ReposManager::ReLoadUidTagData(const std::string& file_name) {
std::string file_content;
bool ret = file::ReadFileToString(file_name, &file_content);
std::unordered_map<int, std::unordered_map<std::string, double> > uid_tags_map;
if (ret == false) return;
std::vector<std::string> content;
SplitString(file_content, '\n', &content);
ifstream fin(file_name);
for (auto line: content)
std::vector<std::string> strs;
std::vector<std::string> vstr;
SplitString(line, '=', &strs);
if (strs.size() < 2) continue;
double weight = StringToDouble(strs[1]);
SplitString(strs[0], ':', &vstr);
if (vstr.size() < 2) continue;
int uid = StringToInt(vstr[0]);
std::string tag = vstr[1];
std::unordered_map<std::string, double>& tags_map = uid_tags_map[uid];
tags_map[tag] = weight;
}
for (auto it = uid_tags_map.begin(); it != uid_tags_map.end(); ++it) {
int uid = it->first;
std::unordered_map<std::string, double>& uid_tags = uid_tags_map[uid];
std::vector<std::string> tags;
for (auto it = uid_tags.begin(); it != uid_tags.end(); ++it) {
tags.push_back(it->first);
}
auto cmp = [&](const std::string& a, const std::string& b) {
return uid_tags[a] > uid_tags[b];
};
std::sort(tags.begin(), tags.end(), cmp);
uid_tags_[uid] = tags;
}
}
文件存储格式为uid:tag=weight 有很多行，共220M左右，函数的功能是对每行进行分割，然后存到成员变量uid_tags_中。函数初看之下没什么问题，但上线后第二天内存涨到3.6G，线上服务器内存很大也不能这么浪费，我记得刚启动加载完毕才2.0G，怎么涨了这么多，考虑原因，估计是凌晨的文件变更再次解析导致的，重启改动文件测试，果然是这个。
文件220M，全部加载进内存，解析过程中算上额外的数据结构的确会引起内存增长，但这些内存消耗只是暂时的，局部变量函数结束后，内存就释放了，显然这里的一些局部变量没有释放掉，这个情况还的确没遇到过。
google了解到STL的内存分配器，分多级，对于申请交大的内存，他会在堆上去申请。我们理解的局部变量出了作用域就会释放掉，这是因为大部分的局部变量都在函数栈里，函数执行完了，整个栈都会释放掉。周末在家试了下，尝试手动通过vector的swap以及map的clear，手动释放，在本机有一定的效果，内存没有继续增长，以为解决了。
周一到公司，放到测试服务器上，发现还是没有解决了，内存还是会出现较大增长，同样的二进制文件，为何会有差异，考虑再三，估计是虚拟机和测试服的配置不同，虚拟机内存不大，所以内存释放得会快点，测试服内存十几个G，内存不是很紧张，所以长时间得不到释放。(看来保持测试环境和线上环境的统一，这个还是很有必要的，保证了运行环境的一致，便于排查问题)。
在知乎看到有人回答malloc_trim（0），google了到使用malloc_trim(0),后来发现无效，然后看C语言的malloc只是提供了接口，具体的实现在各个平台不一样，linux下是glibc的里的malloc，了解到可以用google的tcmalloc替换掉linux默认的malloc，替换后内存从原来高达3.6G到2.6G，看来效果还是杠杆的! 回头自己对代码做了下检查，觉得存储的文件可以再修改下，
uid:tag1=weight
uid:tag2=weight
...
改为：
uid:tag1=weight,tag2=weight,tag3=weight....
将每个uid的所属tag整合到一起，原来220M的文件变味了150M左右，然后修改文件解析函数：
void ReposManager::ReLoadUidTagData(const std::string& file_name) {
std::string file_content;
bool ret = file::ReadFileToString(file_name, &file_content);
if (ret == false) return;
std::vector<std::pair<std::string, double>> tag_list;
using namespace std;
auto cmp = [](const pair<string, double>& a, const pair<string, double>& b) {
return a.second > b.second;
};
std::vector<std::string> content;
SplitString(file_content, '\n', &content);
for (auto line: content) {
if (line.length() == 0) continue;
std::vector<std::string> strs;
SplitString(line, ':', &strs);
if (strs.size() < 2) continue;
int uid = StringToInt(strs[0]);
std::vector<std::string> tags;
SplitString(strs[1], ',', &tags);
tag_list.clear();
for (int i = 0; i < tags.size(); i++) {
std::vector<std::string> tmp;
SplitString(tags[i], '=', &tmp);
if (tmp.size() < 2) continue;
std::string tag = tmp[0];
double weight = StringToDouble(tmp[1]);
tag_list.push_back(std::pair<string, double>(tag, weight));
}
std::sort(tag_list.begin(), tag_list.end(), cmp);
uid_tags_[uid].clear();
for (int i = 0; i < tag_list.size(); ++i) {
uid_tags_[uid].push_back(tag_list[i].first);
}
}
}
相比于修改前的，减少了一个 STL局部变量。
std::unordered_map<int, std::unordered_map<std::string, double> > uid_tags_map;
修改完毕，放到测试服务器测试，内存占用稳定到1.5G左右，多次加载不会出现增长，问题搞定，上线部署。
代码都会写，如何写出高性能，高质量的代码，这就是个技术活。
总结：
malloc()/free()作为C标准，ANSI C并没有指定它们具体应该如何实现。各个平台上（windows, mac, linux等等），调用这两个函数时，实现不一样。
在linux下，malloc()/free()的实现是由glibc库负责的。STL的内存释放，有时候并没有直接返还给os，只是返还给了分配器。
针对大量数据，谨慎大量使用STL局部变量，虽然栈上分配的，但它维护的队列是分配在heap上的，它操作的内存不一定能够即使释放，可能产生碎片。
stackoverflow 问题
ptmalloc理解
