垃圾收集器(.net/java)是实时系统的问题吗？

Question

在构建需要非常一致且快速响应的系统时,垃圾收集器是否存在潜在问题？

我记得几年前的恐怖故事,典型的例子总是一个动作游戏,你的角色会在中途停止几秒钟,当垃圾收集器进行清理时.

我们还要进一步,但我想知道这是否还是一个问题.我读到了.Net 4中的新垃圾收集器,但它看起来仍然像一个大黑盒子,你只需要相信一切都会好的.

如果你有一个总是必须快速响应的系统,有一个垃圾收集器太大问题,选择更硬核更好,控制它自己像c ++这样的语言？我讨厌它,如果事实证明是一个问题,除了等待新版本的运行时或做一些非常奇怪的事情试图影响收集器之外,基本上几乎没有什么可以做的.

编辑

感谢所有的宝贵资源.但是,似乎大多数文章/自定义gc /解决方案都与Java环境有关..Net是否还具有自定义GC的调整功能或选项？

Answer 1

确切地说,垃圾收集器是实时系统的问题.更准确地说,可以用具有自动内存管理的语言编写实时软件.

有关使用Java实现实时行为的方法之一,可以在Java实时规范中找到更多详细信息.RTSJ背后的想法非常简单 - 不要使用堆.RTSJ提供了新的Runnable对象,确保线程不会访问任何类型的堆内存.线程可以访问作用域内存(此处没有异常;值在作用域关闭时被销毁)或永久内存(在整个应用程序生命周期中都存在).永生记忆中的变量一次又一次地用新值写入.

通过使用永久内存,RTSJ确保线程不访问堆,更重要的是,系统没有一个垃圾收集器,它先于线程执行程序.

有关更多详细信息,请参阅JPL和Sun出版的"Project Golden Gate:迈向太空任务中的实时Java"一文.

Answer 2

我用Java和.NET编写游戏,但从未发现这是一个大问题.我希望你的"恐怖故事"基于多年前的垃圾收集器 - 从那时起,这项技术确实已经走了很长一段路.

我唯一不愿意在垃圾收集的基础上使用Java/.NET就像嵌入式编程一样具有硬实时约束(例如运动控制器).

但是,您需要了解GC暂停,并且以下所有内容都有助于最大限度地降低GC暂停的风险:

• 最大限度地减少新的对象分配 - 虽然现代GC系统中的对象分配速度极快,但它们确实有助于将来的暂停,因此应尽量减少.您可以使用预分配对象数组,保留对象池或使用未装箱的基元等技术.
• 使用专门的低延迟库(如Javalution)来处理频繁使用的函数和数据类型.这些专为实时/低延迟应用而设计
• 当有多个版本可用时,请确保使用最佳GC算法.我听说过Sun G1 Collector的低延迟应用程序.最好的GC系统同时完成大部分收集,因此垃圾收集不必长时间"停止世界".
• 适当调整GC参数.通常在整体性能和暂停时间之间进行权衡,您可能希望以牺牲前者为代价来改进后者.

如果您非常富有,您当然可以购买具有硬件GC支持的机器.:-)

Answer 3

是的,必须在实时系统中以确定的方式处理垃圾.

一种方法是在每次存储器分配期间安排一定量的垃圾收集时间.这称为"基于工作的垃圾收集".这个想法是,在没有泄漏的情况下,分配和收集应该是成比例的.

另一种简单的方法("基于时间的垃圾收集")是为了定期垃圾收集安排一定比例的时间,无论是否需要.

在任何一种情况下,程序都可能耗尽可用内存,因为不允许花费足够的时间来完成完整的垃圾收集.这与非实时系统形成对比,非实时系统只要需要就可以暂停,以便收集垃圾.