什么时候你可能不想使用垃圾收集？

垃圾收集自LISP早期就已存在,现在 - 几十年后 - 大多数现代编程语言都在使用它.

假设您正在使用这些语言之一,您有什么理由不使用垃圾收集,而是以某种方式手动管理内存分配？

你有没有必要这样做？

如果可能,请举例说明.

我能想到几点:

确定性的解除分配/清理

实时系统

不放弃一半的内存或处理器时间 - 取决于算法

更快的内存alloc/dealloc和特定于应用程序的分配,释放和内存管理.基本上编写自己的内存 - 通常用于性能敏感的应用程序.这可以在很好地理解应用程序的行为的情况下完成.对于通用GC(如Java和C#),这是不可能的.

编辑

也就是说,GC对社区的大部分人来说当然都是好的.它允许我们更多地关注问题领域而不是漂亮的编程技巧或模式.我仍然是一个"非托管"的C++开发人员.在这种情况下,良好做法和工具有所帮助

内存分配？不,我认为GC比我更好.

但稀缺的资源分配,如文件句柄,数据库连接等？当我完成时,我编写代码来关闭它们.GC不会为你做那件事.

我做了很多嵌入式开发,其中的问题更可能是使用malloc还是静态分配,垃圾收集不是一种选择.

我还编写了许多基于PC的支持工具,并且很乐意使用GC,它可用且速度足够快,这意味着我不必使用pedant :: std :: string.

我写了很多压缩和加密代码,GC性能通常不够好,除非我真的弯曲实现.GC还要求您对地址别名技巧要非常小心.我通常在C中编写性能敏感的代码,并从Python/C#前端调用它.

所以我的答案是有理由避免GC,但原因几乎总是性能,然后最好用另一种语言编写需要它的东西,而不是试图欺骗GC.

如果我在MSVC++中开发一些东西,我从不使用垃圾收集.部分是因为它是非标准的,但也因为我在C++中没有GC而成长,并在安全的内存回收中自动设计.话虽如此,我认为C++是一种令人厌恶的东西,它无法提供C语言的翻译透明度和可预测性,或者后来的OO语言的范围内存安全性(以及其他内容).