刚刚在我的Corei5 2.8GHz上测试了Java的延迟，仅发送/接收了单字节，仅产生了2个Java进程，而没有为任务集分配特定的CPU内核：
TCP - 25 microsecondsNamed pipes - 15 microseconds
现在明确指定核心掩码，例如 taskset 1 java Srv 或 taskset 2 java Cli ：
TCP, same cores:30 microsecondsTCP, explicit different cores: 22 microsecondsNamed pipes, same core: 4-5 microseconds !!!!Named pipes, taskset different cores: 7-8 microseconds !!!!
所以
TCP overhead is visiblescheduling 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/
PS-第二天以内存映射文件的形式尝试了共享内存，如果可以接受繁忙的等待，我们可以将使用以下代码传递单个字节的延迟降低到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个进程可以看到彼此的更改（我还不知道其他方法）。如果2个进程与任务集强制使用同一核心，则延迟变为1.5微秒-
这是上下文切换延迟
PPS-0.3微秒是个好数字！以下代码仅在执行原始字符串连接时，恰好需要0.1微秒：
int j=123456789;String ret = "my-record-key-" + j + "-in-db";
PPPS-希望这不是太多的话题，但是最后我尝试用增加静态volatile
int变量（JVM这样做时刷新CPU缓存）替换Thread.sleep（0）并获得-记录！- 72纳秒的延迟Java到Java进程通信 ！
但是，当强制使用相同的CPU内核时，易失性递增的JVM永远不会相互控制，从而产生恰好10毫秒的延迟-Linux时间间隔似乎是5ms
…因此，只有在有备用内核时才应使用-否则sleep（0）更安全。
