總覽

關于什么是高頻交易的最佳解決方案，存在不同意見。 問題的一部分是高頻交易的變化超出您的預期，另一部分是更快的含義。

我的看法

如果您有一個典型的Java程序員和一個典型的C ++程序員，并且每個人都有幾年編寫典型的面向對象程序的經驗，并且給了他們相同的時間，那么Java程序員可能會更早地擁有一個工作程序，并且將擁有更多的工作時間。是時候調整應用程序了。 在這種情況下，Java應用程序可能會更快。 恕我直言。

以我的經驗，Java在檢測不需要執行的代碼方面在C ++上表現更好。 esp微型基準測試，無濟于事。 ;）如果您在不花任何時間和精力的情況下盡可能地調優Java和C ++，那么C ++程序將更快。 但是，在有限的資源和不斷變化的環境中，動態語言將無法運行。 即在實際應用中。

在股票空間延遲中，您需要將潛伏期定為10到10毫秒以下才能使頻率很高。 不能選擇Java甚至商用硬件上的標準OOP C ++。 您需要C或C ++的精簡版以及專用硬件，例如FPGA，GPU。

在FX中，高頻意味著延遲小于100 us。 在此空間中，可以選擇使用C ++或帶有內核旁路網絡適配器的精簡Java（低GC）。 在這種情況下，使用一種或另一種語言將有加有減。 就個人而言，我認為隨著交流的不斷變化，Java會提供更大的靈活性，前提是您認為可以利用IT獲得競爭優勢。

在許多情況下，當人們談論高頻（尤其是Banks）時，他們說的是1 ms以下或一位數ms。 在這個領域，我想說Java，Scala或C＃等的靈活性/動態編程將給您時間，與C / C ++或FPGA相比，具有可維護性和可靠性方面的優勢。


Java面臨的問題

問題不在于語言本身，而是缺乏對緩存，上下文切換和中斷的控制。 如果復制一塊內存（發生在本機內存中，但是在運行之間使用了不同的延遲），則該副本會變慢，具體取決于副本之間發生的情況。

問題不是GC或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);
}

測試多次執行相同的操作，執行該測試之間的延遲有所不同。 該測試將大部分時間花費在本機方法上，并且沒有像在測試期間那樣創建或丟棄任何對象。

收益率：復制內存延遲1/50/99％tile 1.6 / 1.6 / 2.3 us
NO_WAIT：復制內存延遲1/50/99％tile 1.6 / 1.6 / 1.6 us
BUSY_WAIT_10：復制內存延遲時間為1/50/99％tile 3.1 / 3.5 / 4.4 us BUSY_WAIT_3：復制內存延遲時間為1/50/99％tile 2.7 / 3.0 / 4.0 us BUSY_WAIT_1：復制內存延遲時間為1/50/99％tile 1.6 / 1.6 / 2.6 us SLEEP_10：復制內存延遲時間為1/50/99％tile 2.3 / 3.7 / 5.2 us SLEEP_3：復制內存延遲時間為1/50/99％tile 2.7 / 4.4 / 4.8 us SLEEP_1：復制內存延遲時間為1/50/99％tile 2.8 / 4.6 / 5.0 us

執行內存復制所需的典型時間（中間值）在1.6到4.6 us之間，這取決于是否有1到10毫秒的繁忙等待或睡眠時間。 這個比率大約是Java的3倍，但與Java沒有任何關系。 甚至最好的時間也相差約2倍。


編碼

ThreadlatencyTest.java


結論

在超高頻下，核心引擎將比OOP C ++或Java更多的C，匯編和自定義硬件。 在引擎的延遲要求不太嚴格的市場中，C ++和Low GC Java成為了選擇。 隨著等待時間要求變得不那么嚴格，Java和其他動態語言可能會變得更有效率。 在這種情況下，Java可以更快地推向市場，因此您可以利用市場/需求變化中的優勢。

參考： C ++或Java，高頻交易更快？ 來自我們的JCG合作伙伴 Peter Lawrey在Vanilla Java 。

• Java中的低GC：使用原語而不是包裝器
• Java Lambda語法替代
• JVM如何處理鎖
• Erlang與Java內存架構
• Java Fork / Join進行并行編程
• Java最佳實踐系列
• 如何在Java中獲得類似于C的性能