为什么c ++向量会导致oom-killer？答案

【问题标题】：Why does c++ vector cause oom-killer?为什么c ++向量会导致oom-killer？
【发布时间】：2013-01-19 09:52:20
【问题描述】：

代码需要查找和处理还没有在embedded-linux上处理的文件。 getDir 用于返回目录的排序内容。下面的代码在处理了几十个或可能超过 100 个文件后完美运行，但随后因 oom-killer 而死。这是使用 c++ 向量（循环向量内的循环向量）的坏方法吗？这种方法可能会导致 oom-killer 吗？是否有另一种方法可以在不爆炸的情况下起作用？每个向量超出范围时不应该被销毁吗？是否需要使用 new/delete 来代替？另外：用于查找内存泄漏的 valgrind 未集成在此处理器 (TI DM368) 的 sdk 中，但代码非常短且没有新语句。注意：实际代码会检查 sql 数据库中已处理的文件，但此代码仍会导致 oom-killer，其中 sql 代码已被注释掉，因此为简单起见将其省略。文件路径格式为/YYYYmmdd/HH/MMSS.SS.ext。

void getDir (string dir, vector<string> &files) {
    ...
    while ((dirp = readdir(dp)) != NULL) {
        files.push_back(string(dirp->d_name));
    closedir(dp);
    sort(files.begin(), files.end());

while (true) {
    vector<string> days;
    getDir(database_location, days);
    for (uint d=0; d<days.size(); d++) {
        vector<string> hours;
        getDir(database_location+days[d], hours);
        for (uint h=0; h<hours.size(); h++) {
            vector<string> files;
            string dir = database_location+days[d]+"/"+hours[h];
            getDir(dir, files);
            for (uint f=0; f<files.size(); f++) process(dir, files[f]);

【问题讨论】：

注释掉最后的for-loop（带有process()）会有多深？即使有几百个文件位于一百个文件路径名中的 200 个字符，包括您只查看大约 250-300K 内存的路径。您可以通过first 构建文件列表，然后在其上构建std::for_each()，将其缩短为only 包含最终全名。 IE。使用 3 层 readdir() 循环来构建文件名，一旦它们全部构建（没有中间向量）排序 that，然后通过 @ 运行它们987654325@。结果应该是相似的顺序，但对内存的影响较小。

标签： c++ vector out-of-memory embedded-linux

【解决方案1】：

Linux OOM 杀手是出了名的愚蠢。默认情况下，不要开始责怪自己的代码。
您只有三个大小合理的向量。（如果向量大小不合理，可能是因为单个目录下的文件数量也不合理）。
你不需要new/delete。

由于您不会运行多线程，因此请考虑创建三个向量 static。破解，但可能会奏效。

【讨论】：

【解决方案2】：

为了节省一些内存，您可以尝试使用string::shrink_to_fit() 和vector::shrink_to_fit，一旦每个字符串或向量达到其最终大小（但当然不能在此之前）。

另一件事可能是，不要先将hours 收集到向量中，如果那是一个很长的向量，而是在阅读时处理每个目录条目，然后以某种方式对所有内容进行排序。

【讨论】：