如果你有一个64位操作系统，你有一个几乎无限的地址空间大小。 所以我的问题是，在这样的系统上释放内存很重要吗？ 即使你的内存有限，例如4GB，在一个按需分页scheme（内存只在被触摸时才带来），与释放内存相比，你得到的开销很小，这是我想的一些额外的页面交换，因为内存长时间不触摸，会自动交换。 我在这里错过了什么？ 或者我的论点有效？
实际上，如果这不是一个很大的性能问题，那么我认为它对于C / C ++程序员来说是一件好事，因为内存泄漏将不再是一个重要的问题来处理！
开销…是一些额外的页面交换…作为内存…将自动交换
自动交换到哪里？ 以太？ 页面文件是有限的，就像它们存在的存储一样。
你认为这是一个好主意，永远不要在长时间运行的服务应用程序中释放内存？
我认为这里的关键字是“虚拟的” – 其定义归结为“事实上不是”。 你有一个内存空间，事实上并不是无限的。 所有这些都随着内存越来越大的可用性而改变，这就是应用程序的范围，你可以承担内存管理的冷酷。
换句话说，如果你正在写“Hello World”，那么当然，你可以留下你的记忆垃圾。 这些日子，你可能会逃脱一个没有管理自己的记忆的小应用程序。 但是，如果你写一个设备驱动程序或一个服务守护进程，只要操作系统可以运行，那么我不需要每周关闭一次生产机器来手动清理其他人的内存泄漏。
清理之前分配的内存不只是最佳实践。
如果所有程序由于性能原因而停止释放内存块，则会看到会发生什么情况。
是的，这很重要。
这取决于应用程序。 一些应用程序正在分配很多（例如每秒几百兆字节）。 如果你认为你永远不会释放它，但使用交换空间，你将在几个小时内完成几千兆字节的交换。
查看关于垃圾收集的巨大文献，例如垃圾收集手册 。
旧的安德烈·阿佩尔的纸质垃圾收集可以比堆栈分配速度快，给你有趣的见解。
然而，你可以考虑一个稍微泄漏的垃圾收集器，那么泄漏速率只有每分钟几兆字节（GC之后），情况就不同了。
而当你只考虑短暂的应用程序时，内存泄漏确实不那么重要。 但是，只要你有长期的服务器进程，你应该关心内存，而不要释放（或重复使用）它是一个坏主意。
是的，对于寿命短的工具，比如像ls这样的命令行工具，这可能是有意义的。
例如， Busybox甚至有一个配置选项，用于控制是否像往常一样free内存，或让操作系统在退出时自动清理内存。
FEATURE_CLEAN_UP作为大小优化，busybox通常会退出，而不显式释放动态分配的内存或关闭文件。 这样可以节省空间，因为操作系统会为我们清理，但是它可能会混淆像valgrind这样的调试器，它会报告大量的内存和资源泄漏。
除非你有一个很好的理由来手动清理，否则不要启用它。
地址空间可能看起来实际上是无限的，但是当前任何一台计算机上的物理存储都不是。 操作系统（任何操作系统，不仅仅是Linux）无法知道应用程序是否使用了内存页面，除非它被明确地释放。 交换页面仍然需要磁盘空间和CPU + I / O时间来处理。
从我的经验来看，即使在极少数情况下，一些温和的营销人员设法销售超过要求的计算机系统，可用内存在一段时间之后仍然成为问题。
另外，如果你想知道如果一个应用程序停止释放内存会发生什么情况，只要看看正在泄漏/过度使用内存的应用程序，而不是直接拒绝释放它。 例如，经过几个小时的标签密集型活动后，Firefox在我的8GB系统上即将爬升到超过3GB。 我甚至不想想没有任何记忆被释放，这个数字有多高。
现在想象一下，十个应用程序同时做同样的事情 – 我一个人在我的桌面系统上没有30GB的物理或虚拟内存。 如果我的系统已经只是一个单一的Firefox实例，我担心你的建议方案会发生什么…
如果你认为在没有free()情况下可能发生的最糟糕的事情是崩溃，你应该考虑下面的情况：
底线是，释放您分配的内存。 它会保存你的理智。
如果你有一个64位操作系统，你有一个几乎无限的地址空间大小
这个你似乎错过的部分是virtual一部分。
首先，你总是“受限于”你所拥有的RAM。
我的意思是有限的如下：
在你提到的4GB的例子中，如果没有进程释放内存并继续请求新的内存，操作系统将开始使用HD来交换虚拟页面。
您将有页面错误和访问高清，这将导致过程和整个系统，如果这发生在所有进程运行（按照您认为没问题的方法）的性能开销。
因此，为了使用户拥有“可用”系统，他将不得不购买更多的RAM。
你如何看待用户如果你说，你的系统没有响应，但你只需要购买更多的内存，如16GB或32GB或…..