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

关注

原创最新推荐文章于 2026-04-08 14:56:16 发布 749 阅读 AI 写同款· GEO 优化 ›

来来来！告诉你为什么要用Java开发高频交易系统 过去 14 年，我们一直用 Java 开发外汇算法交易系统，并使用了很棒但价格实惠的硬件。这一切是怎样实现的？在高频交易领域，自动化应用程序每天需要处理数亿个市场交易信号，并在全球各交易所之间发送成千上万的订单。为了保持竞争力，响应时间必须始终保持在微秒级，特别是在发生类似“黑天鹅”事件的异常高峰期。在一个典型的架构中，金融市场的交易信号被转换成内部的市场数据格式 (使用各种协议，如 TCP/IP、UDP 组播和多种格式，如二进制、SBE、JSON、FIX 等)。这些规范化的消息被发送到阅读详情

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

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

在一个典型的架构中，金融市场的交易信号被转换成内部的市场数据格式(使用各种协议，如 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)：

Java在运行过程中编译代码(JIT)，这意味着当它第一次运行某些代码时，会有编译延迟。
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 对经常被调用的代码部分进行编译。它甚至可能会根据经验做出一些假设(某些代码永远不会被调用，或者某个对象始终是一个字符串)。

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

一个方法需要被调用一定次数才能达到编译阈值，然后才能被编译和优化(这个阈值是可配置的，通常在10000次左右)。在此之前，未优化的代码不会“全速”运行。在更快的编译和高质量的编译之间存在折衷(如果假设是错误的，就会发生编译成本)。
当Java应用程序重新启动时，我们又回到了起点，必须等待再次达到阈值。
有些应用程序有一些不常被调用但很关键的方法，这些方法只会被调用几次，但在被调用时需要非常快。

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

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

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

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