logo标签列表

参考文献是使用基本数据类型编写的Java程序。

javagarbage-collectionreal-time
12

我听说过有些Java程序对延迟要求非常严格，在这些程序中“new”指令很少或从不使用（因为没有new=>没有对象->没有GC=>改善了延迟）...相反，所有业务逻辑都使用基本类型处理。

虽然我无法在网上找到相关的技术参考资料...但如果您能提供任何讨论此技术或代码片段的网页链接，我将不胜感激。

3
使用基本元素的商业逻辑？今天是4月1日吗？ - Sean Patrick Floyd
2
那听起来像是一个非常糟糕的想法！ - ColinD
7
这并不一定是过早优化。如果你的需求规定“晚”就等于“错”（硬实时要求），你确实需要像这样做。或者使用带有实时垃圾回收暂停保证的JVM（例如，请参见http://domino.research.ibm.com/comm/research_projects.nsf/pages/metronome.metronomegc.html）。 - The Archetypal Paul
4
这与新闻速度无关。重要的是能够“知道”对某个事件响应的延迟时间，这取决于垃圾回收器在GC暂停上是否有硬性的上限。大多数JVM都没有这样的限制，所以（对于硬实时系统），需要避免使用new操作。 - The Archetypal Paul
2
@ColinD：你提到滥用Java来表现C的观点是有道理的，但反过来说，许多时间关键型系统除了一小部分真正的低延迟行为外，还有大量不太严格受限的代码。RT Java方法（承诺）通过允许您在同一代码库中执行两者，并在它们之间定义良好的耦合，从而降低成本和复杂性。对于特定类别的系统，这非常有意义（例如国防和航空），尽管目前尚不确定它是否会长期成功。 - andersoj
显示剩余20条评论
6个回答
15

更新（2012年3月）：尽管没有公开宣布，但似乎Oracle已关闭其JavaRTS组。

你应该关注两个主题：Java实时规范（JSR-1，JSR-282）和Java安全关键规范(JSR-302)， (Aonix页面)。 RTSJ提供了进行仔细内存管理的资源，虽然RTSJ的大多数用户可能会容忍比“全部基元”方法更大的抖动（并且通过使用RTGC来获得GC的好处）。 有关限制分配的一些示例（限制何时/何地/多少次可以使用new），请搜索“rtsj scoped memory rules”，这里是一个有关此主题的学术论文示例。 您还应该查看“eventrons”，这是在Java中相对干净的方式尝试解决这些高频，低延迟约束的示例。

有关在交易上下文中使用JavaRTS的特定新闻报道，请参见此处。 有关如何在特定情况下获得最确定性行为的一些说明，请参见此处。

安全关键用户更有可能具有此类限制，而SC-Java预计部分是RTSJ的降级版本。您可以在Doug Locke的JTRES 2007状态幻灯片中看到一些专家小组正在研究的示例。

几位人士生产了旨在在此环境中使用的JVM。 Aonix / Atego的PERC; aicas的JamaicaVM; Apogee的Aphelion。Sun / Oracle JavaRTS针对更大的应用程序，可以容忍（并受益于）较少严格的约束。

虽然您所提及的“全部基元”方法是这种类型的编程的极端形式，但您最有可能在上述参考资料之一中找到此主题的资源。

对于我上面的“原语中的业务逻辑？”唱衰者，请注意，IBM汇编语言实现了大量IRS税务业务逻辑，并且正在考虑使用一些“企业”层像Java来包装（而不是替换！）该逻辑。把它放进你的烟斗里吧。

我无法在此引用任何具体信息，但有许多国防应用程序使用Java（通常是RTSJ的一种变体），对内存分配有非常严格的限制，并且大部分代码都是静态分配的，基元聚焦的。信号处理等...我搜索了我了解的系统的开放源代码资料，并且这些文档（特别是参考部分）指引了一些具体示例。

实时虚拟机的一个缺点是它们往往相当昂贵。 - Eleco
@elec，你可以免费使用JavaRTS进行有限的（学术或非商业）用途，并且大多数其他供应商在这些目的上授权也很慷慨。但是他们必须赚钱，而这不是一个高销量的市场。请参见我在此处的评论https://dev59.com/Wm855IYBdhLWcg3w-JbS#4083572 - andersoj
5

我曾经在许多这样的系统上工作过。如果你需要亚毫秒延迟，你需要考虑创建对象。可以编写一个应用程序，一整天都不会进行垃圾回收，以避免任何垃圾回收延迟。

然而，99%以上的应用程序并不需要这种极端情况。

1
+1：很少有系统需要这种极端情况；然而，那些需要的1%往往非常重要。 - andersoj
我曾经在一个系统上工作过，在该系统中创建一个对象的成本是每年约500美元，因为它增加了延迟时间。 ;) - Peter Lawrey
@PeterLawrey，使用Java有什么好处？只有C人才行，只有C。C总是赢得胜利。 - Pacerier
3
不，我从未听说过这样的程序，甚至没有听说过这种技术。
这似乎是一个糟糕的想法，因为这样你实际上就被限制在使用C或类似的低级语言上。如果你需要这样做，用C编写会更容易。此外，有许多方法可以避免长时间的GC暂停，在实践中，大多数低延迟要求都可以通过它们来满足。
另外，为了做任何有用的事情，你必须使用Java平台API或其他第三方库，这些库可能会在你不知情的情况下分配大量对象，因此在非平凡程序中避免所有对象实例化可能根本不切实际。
所以我相当确定这是一个城市传说，或者最多是一个小众想法。
编辑：
这种技术用于获得实时或低延迟行为。现在由于更好的GC算法，它可能已经过时了，但这当然取决于具体情况。因此，至少对于算法的热点部分，这可能是值得考虑的东西。
例如：
许多Java实时环境对对象创建施加了一些限制。这并不意味着它们只能使用原始数据类型：复杂对象的使用仍然是可能的，但例如Safety Critical Java (http://www.aicas.com/papers/scj.pdf)要求所有对象实例化都在初始化阶段完成。一旦应用程序正在运行（"任务阶段"），实例化将不再允许，因此您必须使用您拥有的对象实例进行操作。

这避免了动态分配和垃圾回收引入的不可预测性，但仍然允许有限地使用动态内存。

感谢andersoj和mikera为我解释这个问题。

1
比 C 更糟糕。C 有复合数据类型（结构体）。 - user395760
-1：有很多静态分配、仅包含基本类型的程序示例。只是在通用计算领域中不常见... - andersoj
-1 是错误的说法：这是一种完全有效且有用的技术，应用于许多低延迟的情况中。金融市场交易、多媒体/音频制作和游戏都是这种技术常见的好例子。 - mikera
@andersoj：感谢分享这些有趣的链接。我之前不知道这个领域，看起来非常迷人。 - sleske
@delnan，可以使用基本类型和函数来实现结构体。 - Pacerier
显示剩余2条评论
3

请查看Java实时规范。

尽管它在分配方面具有更加复杂的规则。

2

可能有一些交易系统可以做到这一点，但据我了解（我的同事们在基于Java的低延迟交易平台上工作），一个好的快速现代JVM结合合理的编码实践就可以避免在代码中使用“纯粹的原语”。尽管如此，我不是一个低延迟开发人员，我们的中间件团队只关心每分钟的数千个交易，而不是数万个。我还没有找到令人信服的文章，尽管我很乐意惊喜地发现 :)

2
在这里阅读节拍器论文：http://domino.research.ibm.com/comm/research_projects.nsf/pages/metronome.metronomegc.html。非常有趣的内容。现代JVM对于软实时（晚一点不好但也不是错的）已经足够好了，但是对于硬实时（核反应堆、飞行控制软件等）你需要一些特殊的东西。 - The Archetypal Paul
谢谢@Paul - 很好的东西。我想知道其中有多少可能会进入openJDK/未来的JVM中。 - Martijn Verburg
@Paul：节拍器是很棒的东西。相比之下，可以将其与Sun/Oracle的JavaRTS垃圾回收方法进行对比。 - andersoj
2

我曾在游戏编程中使用过这种技术，因为太多的长时间GC延迟会降低用户体验。实践中并不需要消除所有的“new”指令，只需将其保持在合理的水平即可。

一个很好的例子是Javolution库，它使用了很多这些技术，如果你对它的编码方式感兴趣或想要使用支持最小分配操作的现成数据结构和算法，那么它绝对值得一看。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接