最佳内存泄漏定义
我觉得开发人员谈论内存泄漏，但当你问他们这意味着什么时，很多人都不知道。 为了防止出现这些情况，让我们决定一种情况。
请不要维基百科定义...
你对a的最佳定义是什么 内存泄漏以及什么是最好的方法 来阻止他们？
I feel like developers talk about memory leaks but when you ask them what that means many have no idea. To prevent these situations, let's decide on one.
Please no Wikipedia definitions...
What is your best definition of a
memory leak and what is the best way
to prevent them?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
有两个定义（至少对我来说）：
简单定义： 未能释放无法访问的内存，在分配过程执行期间任何进程都无法再分配该内存。 这主要可以通过使用 GC（垃圾收集）技术或通过自动化工具检测来解决。
微妙的定义：无法释放程序正常运行不再需要的可访问内存。 使用自动化工具或不熟悉代码的程序员几乎不可能检测到这一点。 虽然从技术上讲这不是泄漏，但它与天真的泄漏具有相同的含义。 这不仅仅是我一个人的想法。 您可能会遇到用垃圾收集语言编写的项目，但仍然在其变更日志中提到修复内存泄漏。
There are two definitions (at least for me):
Naive definition: Failure to release unreachable memory, which can no longer be allocated again by any process during execution of the allocating process. This can mostly be cured by using GC (Garbage Collection) techniques or detected by automated tools.
Subtle definition: Failure to release reachable memory which is no longer needed for your program to function correctly. This is nearly impossible to detect with automated tools or by programmers who are not familiar with the code. While technically it is not a leak, it has the same implications as the naive one. This is not my own idea only. You can come across projects that are written in a garbage collected language but still mention fixing memory leaks in their changelogs.
分配的内存无法使用，因为对其的引用已丢失。
Allocated memory that cannot be used because the reference to it has been lost.
定义：分配内存后未能释放内存。
Definition: Failure to release memory after allocation.
内存资源被分配但不再需要时未正确释放的过程，通常是由于不良的编码实践而引入的。
某些语言内置了一些方法来帮助防止它们，尽管避免它们的最佳方法是通过勤奋观察代码执行路径和代码审查。 保持方法简短且目的明确有助于保持资源使用的严格范围，并且也不易在混乱中迷失方向。
The process in which memory resource are allocated and not properly released once no longer required, often introduced through bad coding practices.
There are built in ways in some languages to help prevent them, although the best way to avoid them is through diligent observation of code execution paths and code reviews. Keeping methods short and singularly purposed helps to keep resource usage tightly scoped and less prone to get lost in the shuffle, as well.
有两种方法可以定义内存泄漏。
首先，如果数据在不再有任何引用时未被释放，则该数据将无法访问（除非您有一些损坏的指针或读取了缓冲区中的数据或其他内容）。 基本上，如果您不释放/删除堆上分配的数据，它就会变得不可用并且只会浪费内存。
可能存在指针丢失但数据仍然可以访问的情况。 例如，如果将指针存储在 int 中，或者存储指针的偏移量（使用指针算术），您仍然可以取回原始指针。
在第一个定义中，数据由垃圾收集器处理，垃圾收集器跟踪对数据的引用数量。
其次，如果上次使用时未释放/删除内存，则本质上会泄漏。 它可能会被引用，并立即免费，但不这样做就犯了错误。 可能有一个有效的原因（例如，在析构函数有一些奇怪的副作用的情况下），但这表明程序设计不好（在我看来）。
第二种类型的内存泄漏经常发生在编写使用文件 IO 的小程序时。 您打开文件，写入数据，但完成后不要关闭它。 FILE* 可能仍在范围内，并且可以轻松关闭。 同样，这样做可能有某种原因（例如锁定其他程序的写入访问），但对我来说，这是糟糕设计的标志。
在第二个定义中，数据不由垃圾收集器处理，除非编译器/解释器足够聪明（或愚蠢），知道它不会再被使用，并且释放数据不会导致任何副作用。
There are two ways a memory leak may be defined.
First, if data is not freed when there are no longer has any references to it, that data is unreachable (unless you have some corrupt pointer or read past the data in a buffer or something). Basically, if you don't free/delete data allocated on the heap, it becomes unusable and simply wastes memory.
There may be cases where a pointer is lost but the data is still accessible. For example, if you store the pointer in an int, or store an offset to the pointer (using pointer arithmetic), you can still get the original pointer back.
In this first definition, data is handled by garbage collectors, which keep track of the number of references to the data.
Second, memory is essentially leaked if it is not freed/deleted when last used. It may be referenced, and immediately free-able, but the mistake has been made not to do so. There may be a valid reason (e.g. in the case where a destructor has some weird side effect), but that indicates bad program design (in my opinion).
This second type of memory leaking often happens when writing small programs which use file IO. You open the file, write your data, but don't close it once you're done. The FILE* may still be within scope, and easily closeable. Again, there may be some reason for doing this (such as locking write access by other programs), but to me that's a flag of bad design.
In this second definition, data is not handled by garbage collectors, unless the compiler/interpreter is smart (or dumb) enough to know it won't be used any longer, and this freeing the data won't cause any side effects.
w：
w:
不再需要时不会释放的内存，并且不再“可访问”。 例如，在非托管代码中，如果我使用“new”来实例化一个对象，但当我完成它时我不使用“delete”（并且我的指针超出了范围或其他东西）。
防止它们的最佳方法可能取决于您询问的对象以及您使用的语言。 当然，垃圾收集是一个很好的解决方案，但是可能会产生一些与此相关的开销，这不是什么大问题，除非您主要关心性能。 同样，垃圾收集可能并不总是可用，具体取决于您使用的语言。
或者，您可以确保有适当的删除和/或析构函数。 还有很多方法和工具可以检测内存泄漏，但这取决于您使用的语言和/或 IDE。
Memory that is not deallocated when it is no longer needed, and is no longer "reachable". For instance, in unmanaged code, if I use "new" to instantiate an object, but I don't use "delete" when I'm done with it (and my pointer has gone out of scope or something).
The best way to prevent them probably depends on who you ask and what language you are using. Garbage collection is a good solution for it, of course, but there may be some overhead associated with this, which isn't a big deal unless you performance is your primary concern. Garbage collection may not always be available, again, depending on the language you are using.
Alternatively, you can make sure you have the appropriate deletes and/or destructors in place. There's a lot of methods and tools to detect memory leaks as well, but this will depend on the language and/or IDE you are using.
内存泄漏：未能释放之前不再需要的内存：
防止内存泄漏的最佳方法：尽快释放内存不再需要。
Memory Leak: Failing to free memory that you no longer need before either:
Best way to prevent Memory Leaks: Free memory as soon as it is no longer needed.
以下是一些防止/检测内存泄漏的技术：
根据内存消耗考虑您的算法。其他受访者提到您不必丢失指向已分配项的指针泄漏内存。 即使您的实现包含零指针错误，如果您在实际需要分配的项目后很长时间仍保留它们，您仍然可能会有效地泄漏内存。
分析您的应用程序。您可以使用内存调试器工具（例如 Valgrind 或 Purify）来查找泄漏。
分析
黑盒测试。在向编译的代码提供大量数据集或允许其长时间运行后，观察编译的代码会发生什么情况。 查看其内存占用是否有无限制增长的趋势。
Here are some techniques for preventing / detecting memory leaks:
Consider your algorithm in terms of memory consumption. Other respondents have mentioned the fact that you don't have to lose the pointer to an allocated item to leak memory. Even if your implementation contains zero pointer bugs, you can still effectively leak memory if you hold onto allocated items long after you actually need them.
Profile your application. You can use memory debugger tools like Valgrind or Purify to find leaks.
Black-box testing. Watch what happens to your compiled code after you feed it large data sets, or allow it to run for long periods of time. See if its memory footprint has a tendency to grow without limit.
这里给出的所有定义（在我写这篇文章时，我们已经得到了更好的答案）都无法解决一种边界情况：
您有一个在创建时分配内存的单例，并且只要程序正在运行，该内存通常就会被保留尽管目前的使用已经完成，但不知道未来是否会使用。 这样做通常是因为重新创建它的开销。
根据“完成后无法释放”标准，这将被视为泄漏，并且我看到泄漏报告工具将此类事件称为泄漏，因为内存仍在使用中。 （事实上，代码可能不包含能够清理对象的代码。）
但是，我之前在编译器库中遇到过这种性质的代码，即使重新创建对象的成本并不是那么高。
漏还是不漏？
All the definitions given here (at the time I wrote this, we have gotten better answers since) fail to address one borderline case:
You have a singleton that allocates memory upon creation and this memory is normally held as long as the program is running even though the current use is done and it's unknown whether any future use will ever be made or not. This is generally done because of the overhead of recreating it.
By the "fail to free when done with it" standard this would be considered a leak and I've seen leak-reporting tools call such things leaks as the memory was still in use. (And in fact the code may not contain code capable of cleaning the object up.)
However, I have encountered code of this nature in compiler libraries before even when the cost of recreating the object isn't all that great.
Leak or not?
编辑：这个答案是错误的。 我将其作为一个例子，说明您很容易在自认为非常了解的事情上犯错误。感谢所有指出我错误的人。
内存泄漏是： 编程错误。 您的软件从系统借用一些内存并使用它，然后在完成后无法将其返回给系统。 这意味着在系统重新启动之前，任何其他程序都无法使用该特定的内存块。 许多此类泄漏可能会耗尽所有可用内存，从而导致系统完全无用。
为了防止内存泄漏，请练习 RIIA，并始终测试您的软件。 有很多工具可用于此任务。
edit: This answer is wrong. I'm leaving it up as an example of how easy it is to be mistaken about something you think you know very well. Thank you to everyone who pointed out my mistake.
A memory leak is: A programming error. Your software borrows some memory from the system, uses it, and then fails to return it to the system when it has finished. This means that that particular chunk of memory can never be used by any other programs until the system is rebooted. Many such leaks could use up all of the available memory, resulting in a completely useless system.
To prevent memory leaks, practice RIIA, and always test your software. There are plenty of tools available for this task.