過去 14 年，我們一直用 Java 開發(fā)外匯算法交易系統(tǒng)，并使用了很棒但價格實惠的硬件。這一切是怎樣實現(xiàn)的？

[[352413]]

在高頻交易領(lǐng)域，自動化應(yīng)用程序每天需要處理數(shù)億個市場交易信號，并在全球各交易所之間發(fā)送成千上萬的訂單。

為了保持競爭力，響應(yīng)時間必須始終保持在微秒級，特別是在發(fā)生類似“黑天鵝”事件的異常高峰期。

在一個典型的架構(gòu)中，金融市場的交易信號被轉(zhuǎn)換成內(nèi)部的市場數(shù)據(jù)格式 (使用各種協(xié)議，如 TCP/IP、UDP 組播和多種格式，如二進制、SBE、JSON、FIX 等)。

這些規(guī)范化的消息被發(fā)送到算法服務(wù)器、統(tǒng)計引擎、用戶界面、日志服務(wù)器和各種類型的數(shù)據(jù)庫 (內(nèi)存數(shù)據(jù)庫、物理數(shù)據(jù)庫、分布式數(shù)據(jù)庫)。

這條路徑上的任何一個延遲都有可能帶來嚴重后果（比如基于舊價格做出戰(zhàn)略決策或訂單到達交易市場的時間太遲），并為此付出慘重代價。

為了加快至關(guān)重要的幾微秒，大多數(shù)券商投入了昂貴的硬件：服務(wù)器組配備了超頻液冷的 CPU(在 2020 年，你可以買到單臺配備了 56 核 5.6 GHz CPU 和 1 TB 內(nèi)存的服務(wù)器)、靠近交易所的數(shù)據(jù)中心、納秒級高端網(wǎng)絡(luò)交換機、海底專線 (Hibernian Express 是一家主要的供應(yīng)商)，甚至是微波網(wǎng)絡(luò)。

我們經(jīng)常看到高度定制的可以繞過操作系統(tǒng)的 Linux 內(nèi)核，數(shù)據(jù)可以直接從網(wǎng)卡“跳轉(zhuǎn)”到應(yīng)用程序、IPC(進程間通信)，甚至是 FPGA(可編程單用途芯片)。

在編程語言方面，C++ 似乎是服務(wù)器端應(yīng)用程序的天然競爭者：它速度快，與機器碼非常接近，而且一旦針對目標平臺進行編譯，就可以提供恒定的處理時間。

但是，我們做了一個不一樣的選擇。

在過去的 14 年里，我們一直在用 Java 開發(fā)外匯算法交易系統(tǒng)，并使用了很棒但價格實惠的硬件。

由于團隊規(guī)模小，資源有限，技術(shù)能力強的開發(fā)人員難找，所以使用 Java 意味著我們可以快速地改進軟件功能，因為 Java 生態(tài)系統(tǒng)比 C 語言生態(tài)系統(tǒng)的發(fā)布速度更快。上午討論功能改進，下午就可以實現(xiàn)、測試并發(fā)布到生產(chǎn)環(huán)境。

與那些需要幾周甚至幾個月才能發(fā)布更新的大公司相比，這是一個關(guān)鍵的優(yōu)勢。在高頻交易領(lǐng)域，一個漏洞可以在幾秒鐘內(nèi)抹掉一整年的利潤，所以我們不打算在質(zhì)量上做任何妥協(xié)。我們搭建了一個嚴格的敏捷開發(fā)環(huán)境，包括 Jenkins、Maven、單元測試、夜晚構(gòu)建和 Jira，使用了很多開源庫和項目。

使用 Java，開發(fā)人員可以專注于直觀的面向?qū)ο髽I(yè)務(wù)邏輯，而不是浪費時間去調(diào)試一些晦澀的內(nèi)存核心轉(zhuǎn)儲或管理 C++ 指針。而且，由于 Java 強大的內(nèi)存管理能力，即使是初級程序員也可以在第一天加入項目時為系統(tǒng)帶來價值，而且風險很小。

有了良好的設(shè)計模式和干凈的編碼習慣，Java 的速度可與 C++ 相媲美。

例如，Java 會優(yōu)化和編譯在應(yīng)用程序運行期間觀察到的最佳路徑，但 C++ 會預(yù)先編譯所有東西，因此即使未被使用的方法也會成為可執(zhí)行二進制文件的一部分。

但是，Java 有一個問題，它讓 Java 成為一門強大且令人喜愛的編程語言，但也成了 Java 的缺點之一 (至少對于微秒級應(yīng)用程序來說)——Java 虛擬機 (JVM)：

• Java 在運行過程中編譯代碼 (JIT)，這意味著當它第一次運行某些代碼時，會有編譯延遲。
• Java 管理內(nèi)存的方式是在“堆”空間中分配內(nèi)存塊。每隔一段時間，它就會清理空間，移除舊對象，為新對象騰出空間。主要的問題是，為了進行準確的計數(shù)，應(yīng)用程序線程需要暫時“凍結(jié)”。這個過程稱為垃圾回收 (GC)。

GC 是低延遲應(yīng)用程序開發(fā)人員可能會放棄 Java 的主要原因。

市場上有一些可用的 Java 虛擬機。

最常見的是 Oracle Hotspot JVM，它在 Java 社區(qū)中被廣泛使用，主要是一些歷史原因。

對于非?？量痰膽?yīng)用程序，有一個很棒的替代方案，也就是 Azul Systems 的 Zing。

Zing 是標準 Oracle Hotspot JVM 的一個強大的替代品。Zing 解決了 GC 停頓和 JIT 編譯問題。

接下來，讓我們來研究一下 Java 的一些固有問題和可能的解決方案。

1. 了解 Java 的 JIT 編譯器

像 C++ 這樣的編程語言被稱為編譯型語言，因為發(fā)布的代碼完全是二進制的，可以直接在 CPU 上執(zhí)行。

PHP 或 Perl 被稱為解釋型語言，因為解釋器 (安裝在目標機器上) 會在運行時編譯每一行代碼。

Java 介于兩者之間，它將代碼編譯成 Java 字節(jié)碼，并在必要時再將其編譯成二進制的。

Java 不在啟動時編譯代碼的原因與后續(xù)的性能優(yōu)化有關(guān)。通過觀察應(yīng)用程序運行并分析實時方法調(diào)用和類初始化情況，Java 對經(jīng)常被調(diào)用的代碼部分進行編譯。它甚至可能會根據(jù)經(jīng)驗做出一些假設(shè) (某些代碼永遠不會被調(diào)用，或者某個對象始終是一個字符串)。

編譯過的代碼執(zhí)行速度非?？?，但有三個缺點：

• 一個方法需要被調(diào)用一定次數(shù)才能達到編譯閾值，然后才能被編譯和優(yōu)化 (這個閾值是可配置的，通常在 10000 次左右)。在此之前，未優(yōu)化的代碼不會“全速”運行。在更快的編譯和高質(zhì)量的編譯之間存在折衷 (如果假設(shè)是錯誤的，就會發(fā)生編譯成本)。
• 當 Java 應(yīng)用程序重新啟動時，我們又回到了起點，必須等待再次達到閾值。
• 有些應(yīng)用程序有一些不常被調(diào)用但很關(guān)鍵的方法，這些方法只會被調(diào)用幾次，但在被調(diào)用時需要非?？?。

Zing 通過讓它的 JVM“保存”已編譯的方法和類的狀態(tài)（也就是所謂的 profile）來解決這些問題。這個獨特的功能叫做 ReadyNow，也就是說 Java 應(yīng)用程序可以始終以最佳速度運行，即使是在重啟之后。

當你使用已有的 profile 重新啟動應(yīng)用程序，Azul JVM 會立即收回以前的決策并直接編譯重要的方法，以解決 Java 的預(yù)熱問題。

此外，你也可以在開發(fā)環(huán)境中構(gòu)建一個 profile 來模擬生產(chǎn)行為。優(yōu)化后的 profile 能部署到生產(chǎn)環(huán)境中，并知道所有關(guān)鍵路徑都已經(jīng)過編譯和優(yōu)化。

下圖顯示了交易應(yīng)用程序 (在模擬環(huán)境中) 的最大延遲。

Hotspot JVM 的延時峰值是顯而易見的，而 Zing 的延時保持得相當穩(wěn)定。

百分比分布表明，在 1% 的時間內(nèi)，Hotspot JVM 發(fā)生的延遲是 Zing JVM 的 16 倍。

2. 解決垃圾回收停頓問題

第二個問題是在垃圾回收期間，整個應(yīng)用程序可能會停頓幾毫秒到幾秒鐘 (延遲會隨著代碼復(fù)雜性和堆大小的增加而增加)，更糟糕的是，你無法控制這種情況何時發(fā)生。

雖然對很多 Java 應(yīng)用程序來說，暫停應(yīng)用程序幾毫秒甚至幾秒是可以接受的，但對于低延遲應(yīng)用程序來說，這是一場災(zāi)難，無論是在汽車、航空航天、醫(yī)療還是金融領(lǐng)域。

GC 影響對于 Java 開發(fā)人員來說是一個很大話題，F(xiàn)ull GC 通常也叫作“停止世界的停頓（stop-the-world)”，因為它會凍結(jié)整個應(yīng)用程序。

多年來，有很多 GC 算法都試圖降低吞吐量 (有多少 CPU 時間用于應(yīng)用程序邏輯執(zhí)行而不是垃圾回收) 和 GC 停頓 (我可以暫停應(yīng)用程序多長時間)。

從 Java 9 發(fā)布以來，G1 一直是默認的垃圾回收器，其主要思想是根據(jù)用戶提供的時間目標對 GC 停頓進行劃分。它通常提供較短的停頓時間，但以降低吞吐量為代價。此外，停頓時間隨著堆的大小而增加。

Java 提供了大量的設(shè)置參數(shù)，從堆大小到回收算法以及分配給 GC 的線程數(shù)。因此，Java 應(yīng)用程序通常會配置大量的參數(shù)：

很多開發(fā)人員通過各種技術(shù)來避免 GC。最主要的是，如果我們少創(chuàng)建一些對象，那么后續(xù)要清除的對象就越少。

一種古老的 (仍然在使用) 技術(shù)是使用對象池。例如，數(shù)據(jù)庫連接池可以保存 10 個已經(jīng)打開的數(shù)據(jù)庫連接，以便在需要時使用。

多線程通常需要鎖，這會導致同步延遲和停頓 (特別是當它們共享資源時)。一種流行的方式是使用環(huán)形緩沖隊列系統(tǒng)，多個線程可以在一個無鎖的環(huán)境中（請參考 disruptor）進行讀寫操作。

https://lmax-exchange.github.io/disruptor/

一些專家甚至處于無奈而選擇完全覆蓋 Java 的內(nèi)存管理機制，由自己來管理內(nèi)存分配，這雖然解決了問題，但也帶來了更多的復(fù)雜性和風險。

因此，我們需要考慮使用其他 JVM，于是我們決定嘗試 Azul Zing JVM。

很快，我們就能夠在幾乎無停頓的情況下實現(xiàn)很高的吞吐量。

這是因為 Zing 使用了一個叫作 C4(Continuously Concurrent Compacting Collector，連續(xù)并發(fā)壓縮回收器) 的垃圾回收器，它可以進行無停頓的垃圾回收，而不管 Java 堆有多大 (可以達到 8TB)。

這是通過在應(yīng)用程序運行時并發(fā)映射和壓縮內(nèi)存來實現(xiàn)的。

此外，它不需要修改代碼，而且延遲和速度方面的改進都是開箱即用的，不需要進行繁雜的配置。

Java 程序員可以享受到兩方面的好處：Java 的簡單性 (不需要擔心創(chuàng)建太多的新對象) 和 Zing 的底層性能，允許系統(tǒng)中出現(xiàn)高度可預(yù)測的延遲。

GCeasy 提供了通用 GC 日志分析器，我們可以在真實的自動交易應(yīng)用程序 (在模擬環(huán)境中) 中快速地對 JVM 進行比較。

https://gceasy.io/

在我們的應(yīng)用程序中，使用 Zing 的 GC 大約比使用標準 Oracle Hotspot JVM 的 GC 快 180 倍。

更令人印象深刻的是，GC 停頓通常對應(yīng)于實際的應(yīng)用程序停頓時間，而 Zing 的 GC 通常是并行發(fā)生的，實際的停頓很少，甚至沒有停頓。

總之，在享受 Java 的簡單和特性的同時，仍然有可能實現(xiàn)高性能和低延遲。C++ 一般用于開發(fā)特定的底層組件，如驅(qū)動程序、數(shù)據(jù)庫、編譯器和操作系統(tǒng)，但大多數(shù)現(xiàn)實生活中的應(yīng)用程序可以使用 Java 開發(fā)，甚至是要求很高的應(yīng)用程序。

這就是為什么 Java 是排名第一的編程語言（根據(jù) Oracle 的說法），并擁有數(shù)百萬開發(fā)者，在全世界有超過 510 億個 Java 虛擬機。