~1s 延迟控制应用程序：这适用于 Java 吗？

Posted 2023-02-22

【中文标题】~1s 延迟控制应用程序：这适用于 Java 吗？

【英文标题】：~1s latency control app: is this suitable for Java?

【发布时间】：2011-02-24 09:13:28

【问题描述】：

在我的工作中，我们最近完成了一个控制应用程序的系统架构，该应用程序的最大延迟大约为一到两秒。它分布在通过 IP LAN 通信的小型 ARM 片上盒上。

我们最初预计会使用 C 或 C++，因为它是一种经典的控制系统语言。在讨论了如何实现应用程序之后，我们现在意识到 C++ 的库数量非常有限，缺乏内省，并且还有一些其他属性可能会减慢开发速度。然后我的同事建议 Java 可能胜任这项工作。

我真的很害怕为控制应用程序运行 GC 的延迟，而且我也不愿意放弃 RAII，因为该应用程序将使用大量外部资源（套接字、文件句柄、来自外部库的句柄）等）。

目前优劣名单如下：

C++

+ RAII - Easy resource management - it will be a complex system
+ System language - speed if we cant't find a JIT VM for our ARM
+ No GC - no big worst case latencies from the GC
+ Easy to integrate with some shared mem libs that we have to interface with
- Fewer free as in beer libs 
- Lacks introspection - Mapping classes to DB and external data formats (XML)    
  would benefit from this (ORM /JAXB) approach
- Easy to shoot one self in the foot - hard and expensive to find programmers 
  which don't make big mistakes
- Memory fragmentation - needs tuning and workarounds

Java

+ Huge amount of libs
+ Introspection - serialization becomes a breeze (see C++ section)
+ Easier to find 'good enough' programmers
- No RAII - Client has to remember finally or you leak 
   resources. IMO Java programmers tend to ignore this 
   problem unless they have server app background.
- No System Language - possibly slower although ARMj could alleviate this
- GC - latency might go up (don't know if parallel GC will work - seems that
     you might get fragmentation, see note below).
- Need to write JNI for the shared mem libs that we interface with
- Maybe ORACLE will eat us

提到了并行GC的内存碎片in this AMD article

如果 GC 延迟不是问题并且我们可以获得 RAII，我很乐意使用 Java。所以 我还研究了其他具有 RAII 并且可以作为很好的替代品的语言，到目前为止，我发现 D、Ada、VB、Perl、Python(C)、php、tcl 和 Lua 似乎有某种超出范围的回调。我的自发反应也许 D、Python 和 ADA 可能适用于控制应用程序。 D 和 ADA 是我的最爱。

所以，我的问题是：您对此有什么建议吗？ Java 是一个可行的选择吗？如果你可以选择任何一种语言，你会选择什么？

【问题讨论】：

@disown：GC 不是你唯一的敌人。 JIT 的加入也会引入延迟峰值（顺便说一句，在 Google I/O 2010 上可以看到，新的 android JIT 设备一开始会比非 JIT 设备运行得更慢，然后更快）。我想你可能对javolution.org 感兴趣，那里有很多有趣的文章链接。

@Webinator：感谢您的链接，现在正在查看...

【参考方案1】：

GC 仅用于从丢弃的对象中回收内存。丢弃非常少的资源，您将获得非常少、更短的 GC。

您可能会使用大量套接字、文件句柄、来自外部库的句柄，但是您丢弃它们的速度有多快？

完整的 GC 旨在消除碎片。它通过复制所有内存来做到这一点，以便连续使用它。这就是它昂贵的原因，因此如果延迟对您很重要，您希望尽量减少这些。也就是说，如果您的完整 GC 花费超过 100 毫秒，那么您就会遇到严重的性能问题。应该不会那么高。

恕我直言，您应该能够开发一个延迟远低于 10 毫秒（99% 以上的时间）的控制系统。

【讨论】：

即使您的程序在资源方面非常保守，您如何保证您调用的库不会以惊人的速度翻阅对象？

我不认为我们可以做很多池化，套接字将用于不同的客户端，所以我们会建立和拆除很多。也许缓存连接会有所帮助，并且只有在连接超时时才重新初始化。你说“99% 的时间不到 10 毫秒”。我想知道是否有任何更高的“最坏情况”峰值。我不是说理论上的意思，但是如果你运行几个月，最坏情况下的延迟是多少，以及与 C++ 中的延迟相比如何。我知道这是一个很难回答的问题，我只是在寻找实用的指针。

保证低 GC 时间的唯一方法是使用少量临时对象。即使用较小的年轻一代。然而，这很难可靠地控制在 10 毫秒以下。使用新的 G1 收集器应该有助于控制完整收集的延迟，但它仍在开发中。根据我的经验，与精心编写的 Java 应用程序相比，网络中的可变性要大得多，这就是为什么我花更多时间关注网络性能而不是 Java 性能。

谢谢。这是很有价值的建议。

【参考方案2】：

如果您想使用 java，可能需要概念验证，我建议编写一个简单的原型和压力测试，以检查垃圾收集期间在高负载下的延迟时间。然后检查不同的收集器类型，例如low pause collector.

RAII 参数我不太明白，恕我直言，在 c++ 中创建内存泄漏比在 java 中更容易。

【讨论】：

内存泄漏是的，但 RAII 也适用于其他资源，如数据库连接和文件句柄，在 Jave 中你唯一拥有的是 try/finally，这绝对不如 RAII（AFAIK 需要堆栈- 分配的对象，因此无法在 JVM 上实现）。

根据我在问题中链接的文章，低暂停收集器显然会导致内存碎片。我不知道这有多严重，以及 C++ 是否会更好。 RAII 绝对有助于不泄漏资源，这就是我寻找 RAII 语言的原因。

【参考方案3】：

在这样的环境中，我会远离 GC（肯定是在我见过的任何 JVM 中实现的）。你将永远在这个问题上撞墙。

但是，我只是想指出 RAII 的论点似乎非常薄弱 - 您需要代码审查和其他此类培训，以确保您的团队充分理解此类问题。排除一种在其他方面合适的语言是一个非常糟糕的理由，因为每种语言都有一些经验不足/不够出色的程序员可能会错过的问题。

我从您的列表中感觉到您缺少 C#（我正在考虑使用 Mono），在那里您可以在需要时拥有更多控制权。我不知道它是否适合你的环境，但如果你把 VB 列在你的语言清单上，那显然是一个疏忽。

【讨论】：

洗衣清单仅包含可以支持 RAII 并具有超出范围回调的语言。 C# 有“使用”，但这只是 try..finally 的语法糖，Java 中也有。我并不是说 RAII 是灵丹妙药，它只是一个非常方便的功能，可以帮助程序员不泄漏资源。我担心如果我们没有 RAII，代码会变得更难阅读，仅此而已。

@disown，我更多地认为 C# 具有大部分 Java 优势（库除外）并且更容易集成，我确实认为 using 更容易静态检查捕捉到使用 try/finally 的失败。如果您的问题是可读性，那么using 也更具可读性 IMO。不过，我并没有真正提倡它，只是说它似乎值得考虑。 D 和 ADA 可能确实是更好的选择。