Protocol Buffer解析后内存未释放问题求助

算力阿峰

2026-5-28

格式化后的代码

首先把你的代码整理成可读性更高的格式（顺便提一句：sedid_userid看起来像是seqid_userid的笔误，不影响内存问题，但可能是拼写错误）：

message LongUserIdSeqIdMapData { 
    map<int64, int32> userid_seqid = 1; 
    map<int32, int64> sedid_userid = 2; 
} 

void GetUserIdSeqId(const std::string &user_id_seq_id_file) { 
    std::ifstream infile(user_id_seq_id_file); 
    infile.seekg(0, infile.end); 
    size_t length = infile.tellg(); 
    infile.seekg(0, infile.beg); 

    auto *buffer = new char[length]; 
    infile.read(buffer, length); 

    auto long_user_id_seq_id_map = new com::jaymz::poseidon::LongUserIdSeqIdMapData(); 
    if (!long_user_id_seq_id_map->ParseFromArray(buffer, length)) { 
        std::cout << "Parse user_id_seq_id_file Fail, Please Check Your File!" << std::endl; 
    } else { 
        std::cout << "Parse user_id_seq_id_file Success" << std::endl; 
    } 

    delete[] buffer; 
    delete long_user_id_seq_id_map; 
}

内存未释放的常见原因分析

你遇到的内存占用不下降，大概率不是真的内存泄漏，而是以下几种正常机制导致的"假泄漏"：

1. 操作系统的内存延迟回收

你手动delete内存后，C++运行时会把内存归还给进程的堆管理器，但操作系统不会立刻回收物理内存——它会把这块内存标记为"可用"，留给你的程序后续分配使用，避免频繁向系统申请/释放内存的开销。此时任务管理器或top看到的物理内存占用不会立刻下降，但如果后续程序需要分配内存，会优先使用这些已释放的空间，不会再向系统申请新内存。

验证方法：多次调用GetUserIdSeqId函数，如果内存占用没有持续上涨，只是稳定在190M左右，基本就是这个原因。

2. Protobuf库的内部缓存优化

Protobuf在解析过程中，会使用内存池或全局缓存来存储临时结构、小对象等，这些内存不会在单个protobuf对象销毁时立即释放，而是被库保留下来用于后续解析操作，减少重复分配的性能损耗。这是库的正常性能优化策略，不属于泄漏。

如果确实需要强制清理，可以查看protobuf文档中是否有全局内存释放的接口（比如针对内存池的清理函数），不过大部分场景下不需要手动处理。

3. 内存碎片问题

如果你的文件接近190M，那么分配的buffer是一块连续的大内存。释放后，这块内存可能因为周围存在未释放的小块内存，无法合并成连续的大块内存归还给系统，形成内存碎片。操作系统会保留这块碎片直到程序退出，或者有足够的连续空间可以合并。

4. 真·内存泄漏？（可能性较低）

虽然你的代码看起来手动释放了所有分配的内存，但也存在隐性泄漏的可能：

比如std::ifstream的内部缓冲区未正确释放？不过infile是局部变量，函数结束时会自动销毁，资源应该会被回收。
Protobuf解析过程中是否有未被回收的动态内存？

排查方法：用专业工具检测，Linux下用valgrind --leak-check=full ./your_program，Windows下用Visual Studio内存诊断或Dr. Memory，它们会准确报告是否存在泄漏以及泄漏位置。

内容的提问来源于stack exchange，提问作者Zheming Wang