这可能是一个非常容易接近的问题，但我是那种看到什么坚持墙的类型。对于垃圾收集运行时提供的内存和生命周期管理的所有好处，是否存在由应用程序与其垃圾收集器之间的竞争条件引起的程序不确定性的任何显着情况？是否出现了针对此类事情的防御性编程格式？当然，习惯于RAII的程序员必须在有GC的情况下吸取教训。
答案 0 :(得分：7)
垃圾收集的问题在于它只管理内存资源。不幸的是，程序员必须管理许多其他资源类型：
仅举几例。为了成功地管理这些，你真的需要RAII成语中体现的概念。
答案 1 :(得分：6)
我认为你误解了自动垃圾收集的工作原理。即使在原则上，也不可能在应用程序和正确实现的垃圾收集器之间的竞争条件。垃圾收集器仅收集应用程序无法访问的对象。
由于两者中只有一个可以“拥有”给定的物体，因此不会发生竞争条件。
答案 2 :(得分：5)
当我六年左右搬到.NET世界时，我对GC感到不安，我觉得理所当然地认为它应该慢得多，而且我对内存分配更加小心避免生产性能猪。
六年后，我可以告诉你，我的观点完全改变了！由于忘记了.Dispose（），我在这些年里只记得一个时间，因为我有内存泄漏。将其与C ++进行比较，在C ++中，每小时编码产生一次内存泄漏......; - ）
我已经被迫回到C ++世界，我完全被惊呆了！我使用过这个和喜欢一次吗？ 感觉我在C＃中的效率至少比C ++高10倍。最重要的是：GC内存分配器非常快，我仍然无法相信它。看看这个问题，我必须得出结论，在我的特定情况下，.NET版本（C＃或C ++ / CLI）的执行速度是C ++ MFC版本的10倍：C++ string memory allocation。
我完全改变了 - 但我花了很长时间才完全接受它。
答案 3 :(得分：0)
当我第一次开始使用C编程时，我必须非常有条理地使用我的malloc和realloc，并且我必须释放我没有使用的所有内容。这是一项简单的任务，只需要很少的大学作业，例如创建二叉树。简单...
现在，当我开始开发一个具有用C语言编写的GUI的应用程序时，由于我必须注意可能的内存泄漏这一事实，我不得不多思考并编程。这变得很麻烦。我宁愿拥有半成品而不是半成品。
我开始转向Java和C＃。我喜欢我所要做的就是取消引用一个物体，垃圾收集器就会出现并为我挑选它。我也注意到使用Java的Swing（正如预期的那样）我的程序运行速度有点慢，但它是可管理的。
在我的研究结果中，由于处理器变得越来越便宜，内存变得越来越便宜和快速，并且GUI程序比以前消耗更多的内存。垃圾收集器确实有助于获得一个产品，它可以解决内存泄漏问题。非常方便，可能会导致糟糕的编码习惯，但这些可以得到纠正。
编辑：
Also see this它可以帮助您回答您的问题。好读IMO