这可能是一个非常容易解决的问题,但我是那种看到什么东西粘在墙上的人。对于垃圾收集运行时提供的内存和生命周期管理的所有好处,是否存在由应用程序与其垃圾收集器之间的竞争条件导致的程序不确定性的明显案例?是否出现了针对此类事物的防御性编程格式塔?当然,习惯于 RAII 的程序员在 GC 面前必须吸取教训。
4 回答
垃圾收集的问题在于它只管理内存资源。不幸的是,程序员必须管理很多很多其他资源类型:
- 文件和套接字句柄
- 数据库连接
- 同步对象
- gui资源
这仅仅是列举的一小部分。要成功管理这些,您确实需要 RAII 习语中体现的概念。
我认为您误解了自动垃圾收集的工作原理。应用程序和正确实现的垃圾收集器之间的竞争条件是不可能的,即使在原则上也是如此。垃圾收集器只收集应用程序无法访问的对象。
由于两者中只有一个可以“拥有”给定对象,因此不会发生竞争条件。
大约六年前我搬到 .NET 世界时,我对 GC 感到不安,我理所当然地认为它应该慢得多,而且我要更加小心我的内存分配以避免产生表演狂。
六年后我可以告诉你,我的观点已经完全改变了!这些年来我只能回忆起一次内存泄漏,原因是忘记了 .Dispose()。将其与 C++ 进行比较,在 C++ 中,您每小时编码都会产生内存泄漏...... ;-)
我最近被迫回到 C++ 世界,我完全惊呆了!我曾经使用过这个并喜欢它吗?感觉我在 C# 中的工作效率至少是 C++ 的 10 倍。最重要的是:GC 内存分配器速度如此之快,以至于我仍然无法相信。看看这个问题,我不得不得出结论,在我的特定情况下,.NET 版本(C# 或 C++/CLI)的执行速度是 C++ MFC 版本的 10 倍:C++ string memory allocation。
我已经完全转变了——但我花了很长时间才完全接受它。
当我第一次开始在 CI 中编程时,我必须非常有条理地使用我的 malloc 和 realloc,并且我必须释放所有我不使用的东西。这是一项简单的任务,只需完成一些小的大学作业,例如创建二叉树。简单的...
现在,当我开始开发一个使用全 C 语言编写的 GUI 的应用程序时,我不得不多思考少编程,因为我必须注意可能的内存泄漏。这变得很麻烦。我宁愿有一半的产品而不是一半的产品。
我开始转向 Java 和 C#。我喜欢我所要做的就是取消引用一个对象,然后垃圾收集器会过来为我捡起它。我还注意到,使用 Java 的 Swing(如预期的那样)我的程序运行速度有点慢,但它是可以管理的。
在我的发现中,由于处理器变得更便宜,内存变得更便宜和更快,而且 GUI 程序比以前消耗更多的内存。垃圾收集器确实有助于使产品的内存泄漏问题最小化。真的很方便,可能会导致不良的编码习惯,但是可以补救。
编辑:
另请参阅此内容,它可能会帮助您回答您的问题。好读的海事组织