为嵌入式流媒体设备选择 JVM

Question

我们正在开发一种设备，它基本上是一个树莓派，它可以读取文件数据、处理它并以给定的帧速率将数据从 USB 设备中流出。由于我们使用的特性的性质，我们不能完全消除垃圾分配，即使是次要的年轻代 GC 的 GC 暂停也会导致跳帧。现在我们正在使用 HotSpot JVM，但我的理解是它更适合大堆大小，我们的内存需求很少超过 256mb，所以我想知道是否有更好的垃圾收集 VM 可以让我们暂停更少树莓派上 15 毫秒？

Answer 1

最终，我们决定让应用程序做一些它真正不适合做的事情，或者至少，不值得开发资源继续沿着这条道路前进。

我们当前的解决方案是让应用程序保持原样，并接受垃圾收集暂停的现实，这样我们就不会通过疯狂的优化来阻碍应用程序的未来开发。让 Java 做它设计要做的事情。

为了停止导致跳帧的暂停，我们选择创建第二个小缓冲区应用程序，由我们的主应用程序通过 IPC 管理。

Answer 2

我想你真的会为此而挣扎。您没有提供用于启动 JVM 的标志，因此无法推荐替代方案。

一个配置良好的 G1 收集器，其应用程序不会生成不断增加的长寿命对象，将避免 stop-the-world full GC。但是，您的问题是，即使是较小的 GC（通常非常快）也会导致无法接受的延迟。部分问题是 Pi 上内存总线的速度，这并不是那么好。

我们（我为之工作的 Azul）生产了一个无暂停收集器 (C4)，但它是为拥有更多资源的机器设计的。它至少需要 1Gb RAM 并使用多个内核与应用程序线程同时处理 GC。