在构建需要非常一致且快速响应的系统时，垃圾收集器是否会成为潜在问题？
我记得几年前的恐怖故事，典型的例子总是 Action 游戏，你的角色会在跳跃过程中停下几秒钟，这时垃圾收集器会进行清理。
我们还有几年的时间，但我想知道这是否仍然是一个问题。我读到了 .Net 4 中的新垃圾收集器，但它看起来仍然很像一个大黑匣子，你只需要相信一切都会好起来的。
如果您的系统必须始终快速响应，那么垃圾收集器是否是一个太大的问题，最好选择更硬核的、像 c++ 这样自己控制的语言？我会讨厌它，如果它被证明是一个问题，除了等待运行时的新版本或做一些非常奇怪的事情来试图影响收集器之外，基本上你几乎无能为力。
编辑
感谢您提供的所有优质资源。但是，似乎大多数文章/自定义 gc/解决方案都与 Java 环境有关。 .Net 是否也有针对自定义 GC 的调优功能或选项？
最佳答案
准确地说，垃圾收集器是实时系统的一个问题。更准确地说，可以用具有自动内存管理功能的语言编写实时软件。
更多详情请见 Real Time Specification for Java关于使用 Java 实现实时行为的方法之一。 RTSJ 背后的想法非常简单——不要使用堆。 RTSJ 提供了新的 Runnable 对象，确保线程不会访问任何类型的堆内存。线程可以访问作用域内存(这里没有什么异常；当作用域关闭时值被销毁)或不朽内存(存在于整个应用程序生命周期中)。不朽内存中的变量一次又一次地被新值覆盖。
通过使用不朽内存，RTSJ 确保线程不访问堆，更重要的是，系统没有垃圾收集器抢占线程执行程序。
更多详细信息请参见论文 "Project Golden Gate: Towards Real-Time Java in Space Missions" published by JPL and Sun .
关于java - 垃圾收集器 (.net/java) 是实时系统的问题吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3559878/