的流内存泄漏

本文介绍了的流内存泄漏的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我有一个C ++类，将其数据写入二进制 std :: ofstream 。该类将数据存储为 boost：shared_array ，但我已经消除了这个问题。问题是在 ofstream 上调用 write（）。

问题是，它似乎泄漏内存。

当查看顶部和 free 当应用程序运行时，可执行文件本身不会继续消耗内存（由Netbeans中的内存分析器备份），但是随着时间的推移，可用的系统内存量会减少。此外，当应用程序退出此内存时不会被回收！

这是一个特别的问题，因为意图是连续写入磁盘在50MB / s左右，小时在结束。但是，一旦我们降低到大约90MB的可用系统内存，它似乎稳定，不减少任何进一步，应用程序继续运行确定。然而，它确实为其他运行的进程打破了系统，这是坏的，mmkay。

下面是一个简单的简化版本的类，悲伤。

class WritableMessage { public： WritableMessage void write（std :: ofstream * const idxStream，std :: ofstream * const dataStream）; private： IdxRecord m_idx; boost :: shared_array< char> m_data; }; ofstreams在其他地方被初始化和破坏，但基本上它们仍然是开放的，写作永远。

void WritableMessage :: write（std :: ofstream * const idxStream，std :: ofstream * const dataStream） { //调用IdxRecord来写自己（只是调用idxStream-> write（）） m_idx.write（idxStream，dataStream-> tellp（））; //这是主要的问题，因为对于每个写入，这个数据大小可以高达约2MB //。注释掉这一行删除所有与内存泄漏有关的问题 dataStream-> write（m_data.get（），m_idx.getMessageSize（））; //我希望flush清除ofstream保存的任何缓冲区， //但显然不是 idxStream-> flush（）; dataStream-> flush（）; }

解决方案

t有一个问题，这只是系统缓存工作按预期。 Linux对缓存非常敏捷，所以它将使用几乎所有的可用内存，但是每当应用程序需要更多的内存时，它会释放一些内存并授予应用程序。

I have a C++ class that writes its data out to a binary std::ofstream. The class is storing the data as a boost:shared_array but I have eliminated this as the problem. The problem is with the call to write() on the ofstream.

The issue is that it seems to leak memory. The system it is running on is CentOS 64bit, GCC 4.1.2.

When looking at top and free when the application is running the executable itself does not continue to consume memory (as backed up by the memory profiler in Netbeans), but the amount of free system memory does decrease over time. What's more, when the application exits this memory is not reclaimed!

This is a particular issue because the intention is to write out to disk continuously at around 50MB/s for hours on end. However, once we get down to around 90MB of free system memory it seems to "stabilize" and not reduce any further and the application continues to run OK. It does however screw up the system for the other running processes, which is bad, mmkay.

Below is an ever-so slightly simplified version of the class that is causing the grief.

class WritableMessage { public: WritableMessage(); void write(std::ofstream* const idxStream, std::ofstream* const dataStream); private: IdxRecord m_idx; boost::shared_array<char> m_data; };

The ofstreams are initialised and destructed elsewhere but essentially they remain open for writing "forever".

void WritableMessage::write(std::ofstream* const idxStream, std::ofstream* const dataStream) { //Call the IdxRecord to write itself (just a call to idxStream->write()) m_idx.write(idxStream, dataStream->tellp()); //This is the main issue, because this data can be up to about 2MB in size //for each write. Commenting out this line removes all issues with the memory leak dataStream->write(m_data.get(), m_idx.getMessageSize()); //I'd expect the flush to clear any buffers that the ofstream maintains, //but apparently not idxStream->flush(); dataStream->flush(); }

解决方案

It looks like you don't have a problem, and that is just the system cache working as intended. Linux is very agressive on caching, so it will use almost all your free memory for this, but whenever an application needs more memory, it will release some of that memory and grant it to the application.