~1s 延迟控制应用程序：这适合 Java 吗？
在我的工作中，我们最近完成了控制应用程序的系统架构，该应用程序的最大延迟约为一到两秒。它分布在小型 ARM 片上盒上，通过 IP LAN 进行通信。
我们最初预计我们会使用 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 延迟不是问题并且我们可以获得 RAII，我很乐意使用 Java。所以 我还研究了其他具有 RAII 的语言，可以作为很好的替代品，到目前为止，我发现 D、Ada、VB、Perl、Python(C)、PHP、tcl 和 Lua 似乎有某种超出范围的回调。我的本能反应是 D、Python 和 ADA 可能适合控制应用程序。 D 和 ADA 是我的最爱。
所以，我的问题是：您对此有什么建议吗？ Java 是一个可行的选择吗？如果您可以选择任何语言，您会选择什么？
At my work we recently finished the system architecture for a control application which has a maximum latency of roughly one to two seconds. It is distributed on small ARM on-chip boxes communicating via an IP LAN.
We initially foresee that we would use C or C++, since it is a classical control system language. After discussing how to implement the application we now realize that C++ has a quite limited amount of libraries, lacks introspection, and has some other properties which might slow down development. My colleague then suggested that Java might be up for the job.
I'm really scared about the latency of running a GC for a control app, and I'm also reluctant to drop RAII, since the app will use a lot of external resources (sockets, file handles, handles from external libs etc).
The pro/con list is currently as follows:
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
The memory fragmentation with parallel GC was mentioned in this AMD article
I would love to use Java if GC latency wasn't a problem and we could get RAII. Therefore
I've also looked into other langs which have RAII and could serve as good alternatives, and so far I've found that D,Ada,VB,Perl,Python(C),PHP,tcl and Lua seem to have some sort of out-of-scope callback. My spontainous reaction that perhaps D, Python, and ADA could be suitable for a control app. D and ADA are my favourites.
So, my question is: do you have any recommendations on this? Is Java a viable option, and if you could choose any language, what would it be?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您想使用java，可能您需要一个概念证明，我建议编写一个简单的原型和压力测试，以检查垃圾收集期间高负载下的延迟时间。然后检查不同的收集器类型 ig 低暂停收集器 。
我不太明白 RAII 论点，在 c++ 中，恕我直言，创建内存泄漏比在Java中。
Probably you need a prove of concept if you wish to use java, I would suggest to write a simple prototye and a stress test, to examine what latency time you have under high load during garbage collection. Then checkout the different collector types i.g. low pause collector .
The RAII argument I don't really understand, in c++ it's IMHO easier to create memory leaks than in java.
GC仅用于从被丢弃的对象中回收内存。丢弃非常少的资源，您将得到非常少、更短的 GC。
您可能会使用大量套接字、文件句柄、外部库的句柄，但是您丢弃它们的速度有多快？
完整 GC 旨在消除碎片。它通过复制所有内存来连续使用它来实现这一点。这就是它昂贵的原因，因此如果延迟对您很重要，您希望最大限度地减少这些。也就是说，如果完整 GC 花费的时间超过 100 毫秒，则存在严重的性能问题。不应该那么高。
恕我直言，我认为您应该能够开发一个延迟远低于 10 毫秒（99%+ 的时间）的控制系统。
The GC is only used for reclaiming memory from discarded objects. Discard very little resources and you will get very little, shorter GCs.
You might use lots of sockets, file handles, handles from external libs, but how fast do you discard them?
A full GC is designed to remove fragmentation. It does this by copying all the memory so it is used continously. This is why its is expensive, so you want to minimise these if latency is important to you. That said, if your full GCs are taking more than 100 ms, you have a serious performance issue. It shouldn't be that high.
IMHO, I short you should be able to develop a control system with a latency which is well under 10 ms, 99%+ of the time.
在这样的环境中，我会远离 GC（当然是在我见过的任何 JVM 中实现的）。你将永远在这个问题上用头撞墙。
然而，我只是想指出，RAII 论点似乎非常薄弱 - 您需要代码审查和其他此类培训，以确保您的团队能够很好地理解此类问题。排除一种原本合适的语言是一个非常糟糕的理由，因为每种语言都有一些缺陷，而缺乏经验/不太出色的程序员可能会错过。
我从你的列表中感觉到你缺少 C#（我正在考虑使用 Mono），在需要时你可以拥有更多的控制权。我不知道它是否适合您的环境，但如果您将 VB 列在您的语言清单上，那么这是一个明显的疏忽。
I would stay away from GC (certainly as implemented in any JVM I have seen) in such an environment. You will forever be banging your head against the wall on the problem.
However, I just wanted to point out that the RAII argument seems very weak - you need code reviews and other such training to ensure that such issues are well understood by your team. It is a very bad reason to exclude a language that is otherwise appropriate, as every language has gotchas that an inexperienced/less than stellar programmer can miss.
I felt from your list that you were missing C# (I'm thinking of with Mono) where you have a lot more control when you need it. I don't know if it is appropriate for your environment, but if you list VB on your laundry list of languages, it was an obvious oversight.