垃圾收集的副作用？
这可能是一个非常容易解决的问题，但我是那种只看到墙上的东西的人。 尽管垃圾收集运行时提供了内存和生命周期管理的所有好处，但是否存在由应用程序及其垃圾收集器之间的竞争条件引起的程序不确定性的明显案例？ 针对此类事情的防御性编程是否已经出现？ 当然，习惯了 RAII 的程序员在 GC 面前必须吸取教训。
This may be an eminently closeable question, but I'm the type that sees what sticks to the wall. For all of the benefits of memory and lifetime management afforded by a garbage collected runtime, have there been any notable cases of program indeterminacy caused by race conditions between an application and its garbage collector? Has a gestalt of defensive programming against this kind of thing emerged? Surely programmers accustomed to RAII must learn lessons when in the presence of GC.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
垃圾收集的问题在于它只管理内存资源。 不幸的是，程序员必须管理许多许多其他资源类型：
等等。 要成功管理这些，您确实需要 RAII 惯用法中体现的概念。
The problem with garbage collection is that it only manages memory resources. Unfortunately, programmers must manage many, many other resource types:
to name but a few. To manage those succesfully, you really need the concepts embodied in the RAII idiom.
我认为您误解了自动垃圾收集的工作原理。 即使在原则上，应用程序和正确实现的垃圾收集器之间的竞争条件也是不可能的。 垃圾收集器仅收集应用程序无法访问的对象。
由于两者中只有一个可以“拥有”给定的对象，因此不会发生竞争条件。
I think you misunderstand how automatic garbage collection works. Race conditions between the application and a correctly implemented garbage collector aren't possible, even in principle. The garbage collector only collects objects that the application can't access.
Since only one of the two can ever "own" a given object, race conditions can't occur.
当我六年左右进入 .NET 世界时，我对 GC 感到不安，我想当然地认为它应该慢得多，并且我要更加小心地分配内存以避免产生性能猪。
六年后，我可以告诉你，我的观点完全改变了！ 这些年来我只记得一次由于忘记了 .Dispose() 而发生过内存泄漏。 与 C++ 相比，C++ 每小时编码都会产生内存泄漏...;-)
我最近被迫返回 C++ 世界，我完全惊呆了！ 我曾经使用过这个并且喜欢一次吗？ 感觉我使用 C# 的效率至少是使用 C++ 的 10 倍。 最重要的是：GC 内存分配器的速度快得让我仍然不敢相信。 看一下这个问题，我得出的结论是，在我的特定情况下，.NET 版本（C# 或 C++/CLI）的执行速度是 C++ MFC 版本的 10 倍： com/questions/608370/c-string-memory-management">C++ 字符串内存分配。
我已经完全转变了——但我花了很长时间才完全接受它。
When I moved to the .NET world six years a go or so, I felt uneasy with the GC and I sort of took for granted that it should be much slower and that I was to be even more careful with my memory allocations to avoid producing performace hogs.
After six years I can tell you that my perspective has changed totally! I can only recall one time during these years that I've had a memory leak, due to a forgotten .Dispose(). Compare that to C++ where you produce a memory leak each hour of coding... ;-)
I have recenly been forced to return to the C++ world, and I'm totally flabbergasted! Did I use to work with this and like it once? It feels that I'm at least 10 times more productive in C# than in C++. And on top of that: the GC memory allocator is so blazingly fast that I still cannot believe it. Look at this question where I had to draw the conclusion that in my particular case, a .NET version (C# or C++/CLI) executed 10 times as fast as a C++ MFC version: C++ string memory allocation.
I have converted totally - but it took me a long time to fully accept it.
当我第一次开始用 CI 编程时，我必须非常有条理地使用我的 malloc 和 realloc，并且我必须释放我不使用的所有内容。 对于诸如创建二叉树之类的小型大学作业来说，这是一项简单的任务。 很简单...
现在，当我开始开发一个使用全 C 语言编写的 GUI 的应用程序时，我必须多思考，少编程，因为我必须注意可能的内存泄漏。 这变得很麻烦。 我宁愿拥有一个半成品，也不愿拥有一个半成品。
我开始转向 Java 和 C#。 我喜欢的是，我所要做的就是取消引用一个对象，垃圾收集器就会出现并为我捡起它。 我还注意到，使用 Java 的 Swing 时我的程序运行速度稍慢（如预期），但这是可以管理的。
根据我的发现，由于处理器变得越来越便宜，内存变得越来越便宜且速度更快，GUI 程序比以前消耗了更多的内存。 垃圾收集器确实有助于开发出内存泄漏问题最少的产品。 非常方便，可能会导致不良的编码习惯，但这些是可以纠正的。
编辑：
另请参阅此它可能会帮助您回答问题。 好读国际海事组织
When I first began programming in C I had to be very methodical with my malloc's and realloc's and I had to free everything I wasn't using. This was an easy task with tiny college assignments such as creating a binary tree. Simple...
Now when I started developing an application that had a GUI written in all C, I was having to think more and program less due to the fact that I have to pay attention to possible memory leaks. This was becoming a hassle. I would much rather have a half product than a half ass'd product.
I began moving over to Java and C#. I loved that all I had to do was dereference an object and the garbage collector would come along and pick it up for me. I have also noticed that my programs ran a bit slower using Java's Swing (as expected), but it was manageable.
In my findings, since processors are becoming cheaper and memory is becoming cheaper and faster, and GUI programs are consuming more memory than before. A garbage collector really helps with getting a product out that works with minimal issues with memory leaks. Really handy and can possibly lead to bad coding habits, however those can be remedied.
EDIT:
Also see this it may help you answer your questions. Good read IMO