rpa*_*abi 17 garbage-collection
大多数现代语言都内置了垃圾收集(GC).例如Java,.NET语言,Ruby等.事实上,GC以多种方式简化了应用程序开发.
我很想知道用GCed语言编写应用程序的限制/缺点.假设GC实施是最佳的,我只是想知道我们可能会受到GC的限制,无法做出一些优化决策.
Ree*_*sey 23
在我看来,使用垃圾收集器的主要缺点是:
非确定性的资源清理.有时,说"我已经完成了这件事,我现在想要它清理"是很方便的.使用GC,这通常意味着强制GC清理所有内容,或者只是等到它准备就绪 - 这两者都会剥夺您作为开发人员的控制权.
由GC的非确定性操作引起的潜在性能问题.当GC收集时,常见的是(小)挂起等.这对于诸如实时模拟或游戏之类的事情尤其成问题.
Aid*_*ell 12
从C程序员那里得到它......它是关于成本/收益和适当的使用
诸如三色/标记和扫描之类的垃圾收集算法通常在"丢失"的资源和被释放的物理资源之间存在显着的延迟.在某些运行时,GC实际上会暂停执行程序以执行垃圾收集.
作为一名长期的C程序员,我可以告诉你:
a)手动free()垃圾收集很难 - 这是因为人类放置free()调用的错误率通常高于GC算法.
b)手动free()垃圾收集成本时间 - 调试所花费的时间是否超过GC的毫秒暂停？如果您正在编写游戏而不是嵌入式内核,那么使用垃圾收集可能会有所帮助.
但是,当您无法承受运行时缺点(正确的资源,实时约束)时,执行手动资源分配可能会更好.这可能需要一些时间,但可以100%有效.
试着想象用Java编写的操作系统内核？或者在带有GC的.NET运行时...只需看看JVM在运行简单程序时累积了多少内存.我知道项目存在这样......他们只是让我觉得有点不舒服.
请记住,我的linux机箱今天使用3GB内存的功能与它多年前拥有512MB内存时相同.唯一的区别是我有mono/jvm/firefox等运行.GC的商业案例很明确,但它仍然让我很不舒服.
好书:
对于.NET,我可以看到两个缺点.
1)人们认为GC最了解,但情况并非总是如此.如果您进行某些类型的分配,您可以让自己体验一些非常讨厌的程序死亡,而无需直接调用GC.
2)大于85k的物体进入LOH或大物体堆.该堆目前从未被压缩,因此,当LOH实际上没有足够的压缩以供您进行另一次分配时,您的程序可能会遇到内存不足异常.
我在这个问题中发布的代码中显示了这两个错误: