C，Java和C#中典型的多线程范例都强烈推荐使用锁和互斥

C，Java和C#中典型的多线程范例都强烈推荐使用锁和互斥。对于锁来说有个隐藏的开销：它们慢得难以忍受。使用Disruptor(JVM中的无锁的环形缓存[译者注：实际上就是拥有一个序号指向下一个可用元素的数组])，你可以很容易得每秒处理20M以上的事件。根据java商城开发人员以及jsp商城开发人员介绍，在.NET中使用规定的“最佳实践”等任何超过每秒十几次的传输，都被认为是体面又好的性能表现，在这一点上来说你仅仅需要更大/更好/更多的硬件设备。事实上，很多 java商城产品开发人员以及jsp商城开发人员，见过第三方客户端库(Rabbit，Couch，Mongo等等)中锁语句遍布整个代码。即使在我的代码中没有任何的并发，默认的和首选的方法都用了锁。

 

无锁的、事件驱动的方法允许你大幅降低硬件和资金支出。大部分应用程序可以轻易地运行在两台机器上，第二台机器仅仅在冗余和失效备援时是必须的，以防因为硬件相关的问题导致第一台机器不可用的时候起作用。

 

这个问题的另一个方面是调用网络和磁盘子系统的传统方式：同步，阻塞代码。，作为类似于java商城开发人员可以知道如果你需要多个并发的HTTP请求，你需要更多的线程。大多数人不知道的是，为维持线程多出的1-2MB和上下文切换线程的需求，使得CPU内核消耗所有的时间颠簸在上下文切换上而不是做真正的工作。所以现在我们得到了在一个应用程序中数百或数千的线程，占用了RAM，并造成CPU停滞不前。还有个更好的方式。

 

Netty/NIO (JVM)，Erlang，Node，Gevent (Python)和Go都支持使用事件驱动的子系统操作(选择/epoll[译者注：Linux内核中的一种可扩展IO事件处理机制]/kqueue[译者注：FreeBSD的可扩展的事件通知接口])。这就意味着当等待数据包被tx/rx跨网络的时候，CPU可以自由地去做其它，重要的工作。因为JVM的成熟，Netty可以认为是做这项工作最快的，但我喜欢Go用Goroutines操作这个的方式—它简单，优雅，很容易推理，没有像意大利面条一样的回调。