我应该在异常终止时释放分配的内存吗？
我的程序（文本模式网络浏览器）正在动态分配内存。
当然，我会在运行时释放不需要的块。而且我会在正常终止之前释放所有内容 - 这样内存泄漏检查器就不会给我误报（并且在需要进行重大重构时保持灵活性）。
现在，我不做的是在异常终止之前释放内存。 （目前，我的程序在信号和 malloc/realloc 失败后终止。）
我的问题是：您认为这种风格不好吗？我应该释放异常终止吗？
My program (a text-mode web browser) is dynamically allocating memory.
I do free unneeded blocks during runtime, of course. And I do free everything before normal termination - so that memory leak checkers won't give me false positives (and to be flexible should major refactorings ever become needed).
Now, what I do not do is freeing memory before abnormal termination. (Currently, my program terminates on signals and after failed mallocs/reallocs.)
My question is: Do you consider this bad style? Should I free on abnormal termination?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
不，我认为在程序终止后简单地放弃并让操作系统回收内存是完全可以接受的。我认为如果这确实是一种异常情况并且意图是让程序终止，那么行为良好的程序应该简单地清理所有磁盘资源/锁，并尽快退出。
No. I think it's perfectly acceptable to simply throw up your hands and let the OS reclaim the memory after the program terminates. I think if this is truly an abnormal situation and the intention is to have the program terminate, then a well-behaved program should simply clean up any disk resources/locks, and exit as quickly as possible.
在我看来，没有必要在崩溃时释放内存。当你的进程终止时，操作系统将回收内存，所以你所要做的就是退出。
另一方面，其他资源（例如打开的文件）应该关闭或至少刷新——如果没有，它们可能不会因为缓冲而被存储/存储不完整。
In my opinion freeing the memory on crash isn't necessary. When your process terminates, OS will reclaim the memory, so all you have to do is exit.
On the other hand, other resources (e.g. open files) should be closed or at least flushed -- if not, they may not be stored/stored incomplete because of the buffering.
除了避免泄漏检测工具中的误报之外，您不需要在正常终止时回收内存。
如果您的程序异常终止，根据原因，您可能会发现无法释放内存。例如，由损坏的堆产生的 SIGSEGV 意味着即使尝试释放堆上的其他内容也可能是无望的操作。
You don't need to reclaim memory on normal termination except to obviate false positives in leak detecting tools.
If your program terminates abnormally, depending on the cause, you may find that you can't free memory. For instance, a SIGSEGV resulting from a corrupted heap means that even trying to free other stuff on the heap maybe a hopeless exercise.
如果内存块是由其他进程分配的，则进程的异常终止不会导致其他进程无法使用这些内存块（实际上意味着它们是空闲的）。
我们使用操作系统指令分配/释放内存，以便无错误的操作系统跟踪每个进程的内存块并将它们转换为连续的虚拟内存空间。当进程死亡时，操作系统加载程序会发出信号，并且所有内存都会被调用。当进程共享内存时，事情会变得复杂。
对等进程，如果不是由您的进程派生/启动/分叉（例如，考虑为许多进程提供服务以访问多媒体资源的外部组件），则可能已创建内存（例如缓冲区）来为您的进程提供服务。根据这些外部组件的所有权策略，该内存可能不会在服务进程死亡时释放。
我建议您尝试审核异常终止场景之前和之后提交的所有内存。
Abnormal termination of your process does not lead to memory blocks that cannot be used by other processes (effectively meaning they are free), if they were allocated by it.
We allocate/free memory using OS-directives so that a non-buggy OS keeps track of mem chunks for each process and translates them into a contiguous virtual memory space. Upon a process-death, OS loader signals it, and all memory gets recalled. Things get complicated when processes share memory.
Peering processes, if not derived/launched/forked by you process (e.g. consider an external component serving many processes to access multimedia resources), may have created memory (e.g. buffer) to serve your process. Depending on the policy of ownership of these external components, that memory might not be free upon served-process death.
I advise you to try audit all memory committed before and after abnormal termination scenarios.
不会，除非你的程序总是异常终止。 :)
不管怎样，操作系统在释放它方面做得很好。事实上，许多懒惰的程序员甚至懒得通过正常终止来释放东西——但这使得检测其他内存泄漏变得困难（那些真正的问题）。
No, unless your program always terminates abnormally. :)
Anyway, the OS does a fine job freeing it up. In fact many lazy programmers don't even bother freeing things up with normal termination - but this makes detecting other memory leaks difficult (the ones that are a real problem).
仅当您的操作系统在程序终止时不回收内存时。 DOS 及其“粘性内存”就是此类操作系统的一个例子。在大多数现代操作系统上，异常终止时不 free() 不是问题。
Only if your OS doesn't reclaim memory on program termination. DOS and its 'sticky memory' is an example of such an OS. On most modern OS not free()'ing on abnormal termination is a non-issue.
在异常终止时，您希望进行尽可能少的处理。最大限度地减少对中止过程的修改意味着您可以尽可能接近中止的原因，并且任何进一步的处理都可以被视为“污染”过程，从而使其更难以调试。
On abnormal termination you want to do as little processing as possible. Minimizing tinkering with the aborting process will mean you can get to as close to the reason for the abort as possible and any further processing can be seen as "contaminating" the process thus making it more difficult to debug.