为嵌入式流设备选择 JVM答案

【问题标题】：Selecting a JVM for an embedded streaming device为嵌入式流设备选择 JVM
【发布时间】：2018-09-06 14:38:17
【问题描述】：

我们正在开发一种设备，它基本上是一个树莓派，它可以读取文件数据、对其进行处理，并以给定的帧速率从 USB 设备中流式传输数据。

由于我们使用的特性的性质，我们不能完全消除垃圾分配，而且我们的 GC 暂停即使是很小的年轻代 GC 也会导致跳帧。

现在我们正在使用 HotSpot JVM，但我的理解是它更适合大型堆大小，我们的内存需求很少超过 256mb，所以我想知道是否有更好的带有垃圾收集的 VM 可以为我们提供在 Raspberry Pi 上暂停少于 15 毫秒？

【问题讨论】：

【解决方案1】：

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

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

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

【讨论】：

啊，我们将 Azul 视为一种解决方案，但许可成本高得令人望而却步，我不知道它还需要大量 RAM。仅供参考，我们确实将我们的 VM 切换到了嵌入式 zulu，并且我们确实注意到了性能提升，所以至少有:)。感谢 G1 收集器的洞察力，当我们分析它时，我们正在停止世界事件，但我们也在后台太快地创建了大量垃圾，所以这是有道理的。

【解决方案2】：

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

我们当前的解决方案是让应用程序保持原样，并忍受垃圾收集暂停的现实，这样我们就不会因为疯狂的优化量而阻碍我们应用程序的未来开发。让 Java 完成它的设计目标。

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

【讨论】：

您可能想尝试一下 Red Hat 的 Shenandoah。 Aleksey Shipilëv 本周在 JavaZone 上谈到了这一点，并表示它将在 Pi 3 上运行并显着减少停顿。由于它是单代收集器，它可能更适合您的应用程序。