问题8.InfoQ：下面的问题并不局限于Java，为什么我们需要尽量避免竞争？当我们无法避免竞争时如何能够更好地管理它？ Lawrey：对于追求极致的低延迟来说，这的确是个问题，但对于几微秒级的延迟这就不是个问题了。如果你无法避免这种情况，就要尽量把它的影响降到最低吧。
Montgomery：竞争总会发生的。对它的管理至关重要。处理竞争的最佳方法之一就是架构。“单一写原则”是一种有效的方法。其实，假设有一具单独的写入器，并围绕这一基本原则构建的话，那么就不会有竞争了。使单一的写的工作降到最低，你们会为完成的效果感到惊奇的。 异步行为是一个能够避免竞争的很好的方法。它总是围绕着这样的一个原则：“永远只做有用的工作”。 这通常也会变成单一写原则。我通常喜欢在竞争资源的单一写入器前放一个锁无关队列，用线程执行所有的写操作。线程什么都不做，它只是把写操作推入到队列中，然后这些写操作会在循环中执行。这么做非常有利于批处理。队列方面，一种无等待的方法在此有极大的帮助，从调用者的视角来看，就是在这里执行的异步行为。
Thompson：一旦我们的算法中有了竞争，我们就会有一个基本成正比的瓶颈。竞争点形成队列，利特尔法则（Little's Law）开始起作用了。我们还可以使用阿姆达尔定律（Amdahl's Law）模拟竞争点的时序约束。大多数算法可以被重写以避免来自多线程或执行环境给定的并行加速（通常通过管道）的竞争。如果我们真的必须管理指定数据资源的竞争，那么处理器提供的原子指令往往是比锁更好的解决方案，因为它们是在永远不会涉及内核的用户空间运转的。新一代英特尔处理器（Haswell）扩展了这些指令，使硬件事务型内存支持数据原子性的少量更新。但很遗憾的是，Java很可能需要花上一段时间才能为程序员直接提供这种支持。
Piper：对于低延迟应用来说，锁竞争可能是最大的一个性能障碍了。锁本身并没有多少性能开销，在无竞争情况下Java的同步锁也可以执行地非常好。然而，有竞争时锁的性能就会一落千丈了，不仅仅因为一个线程持有锁使其他线程拿不到同一个锁，还因为更多线程访问这个锁时会给JVM带来昂贵的锁管理成本，这个道理很容易理解。很明显，关键是要避免锁竞争，所以不要同步那些不需要同步的东西（比如，移除那些什么都不保护的锁、缩小锁的范围、降低锁持有的时间、不要混淆锁的职责等等）。另一种常用的技术是消除多线程访问，不要让多个线程去访问一个共享的数据结构；你可以把更新操作当成命令排成队列，这样就变成了单线程处理。这样就把锁竞争简单地归结成了添加在队列中的一个项目了，而它可以通过锁无关技术来实现自我的管理。
问题9.InfoQ：在过去的几年里，你们有没有为了用Java做低延迟开发而做出过改变？ Lawrey：构建一个简单的系统，让它只做你想让它做的事情。尽可能地对它进行端到端的调优。优化和（或）重写那些你测量出瓶颈的地方。
Montgomery：翻天覆地地变化。Ultra Messaging创建于2004年。在那个时候，想把Java用于低延迟可不是一个很明智的选择。除了极少的几个人确实考虑过它。后来人越来越多。我想现在这种局面已经被彻底扭转了。Java不仅是可行的，甚至可能成为低延迟系统的主要选择。Martin Thompson和[Azul Systems'] Gil Tene完成了这项伟大的工程，他们真正地推动了社区对此的态度转变。
Thompson：最近几年的主要变化是持续完善锁无关和缓存友好算法。我喜欢经常参加一些与语言相关的论战，在这些论战中抛出观点来证明在性能方面算法比语言更加重要。不管是什么语言，干净的代码（它展示了机器合应）更容易带来优异的性能。
Piper：Java虚拟机和硬件正在不断地改进，低延迟开发永远都是一场军备竞赛, 为的就是能够保持在目标架构的最佳位置。JVM的Java内存模型和并行数据结构（这依赖于底层硬件的支持）的实现也更加强壮、可靠了，所以像那些锁无关、无等待技术也已经成为主流。硬件现在的发展方向也是在越来越多的执行内核的基础上追求越来越多的并发，所以那些充分发挥这些变化的优势技术，以及那些尽可能降低冲击（比如给避免锁竞争增加更多的权重）的技术正在成为开发环节的要点。 在Diffusion，我们现在已经在标准版的Intel硬件上用标准版的JVM把延迟时间降到了10微秒之内。
问题10.InfoQ：Java是否适用于其他对性能比较敏感的工作？你会把它用于高频交易（HFT）系统吗？能否举个例子？或者说C++仍然是更好的选择？ Lawrey：以上市时间的角度来说（团队的可维护性和支持的综合能力），我认为Java是最好的。C或C++在你要使用Java和FPGA（或GPU）之间的空间一直在不断地缩小。
Montgomery：对于大多数高性能工作来说，使用Java肯定都会是一个明智的选择。对于高频交易（HFT）来说，Java几乎已经有了所需的一切。它有更加广阔的发挥空间，尽管最明显的是有了更多的内联函数。我认为，Java在其他领域可以做得很好。就像低延迟那样，我认为它会让开发人员去乐意尝试也同样做到的。
Thompson：如果有绝对充足的时间，我就能让C（或C++或ASM）的程序性能比Java更好，但现在我没有那么长的时间。通常Java是一种非常快速的交付方式。如果Java有好的并发垃圾回收器、内存层的控制、无符号类型以及一些访问SIMD和并发基元的内联函数，那我可要变成一只非常快乐的兔子喽。
Piper：我把C++看作是一种最优化的选择。从上市时间、可靠性、高质量的角度来看，Java是迄今为止首选的开发环境，所以我常把Java作为第一选择，除非确实有Java无法解决的瓶颈，否则不考虑换其他的语言，这已经成了我的口头禅。
专题讨论小组成员简介 Peter Lawrey是一名对低延迟和高吞吐率系统很感兴趣的Java咨询师。他曾为多家对冲基金、交易公司和投资银行提供过服务。Peter在StackOverflow上的Java方面排在第3名，他的技术博客每月有12万的页面浏览数，他是github上OpenHFT项目最重要的开发人员。OpenHFT项目包括有Chronicle，它每秒最多支持1亿的持久化消息。Peter每月会到性能 Java用户组就不同的低延迟主题做两次免费的讲习会。
 Todd L. Montgomery是29West的Messaging Business Unit（现在已经隶属于Informatica）的副总架构师。Todd作为Informatica的Messaging Business Unit的总架构师负责Ultra Messaging产品系列的设计与实现，该产品系列已经有超过170多个产品在金融服务业内得到了有效地应用。在过去，Todd曾负责过TIBCO和Talarian的架构工作，还负责过West Virginia University的研究和演讲，曾为IETF做出过贡献，完成NASA在各个软件领域的研究工作。在消息平台、可靠的多路广播、网络安全、拥塞控制和软件质保等方面均有较深的资历，他以20年的实战开发经验为我们带来了一种独特的视角。
 Martin Thompson是一名高性能和低延迟专家，有着超过20年的大规模事务处理和大数据领域（包括自动化、博彩、金融、移动和内容管理）的从业经验。他认为机械和应（对硬件的理解，必将有助于软件的创造）是交付优雅的、高性能解决方案的基石。Martin曾是LMAX的联合创始人和首席技术官，直至他离开去专门研究帮助他人使软件达到优越的性能。并发编程框架Disruptor是他创造的机械和应的其中一个实例。
 Dr Andy Piper近期加入到Push Technology的团队中出任首席技术官。Andy之前是Oracle Corporation的技术总监，他在科技前沿有着超过18年的工作经验。在Oracle 的时候，Andy领导Oracle Complex Event Processing (OCEP)的开发，并推进国际化产品策略和创新。在Oracle之前，Andy是BEA Systems的WebLogic Server Core的架构师，负责中间件基础架构技术。
查看英文原文：Virtual Panel: Using Java in Low Latency Environments
转自 http://www.infoq.com/cn/articles/low-latency-vp?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global
| 
