java低延迟

总览

以前，我写过一篇有关Java之类的C的文章。 这是我以前遇到的术语。 但是，经过思考，我认为像Java这样的C ++是一个更好的术语，因为您仍在使用OOP惯例（不是C惯例），但是您需要投入更多的精力来管理和回收内存。

我现在支持的术语是“低级” Java编程。

低延迟和“自然” Java

许多低延迟系统仍使用我称为自然Java的程序进行编程。 在大多数情况下，这是最简单，最有效的方法。 当您具有大堆大小和低延迟要求时，这些问题才真正开始，因为它们不能很好地协同工作。

如果您有一个已建立的程序，并且重写是不合理的，则需要Zing之类的东西，它具有真正的并发收集器。 尽管您可能会看到1-4 ms的最严重的停顿，但这与非实时系统一样好。 有传言说RedHat正在产生并发收集器，但是正如Oracle在G1中发现的那样，编写有效的低延迟是非常困难的。 G1工作正常，只是不适合低延迟交易（例如，暂停时间为1毫秒），我不确定是否会如此。

如果可以重写关键组件，尤其是出于性能以外的原因而正在考虑这样做，则可以显着提高性能，但可以使用更像C ++或C的低级编程。语言是指您正在使用与那些语言相同的技巧，并且已经使用了很长时间，但是使用Java。

为什么用Java进行低级编程？

主要原因是集成和易于支持。 低级Java与自然Java代码非常紧密地集成在一起。 所有的Java工具都可以很好地使用它，并且它仍然是跨平台的（至少是跨OS的）。某些底层技术是JVM特定的，例如它们可以在OpenJDK / HotSpot上工作，但不能在IBM的JVM上工作，反之亦然。 他们可能会起作用，但很多都无济于事。 例如，在HotSpot上使用不安全可能会更快，但在Android上会明显慢。

低级Java编程的另一个好处是，经验丰富的Java开发人员发现使用它相对容易。 他们可能会发现很难从头开始编写，但是如果使用隐藏更多细节的库，则可以有效地使用它。

低级Java有哪些注意事项？

延迟目标

除非您在99.9％的时间内运行时间少于1毫秒，否则您现在可以认为1毫秒的延迟不是那么快。 Java中最快的系统通常约为100微秒，甚至低于包装箱外部的20微秒。

如何处理高吞吐量

对于交易系统，建议您将等待时间设置得尽可能低，并且吞吐量通常足够。 例如，编年史可以以一个线程的持续速率以最大爆发次数持续完整的Opera提要。 这是可能的，因为编年史的潜伏期很短。 一条很小的4字节消息的平均延迟为7纳秒。 即使JVM在下一行崩溃时，它也将保留。 在这一点上吞吐量不是一个问题。

对于反向测试，低延迟是不够的。 这是因为您想要做的是在不到一秒钟的时间内（理想情况下）重播数月的数据。 在这种情况下，您需要高度的并行性以及能够在短时间内重播大量数据的能力。 为此，我使用了内存映射文件，这些文件对我需要的数据进行了预装查询。 如果这些文件为二进制格式并适合主内存，则可以非常快速地跨线程重复访问它们。

处理GC。

垃圾收集暂停会使您减速，因此最快的方法是构建引擎是不使用休息时间。 相反，您给自己一个预算，这是您可以合理拥有的最大伊甸园大小。 这可能是24 GB的Eden。 如果您花了一整天的时间来填满，一天之内就不会收集，即使是次要的收集也是如此。 假设您可以在晚上或周末停下来几秒钟，则可以在预定时间执行完全GC，而GC不再是问题。

即使这样，我还是建议尽量减少垃圾并定位内存访问模式，以最大程度地提高L1 / L2效率，从而可以将性能提高2-5倍。 L3缓存至少比L1慢10倍，并且如果您不给L1填充垃圾（正如许多Java程序一样），您的程序将更快，更一致地运行。

将共享内存用于IPC

这有两个优点。

1. 您可以保留所有事件的记录，以及整天的时间安排和微不足道的开销。 因为可以保留更多数据，所以可以在外部，下游或重现错误来重现系统的确切状态。 这为您提供了基于数据驱动的海量测试，您可以通过测试系统实时提供生产数据，以查看ti在运行之前的行为。
2. 实际上，它可能比其他方法快得多。 一条微小的消息的平均写入延迟为7纳秒，并且在不到100纳秒的时间内对另一个进程可见。

固定芯

许多人已经尝试过固定核心，但并没有太大的区别。 这可能是由于a）应用程序的抖动过大，几乎没有关系，或者b）然后没有固定到隔离的内核。 我发现如果绑定到隔离的内核，最坏情况的延迟会从2毫秒下降到10微秒，但固定到非隔离的内核似乎根本没有帮助。

忙碌中

您不希望关键线程进行上下文切换，而避免这种情况的一种方法是永远不要放弃内核或CPU。 这可以通过在固定的隔离内核上忙于等待来完成。 我所做的一件事是使用隔离的核心
a）对最关键的线程有选择地禁用超线程，而其余的则保留。
b）通过不对“垃圾”内核进行超频来更多地使隔离内核超频。 通过限制不需要最大速度的磁芯产生的热量，可以达到这一目的。 例如，假设您有一个十六进制内核，则不让内核0,2,4保持超频，而超频内核1,3,5则不使用HT，比整个插槽多使用10％。 我认为超频内核在芯片上并不相邻，因此它们不太可能过热。

更大的地址空间集合

Chronicle和OpenHFT的直接存储的主要功能是它们允许访问64位大小。 （由于OS / CPU的限制，技术上只能使用48位）这意味着您可以将TB大小的数据集作为一个集合进行管理，而该集合具有在Java内存中本地的数十亿条记录/摘录。 这样甚至可以避免JNI障碍或系统调用来降低应用程序速度。

结论

如果您的应用程序将其90％的时间用在其代码的10％或80/20中，则可以使用“自然” Java编写90％的代码，或者使用第三方库。 但是，如果您用低级Java编写10％的代码，则可以显着提高性能。

翻译自: https://www.javacodegeeks.com/2013/07/c-like-java-for-low-latency.html

java低延迟