在高频交易的世界中，自动化应用程序每天处理数亿个市场信号，并在全球各个交易所发送成千上万的订单。
为了保持竞争力，反应时间必须始终保持在微秒内，特别是在异常高峰（例如“黑天鹅”事件）期间。
在典型的体系结构中，金融交易信号将转换为单一的内部市场数据格式（交易所使用各种协议（例如TCP / IP，UDP多播）和多种格式（例如二进制，SBE，JSON，FIX等）。那些normalised的消息然后被发送到算法的服务器，统计引擎，用户接口，日志服务器，和所有种数据库（存储器内，物理，分布式）。沿这条路径进行的任何延迟都可能带来昂贵的后果，例如基于旧价格制定策略或过早到达市场的订单。
为了获得这些关键的微秒时间，大多数玩家都在昂贵的硬件上进行了投资：配备超频水冷CPU的服务器池（到2020年，您可以购买具有56个5.6 GHz内核和1 TB RAM的服务器），在主要交换数据中心的配置，纳秒级网络交换机，专用的次洋线（Hibernian Express是主要提供商），甚至是微波网络。常见的情况是，具有操作系统旁路的高度定制的Linux内核使数据直接从网卡“跳转”到应用程序，IPC（进程间通信）甚至FPGA（可编程的单用途芯片）。
对于编程语言，C ++似乎是服务器端应用程序的自然竞争者：它速度很快，尽可能接近机器代码，并且一旦为目标平台编译，就提供了恒定的处理时间。
我们做出了不同的选择。
在过去的14年中，我们一直在使用Java并使用出色且价格合理的硬件进行FX算法交易空间编码方面的竞赛。
由于团队规模小，资源有限以及熟练的开发人员缺乏工作市场，因此Java意味着我们可以快速添加软件改进，因为Java生态系统比C派生产品具有更快的上市时间。可以在早上讨论改进措施，并在下午在生产中实施，测试和发布改进。
与需要几周甚至几个月的软件更新时间的大型公司相比，这是一个关键优势。在一个漏洞可以在几秒钟内抹掉全年利润的领域中，我们还没有准备好在质量上做出妥协。我们使用许多开源库和项目实施了严格的敏捷环境，包括Jenkins，Maven，单元测试，夜间构建和Jira。
使用Java，开发人员可以专注于直观的面向对象的业务逻辑，而不必像C ++中那样调试一些晦涩的内存Core转储或管理指针。而且，由于Java强大的内部内存管理，初级程序员也可以在第一天以有限的风险增加价值。
凭借良好的设计模式和简洁的编码习惯，可以使用Java达到C ++低延迟。
例如，Java将优化和编译在应用程序运行期间观察到的最佳路径，但是C ++会预先编译所有内容，因此即使未使用的方法也仍将是最终可执行二进制文件的一部分。
但是，这里有一个问题，一个主要问题要启动过程。使Java如此强大和令人愉悦的语言的原因还在于它的劣势（至少对于微秒敏感的应用程序而言），即Java虚拟机 （JVM）：
- Java随心所欲地编译代码（仅在时间编译器或JIT中进行），这意味着它第一次遇到某些代码时，会导致编译延迟。
- Java管理内存的方式是在其“堆”空间中分配内存块。每隔一段时间，它将清理该空间并移走旧物体，以便为新物体腾出空间。主要问题是为了准确计数，应用程序线程需要暂时“冻结”。此过程称为垃圾收集（GC）。
GC是低延迟应用程序开发人员可能会先验丢弃Java的主要原因。
市场上有一些Java虚拟机：
- 最常见和标准的是Oracle Hotspot JVM，它在Java社区中被广泛使用，主要是出于历史原因。
- 对于要求非常高的应用程序，Azul Systems提供了一个很棒的替代方案，称为Zing。
- Zing是标准Oracle Hotspot JVM的强大替代品。Zing解决了GC暂停和JIT编译问题。
让我们研究一下使用Java和可能的解决方案所固有的一些问题。
了解Java的即时编译器
像C ++这样的语言被称为编译语言，因为所提供的代码完全是二进制的，可以直接在CPU上执行。
PHP或Perl之所以称为解释型，是因为解释器（安装在目标计算机上）会在运行时编译每一行代码。
Java介于两者之间。它将代码编译为Java字节码，然后在认为合适的情况下将其编译为二进制。
Java在启动时不编译代码的原因与长期性能优化有关。通过观察应用程序的运行并分析实时方法调用和类初始化，Java可以编译经常调用的代码部分。它甚至可能根据经验做出一些假设（这部分代码永远不会被调用，或者该对象始终是String）。
因此，实际的编译代码非常快。但是存在三个缺点：
- 在优化和编译某个方法之前，必须先调用该方法一定次数才能达到编译阈值（该限制是可配置的，但通常约为10,000次调用）。在此之前，未优化的代码不会以“全速”运行。在获得更快的编译速度和获得高质量的编译速度之间存在折衷（如果假设错误，则会产生重新编译的费用）。
- Java应用程序重新启动时，我们回到第一个平方，必须等待再次达到该阈值。
- 某些应用程序（例如我们的应用程序）具有一些不常见但很关键的方法，它们只会被调用几次，但是在执行时需要非常快（考虑到风险或止损过程仅在紧急情况下才调用）。
Azul Zing通过让其JVM在其所谓的概要文件中“保存”已编译方法和类的状态来解决这些问题。名为ReadyNow！ 的独特功能意味着Java应用程序即使在重启后也始终以最佳速度运行。
当您使用现有概要文件重新启动应用程序时，Azul JVM会立即撤回其先前的决定并直接编译概述的方法，从而解决了Java预热问题。
此外，您可以在开发环境中建立概要文件，以模仿生产行为。然后，知道所有关键路径都已编译和优化，然后可以将优化的概要文件部署到生产中。
在1％的时间内，热点JVM产生的延迟是Zing JVM的16倍。
解决垃圾回收（GC）暂停
第二个问题，在垃圾回收期间，整个应用程序可能冻结几毫秒到几秒钟之间的任何时间（延迟随着代码复杂性和堆大小而增加），更糟糕的是，您无法控制何时发生。
尽管对于许多Java应用程序来说，暂停应用程序几毫秒甚至几秒钟是可以接受的，但对于低延迟应用程序（无论是在汽车，航空航天，医疗还是金融领域）来说，这是一场灾难。
GC的影响是Java开发人员中的一个大话题。完整的垃圾回收通常称为“世界停止停顿”，因为它冻结了整个应用程序。
多年以来，许多GC算法都试图降低吞吐量（在实际的应用程序逻辑上而不是在垃圾回收上花费了多少CPU）与GC 暂停（我可以承受暂停应用程序多长时间？）。
从Java 9开始，G1收集器已成为默认的GC，其主要思想是根据用户提供的时间目标分割GC暂停。它通常提供较短的暂停时间，但以降低吞吐量为代价。另外，暂停时间随着堆的大小而增加。
Java提供了许多设置来调整其垃圾收集（通常是JVM），从堆大小到收集算法，以及分配给GC的线程数。因此，常见的情况是看到Java应用程序配置了过多的自定义选项。
许多开发人员（包括我们的开发人员）已转向各种技术来完全避免使用GC。主要是，如果我们创建的对象更少，那么以后需要清除的对象就会更少。
一种旧的（并且仍在使用）的技术是使用可重用对象的对象池。例如，数据库连接池将保存对10个打开的连接的引用，这些连接可以按需使用。
多线程通常需要锁，这会导致同步延迟和暂停（尤其是如果它们共享资源）。一种流行的设计是环形缓冲区 ring buffer队列系统，其中许多线程在无锁设置中进行读写操作（请参阅disruptor ）。
出于无奈，一些专家甚至选择完全覆盖Java内存管理并自己管理内存分配，这在解决一个问题的同时，还带来了更多的复杂性和风险。
在这种情况下，很明显我们应该考虑其他JVM，因此我们决定尝试Azul Zing JVM。
很快，我们就可以实现极高的吞吐量，而暂停时间却可以忽略不计。
这是因为Zing使用称为C4（连续并发压缩收集器）的唯一收集器，该收集器无论Java堆大小（最大为8 TB）如何，都可以进行无中断的垃圾收集。
这是通过在应用程序仍在运行时同时映射和压缩内存来实现的。
此外，它不需要任何代码更改，并且不需要冗长的配置即可立即获得延迟和速度方面的改进。
在这种情况下，Java程序员可以享受两全其美的优势，即Java的简单性（无需对创建新对象抱有幻想）以及Zing的基础性能，从而可以在整个系统中实现高度可预测的延迟。
由于GC容易，通用GC日志分析，我们可以quicky在一个真正的自动交易程序比较两者的JVM（在模拟环境中）。
在我们的应用程序中，Zing的GC大约是标准Oracle Hotspot JVM的180倍。
更为令人印象深刻的是，虽然GC暂停通常对应于实际的应用程序暂停时间，但Zing智能GC通常并行进行，实际中断最少或没有。