為什么我們選擇Java開發高頻交易系統？
過去 14 年，我們一直用 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)：
- Java 在運行過程中編譯代碼 (JIT)，這意味著當它第一次運行某些代碼時，會有編譯延遲。
- Java 管理內存的方式是在“堆”空間中分配內存塊。每隔一段時間，它就會清理空間，移除舊對象，為新對象騰出空間。主要的問題是，為了進行準確的計數，應用程序線程需要暫時“凍結”。這個過程稱為垃圾回收 (GC)。
GC 是低延遲應用程序開發人員可能會放棄 Java 的主要原因。
市場上有一些可用的 Java 虛擬機。
最常見的是 Oracle Hotspot JVM，它在 Java 社區中被廣泛使用，主要是一些歷史原因。
對于非常苛刻的應用程序，有一個很棒的替代方案，也就是 Azul Systems 的 Zing。
Zing 是標準 Oracle Hotspot JVM 的一個強大的替代品。Zing 解決了 GC 停頓和 JIT 編譯問題。
接下來，讓我們來研究一下 Java 的一些固有問題和可能的解決方案。
1. 了解 Java 的 JIT 編譯器
像 C++ 這樣的編程語言被稱為編譯型語言，因為發布的代碼完全是二進制的，可以直接在 CPU 上執行。
PHP 或 Perl 被稱為解釋型語言，因為解釋器 (安裝在目標機器上) 會在運行時編譯每一行代碼。
Java 介于兩者之間，它將代碼編譯成 Java 字節碼，并在必要時再將其編譯成二進制的。
Java 不在啟動時編譯代碼的原因與后續的性能優化有關。通過觀察應用程序運行并分析實時方法調用和類初始化情況，Java 對經常被調用的代碼部分進行編譯。它甚至可能會根據經驗做出一些假設 (某些代碼永遠不會被調用，或者某個對象始終是一個字符串)。
編譯過的代碼執行速度非常快，但有三個缺點：
- 一個方法需要被調用一定次數才能達到編譯閾值，然后才能被編譯和優化 (這個閾值是可配置的，通常在 10000 次左右)。在此之前，未優化的代碼不會“全速”運行。在更快的編譯和高質量的編譯之間存在折衷 (如果假設是錯誤的，就會發生編譯成本)。
- 當 Java 應用程序重新啟動時，我們又回到了起點，必須等待再次達到閾值。
- 有些應用程序有一些不常被調用但很關鍵的方法，這些方法只會被調用幾次，但在被調用時需要非常快。
Zing 通過讓它的 JVM“保存”已編譯的方法和類的狀態（也就是所謂的 profile）來解決這些問題。這個獨特的功能叫做 ReadyNow，也就是說 Java 應用程序可以始終以最佳速度運行，即使是在重啟之后。
當你使用已有的 profile 重新啟動應用程序，Azul JVM 會立即收回以前的決策并直接編譯重要的方法，以解決 Java 的預熱問題。
此外，你也可以在開發環境中構建一個 profile 來模擬生產行為。優化后的 profile 能部署到生產環境中，并知道所有關鍵路徑都已經過編譯和優化。
下圖顯示了交易應用程序 (在模擬環境中) 的最大延遲。
Hotspot JVM 的延時峰值是顯而易見的，而 Zing 的延時保持得相當穩定。
百分比分布表明，在 1% 的時間內，Hotspot JVM 發生的延遲是 Zing JVM 的 16 倍。
2. 解決垃圾回收停頓問題
第二個問題是在垃圾回收期間，整個應用程序可能會停頓幾毫秒到幾秒鐘 (延遲會隨著代碼復雜性和堆大小的增加而增加)，更糟糕的是，你無法控制這種情況何時發生。
雖然對很多 Java 應用程序來說，暫停應用程序幾毫秒甚至幾秒是可以接受的，但對于低延遲應用程序來說，這是一場災難，無論是在汽車、航空航天、醫療還是金融領域。
GC 影響對于 Java 開發人員來說是一個很大話題，Full GC 通常也叫作“停止世界的停頓（stop-the-world)”，因為它會凍結整個應用程序。
多年來，有很多 GC 算法都試圖降低吞吐量 (有多少 CPU 時間用于應用程序邏輯執行而不是垃圾回收) 和 GC 停頓 (我可以暫停應用程序多長時間)。
從 Java 9 發布以來，G1 一直是默認的垃圾回收器，其主要思想是根據用戶提供的時間目標對 GC 停頓進行劃分。它通常提供較短的停頓時間，但以降低吞吐量為代價。此外，停頓時間隨著堆的大小而增加。
Java 提供了大量的設置參數，從堆大小到回收算法以及分配給 GC 的線程數。因此，Java 應用程序通常會配置大量的參數：
很多開發人員通過各種技術來避免 GC。最主要的是，如果我們少創建一些對象，那么后續要清除的對象就越少。
一種古老的 (仍然在使用) 技術是使用對象池。例如，數據庫連接池可以保存 10 個已經打開的數據庫連接，以便在需要時使用。
多線程通常需要鎖，這會導致同步延遲和停頓 (特別是當它們共享資源時)。一種流行的方式是使用環形緩沖隊列系統，多個線程可以在一個無鎖的環境中（請參考 disruptor）進行讀寫操作。
https://lmax-exchange.github.io/disruptor/
一些專家甚至處于無奈而選擇完全覆蓋 Java 的內存管理機制，由自己來管理內存分配，這雖然解決了問題，但也帶來了更多的復雜性和風險。
因此，我們需要考慮使用其他 JVM，于是我們決定嘗試 Azul Zing JVM。
很快，我們就能夠在幾乎無停頓的情況下實現很高的吞吐量。
這是因為 Zing 使用了一個叫作 C4(Continuously Concurrent Compacting Collector，連續并發壓縮回收器) 的垃圾回收器，它可以進行無停頓的垃圾回收，而不管 Java 堆有多大 (可以達到 8TB)。
這是通過在應用程序運行時并發映射和壓縮內存來實現的。
此外，它不需要修改代碼，而且延遲和速度方面的改進都是開箱即用的，不需要進行繁雜的配置。
Java 程序員可以享受到兩方面的好處：Java 的簡單性 (不需要擔心創建太多的新對象) 和 Zing 的底層性能，允許系統中出現高度可預測的延遲。
GCeasy 提供了通用 GC 日志分析器，我們可以在真實的自動交易應用程序 (在模擬環境中) 中快速地對 JVM 進行比較。
https://gceasy.io/
在我們的應用程序中，使用 Zing 的 GC 大約比使用標準 Oracle Hotspot JVM 的 GC 快 180 倍。
更令人印象深刻的是，GC 停頓通常對應于實際的應用程序停頓時間，而 Zing 的 GC 通常是并行發生的，實際的停頓很少，甚至沒有停頓。
總之，在享受 Java 的簡單和特性的同時，仍然有可能實現高性能和低延遲。C++ 一般用于開發特定的底層組件，如驅動程序、數據庫、編譯器和操作系統，但大多數現實生活中的應用程序可以使用 Java 開發，甚至是要求很高的應用程序。
這就是為什么 Java 是排名第一的編程語言（根據 Oracle 的說法），并擁有數百萬開發者，在全世界有超過 510 億個 Java 虛擬機。
