如何让Java以光的速度跨线程通信？

SPSC队列是一个Single Producer/Single Consumer 队列(单生产者/单消费者)，而MPSC是一个Multi Producer/Single Consumer队列。

Dispatcher线程从Actor线程接受到消息，然后发送到相应的SPSC中。

Actor线程从接受的消息中使用数据，调用相应的actor类的方法，Actor实例都是发送消息给MPSC队列，然后再从Actor线程那里得到消息。

下面是ping-pong案例：



作者找到一个SPSC单生产者和单消费者的无锁队列，http://www.infoq.com/presentations/Lock-Free-Algorithms

无锁队列提供比锁队列更好的性能。锁队列中在当一个线程获得锁，其他线程将被阻塞，直到该锁被释放的。在无锁算法的情况下，生产者线程可以产生消息，但不阻止其他生产者线程，以及其他消费者，而从队列中读取的消费者不会被阻塞。

这个无锁队列据测试结果是超过每秒100M ops，是JDK的并发队列实现的10倍。

但是作者使用这个无锁队列提到SPSC 以后，并没有产生明显性能提升，他立即意识到这个框架的性能瓶颈不是在SPSC，而是在多个生产者/单个消费者(MPSC)那里。

多个生产者如果使用SPSC会覆盖彼此的值，因为SPSC并没有一个对生产者的控制机制，即使最快的SPSC也不适合。

对于MPSC作者找到了LMAX的disruptor，一个通过Ringbuffer实现的高性能线程间通信库包。



使用Disruptor很容易实现非常低延迟，高吞吐量的线程间消息通信。它还提供了用例对生产者和消费者的不同组合。多个线程可以从环形缓冲区中读取而不会阻塞对方：



多生产者和多消费者：


三个生产者/一个消费者测试结果显示，Disruptor都是两倍于LinkedBlockingQueue 。

但是使用Disruptor后的这个框架性能还是没有达到预期，作者从上下班的地铁中得到灵感，在某个站点同一车厢出来的人是生产者，进去的是消费者。

建立一个Railway类，使用AtomicLong来跟踪地铁在站与站之间的传递，下面是一个single-train railway:



使用一列火车实现单个生产者单个消费者：

经过测试吞吐量是单列火车的1.4被，延迟从192.6纳秒降低到133.5纳秒。

但是线程间传输消息延迟是因为火车容量2048导致2178.4纳秒，通过增加火车降低这个延迟，如下图：


当在两个线程之间使用32,768 列火车传递一个long值，其延迟降低到13.9纳秒。到此吞吐量和延迟达到了一个平衡。

这只是SPSC的实现，纳秒多个生产者如何实现呢？答案是加入更多站点。



每个线程等待下一列火车，然后加载卸装消息，再把火车发到下一个站，而生产者线程放入消息到火车而消费者是从其中获得，火车总是从一个站到另外一个站循环不断移动。

测试了SPMC单个生产者和多个消费者，使用8个站点，一个属于生产者，剩余7个是消费者。

火车数量是256 火车容量是32时，测试结果是：吞吐量和延迟：
ops/sec = 116,604,397
latency nanos = 274.4
而火车数量是32而火车容量是256时：
ops/sec = 432,055,469
latency nanos = 592.5

后者相对是一个好的结果，延迟虽然提高，但是吞吐量提高的倍数要高得多。