刚刚在我的Corei5 2.8 CPU上测试了Java的延迟，只有单字节发送/接收，2个Java进程刚刚产生，没有分配特定的CPU核心和任务集：

TCP         - 25 microseconds
Named pipes - 15 microseconds

现在显式指定核心掩码，如 taskset 1 java Srv 或 taskset 2 java Cli 。

TCP, same cores:                      30 microseconds
TCP, explicit different cores:        22 microseconds
Named pipes, same core:               4-5 microseconds !!!!
Named pipes, taskset different cores: 7-8 microseconds !!!!

所以

TCP overhead is visible
scheduling overhead (or core caches?) is also the culprit

同时，Thread.sleep(0) (如strace所示，它会导致执行一次sched_yield() Linux内核调用)花费0.3微秒-因此调度到单个内核的命名管道仍然有很多开销

一些共享内存测量:2009年9月14日- Solace Systems今天宣布，使用共享内存传输，其统一消息平台API可以实现低于700纳秒的平均延迟。 http://solacesystems.com/news/fastest-ipc-messaging/

附言-第二天以内存映射文件的形式尝试共享内存，如果繁忙等待是可以接受的，我们可以将传递单个字节的延迟减少到0.3微秒，代码如下：

MappedByteBuffer mem =
  new RandomAccessFile("/tmp/mapped.txt", "rw").getChannel()
  .map(FileChannel.MapMode.READ_WRITE, 0, 1);
while(true){
  while(mem.get(0)!=5) Thread.sleep(0); // waiting for client request
  mem.put(0, (byte)10); // sending the reply
}

注意: Thread.sleep(0)是必需的，这样两个进程就可以看到彼此的变化(我还不知道有其他方法)。如果2个进程与taskset被强制分配到同一个内核，则延迟将变为1.5微秒-这是上下文切换延迟

附言: 0.3微秒是个不错的数字！下面的代码恰好只用了0.1微秒，而只做了一个基本字符串连接：

int j=123456789;
String ret = "my-record-key-" + j  + "-in-db";

P.S-希望这不是太离题，但最后我尝试了用递增静态的易失性整数变量来代替Thread.sleep(0) (JVM在这样做的时候碰巧刷新了CPU缓存)，并获得了-记录！- 72纳秒java- to -java进程通信 ！

然而，当被迫使用相同的CPU核心时，易失性递增的JVM永远不会相互控制，因此恰好会产生10毫秒的延迟- Linux时间段似乎是5ms……因此，只有在有备用内核的情况下才应该使用它-否则，sleep(0)会更安全。