避免 C + + 中内存泄漏的一般准则

用户智能指针无处不在! 所有类的内存泄漏都会消失。

您需要查看智能指针，例如 Boost 的智能指针。

而不是

int main()
{
Object* obj = new Object();
//...
delete obj;
}

一旦引用计数为零，share _ ptr 将自动删除:

int main()
{
boost::shared_ptr<Object> obj(new Object());
//...
// destructor destroys when reference count is zero
}

注意我最后一点，当引用计数为零时，这是最酷的部分。因此，如果对象有多个用户，则不必跟踪对象是否仍在使用。一旦没有人引用您的共享指针，它就会被销毁。

然而，这并非灵丹妙药。虽然您可以访问基指针，但是您不希望将其传递给第三方 API，除非您对它所做的事情有信心。很多时候，在创建作用域完成之后，您的“发布”内容到其他线程以完成工作。这在 Win32中的 PostThreadMessage 中很常见:

void foo()
{
boost::shared_ptr<Object> obj(new Object());


// Simplified here
PostThreadMessage(...., (LPARAM)ob.get());
// Destructor destroys! pointer sent to PostThreadMessage is invalid! Zohnoes!
}

像往常一样，使用你的思考帽与任何工具..。

在项目中共享和了解内存所有权规则。使用 COM 规则可以获得最佳一致性([ in ]参数归调用方所有，被调用方必须复制; [ out ]参数归调用方所有，如果保留引用，被调用方必须复制; 等等)

不要手动管理内存，而是尝试在适当的地方使用智能指针。
看看 推动自由，TR1和 聪明的指点。
此外，智能指针现在是 C + + 标准 C + + 11的一部分

仔细阅读 拉尔，确保你理解它。

如果可以的话，使用 Boost share _ ptr 和标准的 C + + auto _ ptr。

当您返回 auto _ ptr 时，您是在告诉调用者，您正在向他们提供内存的所有权。

当您返回 share _ ptr 时，您是在告诉调用者您有一个对它的引用，并且它们拥有部分所有权，但这不仅仅是它们的责任。

这些语义也适用于参数。

ValGraduate 也是一个很好的工具，可以在运行时检查程序的内存泄漏。

它可以在大多数风格的 Linux (包括 Android)和 Darwin 上使用。

如果您用来为您的程序编写单元测试，那么您应该养成在测试中系统地运行 val弓形测试的习惯。它可以在早期阶段避免许多内存泄漏。在一个完整的软件中，通常在简单的测试中更容易找到它们。

当然，这个建议对于任何其他内存检查工具都是有效的。

在 C + + 中内存管理中流行的一种技术是 拉尔。基本上，您使用构造函数/析构函数来处理资源分配。当然，由于异常安全的原因，C + + 中还有一些其他令人讨厌的细节，但是基本思想非常简单。

这个问题通常可以归结为所有权问题。我强烈推荐阅读 Scott Meyers 的《有效的 C + + 系列》和 Andrei Alexandrescu 的《现代 C + + 设计》。

如果你不能/不能使用智能指针(虽然这应该是一个巨大的红色标志) ，输入你的代码:

allocate
if allocation succeeded:
{ //scope)
deallocate()
}

这是显而易见的，但是一定要输入 之前，在作用域中输入任何代码

另外，如果有一个 std 库类(例如 Vector) ，不要使用手动分配的内存。如果您违反了该规则，请确保您有一个虚拟析构函数。

任何函数只有一个返回值，这样你就可以在那里进行释放，而且永远不会错过它。

否则很容易犯错:

new a()
if (Bad()) {delete a; return;}
new b()
if (Bad()) {delete a; delete b; return;}
... // etc.

如果要手动管理内存，有两种情况:

1. 我创建了这个对象(可能是间接地，通过调用一个分配新对象的函数) ，我使用它(或者我调用的函数使用它) ，然后释放它。
2. 有人给了我推荐信，所以我不应该释放它。

如果您需要打破这些规则中的任何一条，请记录下来。

它完全是关于指针所有权的。

您可以拦截内存分配函数，并查看是否有一些内存区域在程序退出时没有释放(尽管它不适合于应用程序的 所有)。

也可以在编译时通过替换运算符 new 和 delete 以及其他内存分配函数来完成。

例如，检入这个 工地[在 C + + 中调试内存分配] 注意: 删除操作符也有类似的技巧:

#define DEBUG_DELETE PrepareDelete(__LINE__,__FILE__); delete
#define delete DEBUG_DELETE

您可以在一些变量中存储文件的名称，重载删除操作符将知道从哪个位置调用该文件。这样就可以跟踪程序中的每个 delete 和 malloc。在内存检查序列的最后，你应该能够报告哪些分配的内存块没有被“删除”，通过文件名和行号来标识它，我猜这就是你想要的。

你也可以在 Visual Studio 下尝试一些类似 界限检查器的东西，这很有趣，也很容易使用。

呸，你们这些年轻人和你们的新式垃圾收集工。

对“所有权”有非常严格的规定——哪个对象或软件的一部分有权删除该对象。清除注释和明智的变量名，使指针“拥有”或是“只看不碰”时显而易见。为了帮助决定谁拥有什么，在每个子例程或方法中尽可能遵循“三明治”模式。

create a thing
use that thing
destroy that thing

有时候在不同的地方创造和毁灭是必要的，我认为很难避免这一点。

在任何需要复杂数据结构的程序中，我使用“ owner”指针创建一个包含其他对象的严格明确的对象树。此树为应用程序域概念的基本层次结构建模。例如一个3D 场景拥有对象，灯光，纹理。在渲染结束时，程序退出，有一个清晰的方式来摧毁一切。

当一个实体需要访问另一个实体时，许多其他指针被定义为需要，以便扫描数组或其他任何东西; 这些是“仅仅查看”。对于3D 场景的例子-一个对象使用纹理，但不拥有; 其他对象可能使用相同的纹理。对象的破坏会调用对任何纹理的破坏。

是的，这很费时，但这就是我的工作。我很少有内存泄漏或其他问题。但后来我在有限的高性能科学、数据采集和绘图软件领域工作。我不经常处理银行和电子商务、事件驱动的 GUI 或高度网络化的异步混乱等事务。也许新奇的方法在那里有优势！

我们将所有的分配函数封装在一个图层中，该图层在前面附加一个简短的字符串，在末尾附加一个哨兵标志。例如，您可以调用“ myalloc (pszSomString，iSize，iAlign) ; 或者 new (“ description”，iSize) MyObject () ; 它在内部分配指定的大小加上足够的空间来放置头文件和前哨文件。当然，对于非调试构建，不要忘记注释掉它！做到这一点需要更多的内存，但好处远远大于成本。

这有三个好处-首先，它允许您轻松快速地跟踪哪些代码正在泄漏，通过快速搜索在某些“区域”中分配的代码，但是当这些区域应该已经释放时却没有清理。通过检查以确保所有哨兵完好无损，检测边界何时被覆盖也很有用。当我们试图找到那些隐藏得很好的崩溃或数组错误时，这已经为我们节省了很多次。第三个好处是跟踪记忆的使用情况，看看谁是大玩家——例如，当“声音”比你预期的要占用更多的空间时，MemDump 中的某些描述的整理会告诉你。

已经有很多关于如何避免泄漏的方法，但是如果您需要一个工具来帮助您跟踪泄漏，那么可以看一下:

• VS 下的 BoundsChecker
• 来自 FluidStudio 的 MMGR C/C + + lib Http://www.paulnettle.com/pub/fluidstudios/memorymanagers/fluid_studios_memory_manager.zip (它覆盖分配方法并创建分配、泄漏等报告)

C + + 在设计时就考虑到了 RAII，我认为没有比 C + + 更好的方法来管理内存了。 但是要小心，不要在本地作用域上分配非常大的块(如缓冲区对象)。它可能导致堆栈溢出，如果在使用该块时边界检查存在缺陷，则可以覆盖其他变量或返回地址，这将导致各种安全漏洞。

还有一些人首先提到了避免内存泄漏的方法(比如智能指针)。但是一旦出现内存问题，分析和内存分析工具通常是跟踪内存问题的唯一方法。

这是一个非常好的免费网站。

使用 拉尔

• 忘记垃圾收集 (改为使用 RAII)。请注意，甚至垃圾收集器也可能泄漏(如果你忘记在 Java/C # 中“ null”一些引用) ，垃圾收集器不会帮助你释放资源(如果你有一个对象获得了一个文件的句柄，文件将不会被自动释放时，对象将超出范围，如果你不手动做它在 Java 中，或使用“处理”模式在 C #)。
• 忘掉“每个函数返回一个”规则。这是一个很好的避免泄漏的 C 建议，但是在 C + + 中它已经过时了，因为它使用了异常(改用 RAII)。
• 虽然 “三明治模式”是一个很好的 C 建议，但是由于使用了异常，因此它是 在 C + + 中已经过时了(使用 RAII 代替)。

void doSandwich()
{
T * p = new T() ;
// do something with p
delete p ; // leak if the p processing throws or return
}


void doRAIIDynamic()
{
std::auto_ptr<T> p(new T()) ; // you can use other smart pointers, too
// do something with p
// WON'T EVER LEAK, even in case of exceptions, returns, breaks, etc.
}


void doRAIIStatic()
{
T p ;
// do something with p
// WON'T EVER LEAK, even in case of exceptions, returns, breaks, etc.
}