为什么我们选择Java开发高频交易系统？

在高频交易领域，自动化应用程序每天需要处理数亿个市场交易信号，并在全球各交易所之间发送成千上万的订单。

为了保持竞争力，响应时间必须始终保持在微秒级，特别是在发生类似“黑天鹅”事件的异常高峰期。

在一个典型的架构中，金融市场的交易信号被转换成内部的市场数据格式(使用各种协议，如 TCP/IP、UDP 组播和多种格式，如二进制、SBE、JSON、FIX 等)。

这些规范化的消息被发送到算法服务器、统计引擎、用户界面、日志服务器和各种类型的数据库(内存数据库、物理数据库、分布式数据库)。

这条路径上的任何一个延迟都有可能带来严重后果（比如基于旧价格做出战略决策或订单到达交易市场的时间太迟），并为此付出惨重代价。

为了加快至关重要的几微秒，大多数券商投入了昂贵的硬件：服务器组配备了超频液冷的 CPU(在 2020 年，你可以买到单台配备了 56 核 5.6 GHz CPU 和 1 TB 内存的服务器)、靠近交易所的数据中心、纳秒级高端网络交换机、海底专线(Hibernian Express 是一家主要的供应商)，甚至是微波网络。

我们经常看到高度定制的可以绕过操作系统的 Linux 内核，数据可以直接从网卡“跳转”到应用程序、IPC(进程间通信)，甚至是 FPGA(可编程单用途芯片)。

在编程语言方面，C++似乎是服务器端应用程序的天然竞争者：它速度快，与机器码非常接近，而且一旦针对目标平台进行编译，就可以提供恒定的处理时间。

但是，我们做了一个不一样的选择。

在过去的14年里，我们一直在用Java开发外汇算法交易系统，并使用了很棒但价格实惠的硬件。

由于团队规模小，资源有限，技术能力强的开发人员难找，所以使用 Java 意味着我们可以快速地改进软件功能，因为 Java 生态系统比 C 语言生态系统的发布速度更快。上午讨论功能改进，下午就可以实现、测试并发布到生产环境。

与那些需要几周甚至几个月才能发布更新的大公司相比，这是一个关键的优势。在高频交易领域，一个漏洞可以在几秒钟内抹掉一整年的利润，所以我们不打算在质量上做任何妥协。我们搭建了一个严格的敏捷开发环境，包括 Jenkins、Maven、单元测试、夜晚构建和 Jira，使用了很多开源库和项目。

使用 Java，开发人员可以专注于直观的面向对象业务逻辑，而不是浪费时间去调试一些晦涩的内存核心转储或管理 C++指针。而且，由于 Java 强大的内存管理能力，即使是初级程序员也可以在第一天加入项目时为系统带来价值，而且风险很小。

有了良好的设计模式和干净的编码习惯，Java 的速度可与 C++相媲美。

例如，Java 会优化和编译在应用程序运行期间观察到的最佳路径，但 C++会预先编译所有东西，因此即使未被使用的方法也会成为可执行二进制文件的一部分。

但是，Java 有一个问题，它让 Java 成为一门强大且令人喜爱的编程语言，但也成了 Java 的缺点之一(至少对于微秒级应用程序来说)——Java 虚拟机(JVM)：

1. Java在运行过程中编译代码(JIT)，这意味着当它第一次运行某些代码时，会有编译延迟。

2. Java管理内存的方式是在“堆”空间中分配内存块。每隔一段时间，它就会清理空间，移除旧对象，为新对象腾出空间。主要的问题是，为了进行准确的计数，应用程序线程需要暂时“冻结”。这个过程称为垃圾回收(GC)。

GC 是低延迟应用程序开发人员可能会放弃 Java 的主要原因。

市场上有一些可用的 Java 虚拟机。

最常见的是 Oracle Hotspot JVM，它在 Java 社区中被广泛使用，主要是一些历史原因。

对于非常苛刻的应用程序，有一个很棒的替代方案，也就是 Azul Systems 的 Zing。

Zing 是标准 Oracle Hotspot JVM 的一个强大的替代品。Zing 解决了 GC 停顿和 JIT 编译问题。

接下来，让我们来研究一下 Java 的一些固有问题和可能的解决方案。

了解 Java 的 JIT 编译器

像 C++这样的编程语言被称为编译型语言，因为发布的代码完全是二进制的，可以直接在 CPU 上执行。

PHP 或 Perl 被称为解释型语言，因为解释器(安装在目标机器上)会在运行时编译每一行代码。

Java 介于两者之间，它将代码编译成 Java 字节码，并在必要时再将其编译成二进制的。

Java 不在启动时编译代码的原因与后续的性能优化有关。通过观察应用程序运行并分析实时方法调用和类初始化情况，Java 对经常被调用的代码部分进行编译。它甚至可能会根据经验做出一些假设(某些代码永远不会被调用，或者某个对象始终是一个字符串)。

编译过的代码执行速度非常快，但有三个缺点：

1. 一个方法需要被调用一定次数才能达到编译阈值，然后才能被编译和优化(这个阈值是可配置的，通常在10000次左右)。在此之前，未优化的代码不会“全速”运行。在更快的编译和高质量的编译之间存在折衷(如果假设是错误的，就会发生编译成本)。

2. 当Java应用程序重新启动时，我们又回到了起点，必须等待再次达到阈值。

3. 有些应用程序有一些不常被调用但很关键的方法，这些方法只会被调用几次，但在被调用时需要非常快。

Zing 通过让它的 JVM“保存”已编译的方法和类的状态（也就是所谓的 profile）来解决这些问题。这个独特的功能叫做 ReadyNow，也就是说 Java 应用程序可以始终以最佳速度运行，即使是在重启之后。

当你使用已有的 profile 重新启动应用程序，Azul JVM 会立即收回以前的决策并直接编译重要的方法，以解决 Java 的预热问题。

此外，你也可以在开发环境中构建一个 profile 来模拟生产行为。优化后的 profile 能部署到生产环境中，并知道所有关键路径都已经过编译和优化。

下图显示了交易应用程序(在模拟环境中)的最大延迟。

Hotspot JVM 的延时峰值是显而易见的，而 Zing 的延时保持得相当稳定。

百分比分布表明，在 1%的时间内，Hotspot JVM 发生的延迟是 Zing JVM 的 16 倍。

解决垃圾回收停顿问题

第二个问题是在垃圾回收期间，整个应用程序可能会停顿几毫秒到几秒钟(延迟会随着代码复杂性和堆大小的增加而增加)，更糟糕的是，你无法控制这种情况何时发生。

虽然对很多 Java 应用程序来说，暂停应用程序几毫秒甚至几秒是可以接受的，但对于低延迟应用程序来说，这是一场灾难，无论是在汽车、航空航天、医疗还是金融领域。

GC 影响对于 Java 开发人员来说是一个很大话题，Full GC 通常也叫作“停止世界的停顿（stop-the-world)”，因为它会冻结整个应用程序。

多年来，有很多 GC 算法都试图降低吞吐量(有多少 CPU 时间用于应用程序逻辑执行而不是垃圾回收)和 GC 停顿(我可以暂停应用程序多长时间)。

从 Java 9 发布以来，G1 一直是默认的垃圾回收器，其主要思想是根据用户提供的时间目标对 GC 停顿进行划分。它通常提供较短的停顿时间，但以降低吞吐量为代价。此外，停顿时间随着堆的大小而增加。

Java 提供了大量的设置参数，从堆大小到回收算法以及分配给 GC 的线程数。因此，Java 应用程序通常会配置大量的参数：

很多开发人员通过各种技术来避免 GC。最主要的是，如果我们少创建一些对象，那么后续要清除的对象就越少。

一种古老的(仍然在使用)技术是使用对象池。例如，数据库连接池可以保存 10 个已经打开的数据库连接，以便在需要时使用。

多线程通常需要锁，这会导致同步延迟和停顿(特别是当它们共享资源时)。一种流行的方式是使用环形缓冲队列系统，多个线程可以在一个无锁的环境中（请参考disruptor）进行读写操作。

一些专家甚至处于无奈而选择完全覆盖 Java 的内存管理机制，由自己来管理内存分配，这虽然解决了问题，但也带来了更多的复杂性和风险。

因此，我们需要考虑使用其他 JVM，于是我们决定尝试 Azul Zing JVM。

很快，我们就能够在几乎无停顿的情况下实现很高的吞吐量。

这是因为 Zing 使用了一个叫作 C4(Continuously Concurrent Compacting Collector，连续并发压缩回收器)的垃圾回收器，它可以进行无停顿的垃圾回收，而不管 Java 堆有多大(可以达到 8TB)。

这是通过在应用程序运行时并发映射和压缩内存来实现的。

此外，它不需要修改代码，而且延迟和速度方面的改进都是开箱即用的，不需要进行繁杂的配置。

Java 程序员可以享受到两方面的好处：Java 的简单性(不需要担心创建太多的新对象)和 Zing 的底层性能，允许系统中出现高度可预测的延迟。

GCeasy提供了通用 GC 日志分析器，我们可以在真实的自动交易应用程序(在模拟环境中)中快速地对 JVM 进行比较。

在我们的应用程序中，使用 Zing 的 GC 大约比使用标准 Oracle Hotspot JVM 的 GC 快 180 倍。

更令人印象深刻的是，GC 停顿通常对应于实际的应用程序停顿时间，而 Zing 的 GC 通常是并行发生的，实际的停顿很少，甚至没有停顿。

总之，在享受 Java 的简单和特性的同时，仍然有可能实现高性能和低延迟。C++一般用于开发特定的底层组件，如驱动程序、数据库、编译器和操作系统，但大多数现实生活中的应用程序可以使用 Java 开发，甚至是要求很高的应用程序。

这就是为什么 Java 是排名第一的编程语言（根据 Oracle 的说法），并拥有数百万开发者，在全世界有超过 510 亿个 Java 虚拟机。

原文链接：

https://medium.com/@jadsarmo/why-we-chose-java-for-our-high-frequency-trading-application-600f7c04da94