我正在考虑学习D（基本上是“正确完成C ++并使用垃圾收集和线程之间的消息传递”）并与一位长期从事C ++程序员的同事交谈，基本上他抱怨垃圾收集器本身已经即使在软实时类型应用中也会出现严重的时序问题。
这不是我需要编写实时应用程序 - 远非它 - 但我很好奇GC在开发数据库时会有多大问题？ （从GC似乎强加的额外内存使用开销中抽象出来，统计上）
（现在我知道GC可以在D中关闭，但这就像是说你可以通过摆脱汽车摆脱与汽车相关的问题 - 这是真的，但这不是我想选择的解决方案）< / p>
这是真的吗？这种问题在实践中有多严重？比如在D中开发设备驱动程序并使用GC是实用/合理/良好的做法吗？
答案 0 :(得分：2)
虽然D有GC，但它不会强迫您将其用于所有内容。 D也有结构，它的行为类似于C ++类和结构（减去多态性）。
在现代托管语言中，只要您有足够的内存，GC就不是问题。对于像C ++这样的非托管语言也是如此 - 但在C ++中，内存不足意味着你不能再分配更多的内存，而在Java中，内存耗尽意味着GC启动时会出现延迟。
因此，如果您计划分配大量对象，那么是 - GC可能是个问题。但是你可能并不需要分配这么多对象。在Java中，您必须使用对象来存储诸如字符串，日期和坐标之类的东西 - 这可以真正填满您的堆并调用GC（幸运的是，现代JVM使用分代GC来优化这些类型的对象）。在D中，您只需对这些内容使用结构，并且仅对实际需要GC的情况使用类。
根据经验，你通常希望在任何地方使用结构，但是如果你发现自己做了一些特别的事情来处理解除分配或者防止复制和破坏（尽管在D中真的很快） - 制作没有第二个想法就输入了一个类。
答案 1 :(得分：0)
我个人并不真正赞同这句话“只要你有足够的内存，GC就不是问题”。我的意思是，这基本上意味着，你前进并浪费你的记忆而不是妥善照顾它，当它出来时你突然不得不等待1＆gt;第二个让GC收集所有东西。
首先，只有当这是一个非常糟糕的GC时才会发生。例如，c＃中的GC以极快的速度经常收集对象。你不会遇到问题，即使你在一个经常使用的函数中分配它也不会等到你的内存不足以进行收集。
我还没有完全了解D2 GC的当前功能（我们使用D1），但当时的行为是它会分配一个内存池，并且对于你的每个分配，它会给你一些它。当它发出90％并且您需要更多时，它将启动一个集合和/或从系统中分配更多。 （或类似的东西）。还有（对于D1）并发GC可以更早地启动集合，但让它们在后台运行，但它只是linux，因为它使用fork系统调用。
所以，我认为如果不小心使用，目前的D GC可能会导致小而明显的冻结。但您可以禁用/启用它，例如当你做一些实时关键时，禁用它，当代码的关键部分结束时，再次启用它。
对于数据库，我认为D GC尚未准备就绪。我会大量重用内存，而不是完全依赖GC来处理这种应用程序。