InfoQ有幸邀请到了这个领域的四位专家，跟他们一起讨论是什么推动了这一趋势，在这种情况下使用Java有哪些最佳实践。
与会者名单：
Peter Lawrey是一位对低延迟和高吞吐量系统很有兴趣的Java顾问。他曾为多家对冲基金、交易公司和投资银行提供过服务。
Martin Thompson是一位高性能和低延迟方面的专家，具有二十多年的大规模事务处理和大数据系统的工作经验，涉足过汽车、博彩、金融、移动和内容管理等领域。
Todd L. Montgomery是Informatica Ultra Messaging的副总架构师，29West低延迟消息传递产品的首席设计师和实现者。
Dr Andy Piper最近从Oracle离职加入到了Push Technology，任职首席技术官。
问题列表：
- 我们如何理解低延迟？它和实时一样吗？它与高性能代码一般有怎样的联系？
- 在其他情况下使用Java往往会提到以下优势：可以使用丰富的类库、框架和应用服务器等等，而且还有大量掌握它的程序员用户群。在编写低延迟代码时还有这些优势吗？如果没有，那与C++相比Java有哪些优势？
- JVM是如何支持并发程序的？
- 如果先不谈垃圾回收，那么Java还有哪些其他特有的技术有助于编写低延迟代码的技术（在C++中不会用到的技术）？我能想到的有JVM预热，把所有类加载到permgen中以避免IO，用于避免缓存未命中的Java专有技术等等。
- 管理垃圾回收行为对大家用Java编写低延迟代码的方式有怎样的影响？
- 在分析低延迟应用时，你有没有在性能的“峰值”和极端值背后发现任何常见原因或模式？
- Java 7已经开始支持基于InfiniBand设备的套接字直接协议（Sockets Direct Protocol，SDP）了。你是否已经看到有生产系统使用过它了？如果这项技术还没有被应用过，那么你看到有什么其他的解决方案吗？
- 下面的问题并不局限于Java，为什么我们需要尽量避免竞争？当我们无法避免竞争时如何能够更好地管理它？
- 在过去的几年里，你们有没有为了用Java做低延迟开发而做出过改变？
- Java是否适用于其他对性能比较敏感的工作？你会把它用于高频交易（HFT）系统吗？能否举个例子？或者说C++仍然是更好的选择？
问题1.InfoQ：我们如何理解低延迟？它和实时一样吗？它与高性能代码一般有怎样的联系？
Lawrey：对延迟有严格要求的系统，延迟的时间甚至快到人们根本就看不到。这种延迟时间仅在100纳秒到100毫秒之间。
Montgomery：实时和低延迟完全不同。大多数人对于“实时”的观点是确定性，即严格控制（甚至界定）峰值的纯粹的速度。然而，通常“低延迟”意味着要最大限度地追求纯粹的速度，与此同时可以容忍个别轻微的偏差。当思考硬实时系统时，这一点是肯定的。低延迟的一个先决条件就是要始终对效率保持足够的敏锐。从系统的角度看，这种效率必须渗透到全部应用栈、操作系统和网络中。这意味着低延迟系统必须让所有其他组件都能达到机械和应的程度。另外，最近几年在低延迟系统中涌现了许多技术，它们源自于操作系统、编程语言、虚拟机、协议、其他系统开发领域乃至硬件设计的高性能技术。
Thompson：性能无非就是两点——吞吐率（比如单位/秒）和响应时间（有时也称为等待时间）。最重要的是给出量化的指标，而不能只是说它应该“很快”。实时有非常明确的定义，但却经常被误用。实时与具体系统相关，这些系统在不考虑系统负载的情况下对输入事件到其响应有实际的时间限制。在硬实时系统中如果不能满足这些限制，那么整个系统就会出现故障。大家可以想一下心脏起博器或导弹控制系统，它们能帮我们更好地理解这一概念。
对于交易系统来说，实时系统更倾向于另外一种含义，那就是系统必须拥有高吞吐率并且尽快响应每个事件，这可以理解为“低延迟”。但如果有一次交易没有被及时处理并不代表整个系统发生了错误，所以严格意义上你不能把它称为实时。
好的交易系统要有高质量的执行，其中一个方面就是要有低延迟的响应，响应时间只能有很小的偏差。
Piper：简单来说延迟就是决策与行动之间的延时。在高性能计算环境下，低延迟通常意味着网络间的传输有很低的延迟时间或请求到响应间有很低的整体延迟时间。“低”的定义取决于具体环境，在互联网中低延迟可能是指在200毫秒以内，但是在交易应用中可能就是在2微秒之内了。从学术上来说低延迟与实时是有区别的，低延迟通常用百分比来度量，度量那些必须要掌握的异常值（未达到低延迟的情况）。而如果是实时的话，你就必须保证系统行为在最大延时之内响应，而不再是度量延迟百分比。你会发现实时系统很容易做成低延迟系统，但反过来就很难了。但是现在，人们渐渐地已经不再严格区分这些概念了，会混着用这些术语。
假设延迟是从请求到响应的整体延迟时间，那么很明显延迟会受到以下诸多方面的影响：CPU、网络、操作系统、应用甚至物理定律。
问题2.InfoQ：在其他情况下使用Java往往会提到以下优势：可以使用丰富的类库、框架和应用服务器等等，而且还有大量掌握它的程序员用户群。在编写低延迟代码时还有这些优势吗？如果没有，那与C++相比Java有哪些优势？
Lawrey：如果你的应用把90%的时间花在了10%的代码上，那么Java很难去优化那10%的代码，但却很容易编写和维护剩下的那90%的代码，尤其是当团队能力水平参差不齐的时候。
Montgomery：在资本市场（特别是算法交易）中有很多可以发挥作用的因素。更快的算法投入市场时往往拥有更多的优势。许多算法都有搁置期，尽快进入市场是充分发挥其优势的关键。与C或C++截然不同，Java有更多社区和可用的选择，这无疑是它强大的竞争优势。虽然有时候纯理论上的低延迟可以不考虑其他关注点。但我想目前Java和C++的性能差异并不大，单纯从速度上讲并没有那么黑白分明。通过对垃圾回收技术、运行期编译执行技术优化与运行期的管理的改进，Java在一向比较薄弱的性能方面增加了一些非常令人赞叹的优势，这些优势不会轻易被人们忽视的。
Thompson：我们用Java编写低延迟系统时很少使用第三方甚至标准类库，主要有以下两个原因：首先，许多类库在编写时并没有专门考虑过性能，所以通常达不到令人满意的吞吐率和响应时间。其次，它们通常会用锁来控制并发，这样就会产成大量的垃圾，当锁竞争和垃圾回收时响应时间就会有很大的变数。
Java有几个最好的工具，这些工具可以支持任何语言，它们能非常有效地提升生产率。上市时间往往是构建交易系统时的一项关键要求，Java通常在这时总能占得先机。
Piper：很多方面都反过来了，以前很难用Java写好的低延迟代码，因为JVM把开发人员与硬件隔离开。这是一个非常好的转变，不仅让JVM更快、更容易预测了，而且现在开发人员充分理解了Java的工作机制（特别是Java内存模型）以及它与底层硬件之间的映射方式（Java可以称得上是第一个为程序员提供了全面的内存模型的流行语言了，C++也是在它之后才提供的），从而能够充分地发挥硬件的优势了。比如无锁、无等待技术都是比较好的例子，Martin Thompson和我们公司（Push）一直在推进这些技术的应用，在我们自己的开发中已经非常成功地应用了这些技术。此外，由于这些技术越来越流行了，我们发现它们正被引入到标准库中（例如Disruptor），所以开发人员在使用这些技术时已经无需再详细了解那些底层的行为了。
即使我们抛开这些技术不谈，Java的安全优势（内存管理、线程管理等）往往也比C++感觉上的性能优势更具价值，而且JVM供应商前段时间还声称主流的JVM通常比定制的C++代码更快，因为它们可以进行跨应用的整体优化。
问题3.InfoQ：JVM是如何支持并发程序的？
Lawrey：Java从一开始就内置了对多线程的支持，高并发支持标准已经有10年了。
Montgomery：JVM是一个很好的并发程序平台。它的内存模型使开发人员可以在硬件抽象层上以统一的模式使用无锁技术，这个优点能让应用尽可能地发挥硬件的能力。无锁和无等待技术非常适合创建高效的数据结构，这正是开发社区中大家所急需的东西。此外，有一些用于并发的标准类库的结构非常易于使用，使应用可以更具弹性。不仅是Java使用了很多这样的结构，还有C++11（如果抛开某些细节不谈的话）。C++11的内存模型对于开发人员来说是一次非常巨大的进步。
Thompson：Java（1.5）是第一个拥有详细定义的内存模型的重要语言。有了语言层的内存模型，就可以使开发人员在硬件抽象层上推理并发代码了。这一点至关重要，因为硬件和编译器将激进地重排我们的代码，这存在跨线程可见性问题。你可以使用Java编写很好的无锁算法，它能在低并可预估的延迟上实现非常惊人的吞吐量。Java对锁也有很多的支持。然而，锁竞争时操作系统必须作为一个仲裁者介入，会消耗巨大的性能成本。有没有锁竞争会产生不同的延迟，通常有3个数量级的差异。
Piper：Java从自身的Java语言规范开始就已经支持并发编程了——JLS描述了许多支持并发的Java基本实体和结构。在基层是java.lang.Thread类，它用来创建和管理线程，关键字synchronized用来协调不同线程对共享资源的访问。除此之外，Java还提供了完整的数据结构包（java.util.concurrent），从并发哈希锁到任务调度程序再到不同的锁类型，该包都已经针对并发编程进行了优化。Java内存模型（JMM）是其中最大的一项支持，它是作为JDK5中的一部分并入到了JLS中。它确保了开发人员在处理多线程及其行为时可以有相应的预期。有了它之后开发人员就可以更容易地编写出高性能、线程安全的代码了。在开发Diffusion时，为了实现最佳的性能我们非常依赖于Java内存模型。
