C++還是Java 哪個響應高頻交易應用比較快？

概述高頻交易的最佳解決方案是什麽？對於這個問題，觀點壹直比較沖突，部分原因是人們不知道什麽叫高頻交易並且與人們想象的總是存在差異，其次是速度問題，用哪種語言開發速度會快點，本文作者拿當今非常流行的C++和Java這兩種語言進行比較。如果妳是壹個典型的Java和C++程序員，並且用這兩種語言編寫過典型的面向對象程序。在相同的時間下面編寫高頻解決方案，Java程序員有可能會提前完成程序並且有時間調整應用程序。在這種情形下，恕我直言，Java應用程序的速度會快些。以我的經驗，Java在執行上會好於C++，因為Java進行微基準測試，其實它沒有做什麽事情。但是如果沒有時間限制，對Java和C++程序進行調優，那麽C++程序會比Java快些。然而，考慮到資源的有限性和環境的不斷變化，壹個充滿活力的語言可能會現實應用中超常發揮。在股票交易這種高頻市場，即使延遲10微秒都需要認真對待。 Java甚至標準的OOP C++，用在商業硬件上都不是最佳選擇，妳需要借助C或者精簡版的C++和壹些專業的硬件工具，例如FPGAs、GPUs。然而，在外匯（FX：Foreign Exchange）市場，高頻意味著延遲時間不低於100微秒。在這個的環境下，C++或者Java（低GC）都是個不錯的選擇。個人認為，在不斷變化的交易場所，Java擁有更多的靈活性。當人們討論高頻率時，尤其是在做銀行系統的時候，他們想把時間縮短1毫秒或者單單幾毫秒。在這樣的情況下，我會說，靈活/多態的Java、Scala或者C#等語言在編程時間上將會更加充裕，可維護性或可靠性優勢將會超過C/C++或FPGA。Java所面臨的問題問題不在於這樣的語言上，而是缺乏緩存控制和上下文交互。如果妳復制壹塊在本地已經操作過的內存，但是在運行之間使用不同的延遲，副本將會變慢。原因是部分緩存被交換出去，而復制本身也需要壹些時間。這和訪問內存的任何操作是壹樣的。例如，訪問計劃對象將會更慢。private void doTest(Pauser delay) throws InterruptedException { int[] times = new int[1000 * 1000]; byte[] bytes = new byte[32* 1024]; byte[] bytes2 = new byte[32 * 1024]; long end = System.nanoTime() + (long) 5e9; int i; for (i = 0; i < times.length; i++) { long start = System.nanoTime(); System.arraycopy(bytes, 0, bytes2, 0, bytes.length); long time = System.nanoTime() - start; times[i] = (int) time; delay.pause(); if (start > end) break; } Arrays.sort(times, 0, i); System.out.printf(delay + ": Copy memory latency 1/50/99%%tile %.1f/%.1f/%.1f us%n", times[i / 100] / 1e3, times[i / 2] / 1e3, times[i - i / 100 - 1] / 1e3 ); } 這個測試其實是在多次執行同壹件任務，在執行之間使用不同的延時。其中大部分時間都花在本地方法上，在測試期間沒有創建或拋棄對象。YIELD: Copy memory latency 1/50/99%tile 1.6/1.6/2.3 us NO_WAIT: Copy memory latency 1/50/99%tile 1.6/1.6/1.6 us BUSY_WAIT_10: Copy memory latency 1/50/99%tile 2.8/3.5/4.4 us BUSY_WAIT_3: Copy memory latency 1/50/99%tile 2.7/3.0/4.0 us BUSY_WAIT_1: Copy memory latency 1/50/99%tile 1.6/1.6/2.5 us SLEEP_10: Copy memory latency 1/50/99%tile 2.2/3.4/5.1 us SLEEP_3: Copy memory latency 1/50/99%tile 2.2/3.4/4.4 us SLEEP_1: Copy memory latency 1/50/99%tile 1.8/3.4/4.2 us -XX+Java 7的UseLargePagesYIELD: Copy memory latency 1/50/99%tile 1.6/1.6/2.7 us NO_WAIT: Copy memory latency 1/50/99%tile 1.6/1.6/1.8 us BUSY_WAIT_10: Copy memory latency 1/50/99%tile 2.7/3.6/6.6 us BUSY_WAIT_3: Copy memory latency 1/50/99%tile 2.7/2.8/5.0 us BUSY_WAIT_1: Copy memory latency 1/50/99%tile 1.7/1.8/2.6 us SLEEP_10: Copy memory latency 1/50/99%tile 2.4/4.0/5.2 us SLEEP_3: Copy memory latency 1/50/99%tile 2.3/3.9/4.8 us SLEEP_1: Copy memory latency 1/50/99%tile 2.1/3.3/3.7 us 上面是最好的三種運行。進行內存拷貝的典型時間（中間值）是1.6到4.6微秒，依據是否有線程在繁忙等待或休眠狀態上使用了1到10毫秒。這大概是3倍的比率，並且與Java無關，這是因為它沒有真正的控制權。即使在最好的情況下時間差大概也是2倍。代碼ThreadlatencyTest.java總結在極端高頻情況下，核心引擎壹般會用C、匯編和定制的硬件實現比使用C++或JAVA面向對象實現的方式多。由於延遲需求不再那麽緊張（指當基礎平臺使用C/C++搭建架構之後，應用平臺層面，時間響應已不是很重要，反而開發響應更重要）。因此Java和其他動態語言可能會變得更富有成效，在這種情形下，選擇Java或許可以幫妳輕松應對不斷變化的市場/需求。