因此,如果我理解得很好,垃圾收集会自动释放程序不再使用的对象.像java中的垃圾收集器.
我听说像C这样的语言不支持垃圾收集,程序可能会有内存泄漏并随后耗尽内存.
那么程序员在不支持垃圾收集的C语言中所犯的错误是什么？我猜不会在它们不再使用后解除分配对象.但是由于缺少垃圾收集器,这些是我们可以做的唯一错误吗？
戴上你需要的东西
不解除你不再需要的东西(因为你没有跟踪分配/使用/释放)
重新分配已经存在的事物的新实例(不能正确跟踪的副作用)
取消分配你已经释放的东西
取消分配不存在的东西(空指针)
可能还有更多.重点是:管理内存很棘手,最好使用某种跟踪机制和分配/释放抽象来处理.因此,您可能也会将其内置到您的语言中,因此它可以让您轻松愉快.手动内存管理不是世界末日 - 它肯定是可行的 - 但是现在,除非您正在编写实时代码,硬件驱动程序或(可能)可能的最新超优化核心代码游戏,然后手动努力是不值得的,除了作为学术练习.
IMO,垃圾收集语言与非垃圾收集语言的问题存在互补问题.对于每个问题,都存在非GC特征错误和GC特征错误 - 非GC程序员责任和GC程序员责任.
GC程序员可能认为他们免除了释放对象的责任,但是对象拥有除内存之外的资源 - 通常需要及时释放资源以便可以在其他地方获取 - 例如文件句柄,记录锁,互斥锁. ..
如果一个非GC程序员有一个悬空引用(并且通常一个不是bug,因为某些标志或其他状态会将其标记为不使用),GC程序员会有内存泄漏.因此,非GC程序员负责确保适当地调用free/delete,GC程序员负责确保不需要的引用被清零或以适当的方式处理.
这里声称智能指针不处理垃圾循环.这不一定是真的 - 有一些引用计数方案可以打破周期并确保及时处理垃圾内存,并且至少有一个Java实现使用(并且仍然可以)引用计数方案,它可以很容易地实现C++中的智能指针方案.
参考计数系统中的并发周期收集
当然,通常不会这样做 - 部分原因是你可能只使用GC语言,但也部分使用IMO,因为它会破坏C++中的关键约定.你看,许多C++代码 - 包括标准库 - 在很大程度上依赖于资源分配初始化(RAII)约定,并依赖于可靠和及时的析构函数调用.在任何处理循环的GC中,你根本就不能拥有它.当打破垃圾循环时,你无法知道哪个析构函数首先调用而没有任何依赖性问题 - 它甚至可能不可能,因为可能存在更多的循环依赖,而不仅仅是内存引用.解决方案 - 在Java等中,无法保证将调用终结器.垃圾收集只收集一种非常特殊的垃圾 - 内存.所有其他资源必须手动清理,因为它们应该是Pascal或C,并且没有可靠的C++风格析构函数的优势.
最终结果 - 许多在C++中"自动化"的清理必须在Java,C#等手动完成.当然"自动化"需要引号,因为程序员负责确保为任何堆分配适当地调用删除对象 - 但在GC语言中,有不同但互补的程序员职责.无论哪种方式,如果程序员未能正确处理这些职责,您就会遇到错误.
[ 编辑 - 有些情况下,Java,C#等显然可靠(如果不一定及时)清理,文件就是这样的一个例子.这些是不能发生引用循环的对象 - 因为(1)它们根本不包含引用,(2)有一些静态证据表明它包含的引用不能直接或间接地导回到同一类型的另一个对象,或者(3)运行时逻辑确保尽管链/树/任何可能的循环都不是.对于资源管理对象而言,情况(1)和(2)非常常见,而不是数据结构节点 - 可能是通用的.但编译器本身无法合理地保证(3).因此,虽然编写最重要的资源类的标准库开发人员可以确保为那些人提供可靠的清理,但一般规则仍然是无法保证GC的非内存资源的可靠清理,这可能会影响应用程序定义的资源. ]
坦率地说,从非GC切换到GC(或反之亦然)不是魔术棒.它可能会使通常的可疑问题消失,但这只意味着你需要新的技能组来防止(和调试)一整套新的嫌疑人.
一个优秀的程序员应该通过你们身边的人,并学会处理这两个问题.
那么,你可以犯的错误是:
不要解除你不需要的东西
解除你需要的东西
有可以使其他错误,但这些都是相关的那些具体到垃圾收集.
京公网安备 11010802040832号 | 京ICP备19059560号-6 