我正在考虑学习 D（基本上“C++ 做得正确，垃圾收集和线程之间的消息传递”）并与一位长期从事 C++ 程序员的同事交谈，基本上他抱怨垃圾收集器本身存在严重的时间问题即使在软实时类型的应用程序中。
这并不是说我需要编写实时应用程序——远非如此——但我很好奇 GC 在开发数据库时会有多大问题？（从统计上GC似乎强加的额外内存使用开销中抽象出来）
（现在我知道可以在 D 中关闭 GC，但这就像说您可以通过摆脱汽车来摆脱与汽车相关的问题 - 是的，但这不是我想选择的解决方案）
这是真的？这些问题在实践中有多严重？例如，在 D 中开发设备驱动程序并使用 GC 是实用/明智/良好的做法吗？
虽然 D 有一个 GC，但它不会强迫您将它用于所有事情。D 也有结构，其行为类似于 C++ 类和结构（减去多态性）。
在现代托管语言中，只要您有足够的内存，GC 就不是问题。对于像 C++ 这样的非托管语言也是如此 - 但在 C++ 中，内存不足意味着您无法分配更多内存，而在 Java 中，内存不足意味着 GC 启动时的延迟。
因此，如果您打算分配大量对象，那么可以 - GC 可能是个问题。但是你可能并不真的需要分配这么多的对象。在 Java 中，您必须使用对象来存储诸如字符串、日期和坐标之类的东西——这确实会填满您的堆并调用 GC（幸运的是，现代 JVM 使用分代 GC 来优化这些类型的对象）。在 D 中，您只需将结构用于这些事情，而仅将类用于实际需要 GC 的情况。
根据经验，您通常希望尽可能使用结构，但是如果您发现自己做了一些特殊的事情来处理解除分配或防止复制和破坏（尽管它在 D 中非常快） - 使该类型成为一个没有的类再想一想。
我个人并不真正赞同“只要你有足够的内存，GC 不是问题”的说法。我的意思是，这基本上意味着，你继续浪费你的内存，而不是妥善处理它，当它用完时，你突然不得不等待 1> 秒让 GC 收集所有东西。
一方面，只有当它是一个非常糟糕的 GC 时才会发生这种情况。例如，c# 中的 GC 非常快速且频繁地收集对象。你不会遇到问题，即使你在一个经常使用的函数中进行分配，它也不会等到你的内存用完才进行收集。
我没有完全了解 D2 GC（我们使用 D1）的当前特性，但当时的行为是它会分配一个内存池，并且对于你的每个分配，它都会给你一些。当它发出 90% 并且您需要更多时，它将开始收集和/或从系统分配更多。（或类似的东西）。（对于 D1）还有并发 GC，它会更早地开始收集，但让它们在后台运行，但它仅适用于 linux，因为它使用 fork 系统调用。
所以，我认为如果不小心使用，当前的 D GC 可能会导致小但明显的冻结。但是您可以禁用/启用它，例如，当您执行实时关键操作时，禁用它，当代码的关键部分结束时，再次启用它。
For a database, I don't think the D GC is ready yet. I would heavily re-use memory and not rely on the GC at all for that kind of application.