关于什么是高频交易的最佳解决方案，存在不同意见。 问题的一部分是高频交易的变化超出您的预期，另一部分是更快的含义。

我的看法

如果您有一个典型的Java程序员和一个典型的C ++程序员，并且每个人都有几年编写典型的面向对象程序的经验，并且给了他们相同的时间，那么Java程序员可能会更早地拥有一个工作程序，并且将拥有更多的工作时间。是时候调整应用程序了。 在这种情况下，Java应用程序可能会更快。 恕我直言。

以我的经验，Java在检测不需要执行的代码方面在C ++上表现更好。 esp微型基准测试，没有任何用处。 ;）如果您以任意专业知识和时间调优Java和C ++的能力，C ++程序将更快。 但是，由于资源有限且在不断变化的环境中，动态语言将无法运行。 即在实际应用中。

在股票空间延迟中，您需要将潜伏期定为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毫秒的繁忙等待或睡眠时间。 这是大约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的性能