垃圾收集的副作用？

这可能是一个非常容易接近的问题,但我是那种看到什么坚持墙的类型.对于垃圾收集运行时提供的内存和生命周期管理的所有好处,是否存在由应用程序与其垃圾收集器之间的竞争条件引起的程序不确定性的任何显着情况？是否出现了针对此类事情的防御性编程格式？当然,习惯于RAII的程序员必须在有GC的情况下吸取教训.

垃圾收集的问题是它只管理内存资源.不幸的是,程序员必须管理许多其他资源类型:

文件和套接字句柄

数据库连接

同步对象

gui资源

这仅仅是列举的一小部分.为了成功地管理这些,你真的需要RAII成语中体现的概念.

我想你误解了自动垃圾收集的工作原理.即使在原则上,也不可能在应用程序和正确实现的垃圾收集器之间的竞争条件.垃圾收集器仅收集应用程序无法访问的对象.

由于两者中只有一个可以"拥有"给定的物体,因此不会发生竞争条件.

六年左右我搬到.NET世界的时候,我对GC感到不安,我觉得它应该慢得多,而且我要更加小心我的内存分配以避免产生表演猪.

六年后,我可以告诉你,我的观点完全改变了!在这些年里,我只记得有一次由于忘记了.Dispose()而导致内存泄漏.与C++相比,每小时编码会产生内存泄漏... ;-)

我已经被迫回到C++世界,我完全被惊呆了!我是否习惯使用它并喜欢它一次？这感觉,我在C#比C中的至少10倍以上的生产++.最重要的是:GC内存分配器非常快,我仍然无法相信它.看看这个问题,我必须得出结论,在我的特定情况下,.NET版本(C#或C++/CLI)的执行速度是C++ MFC版本的10倍:C++字符串内存分配.

我完全改变了 - 但我花了很长时间才完全接受它.