Java和C / C ++之间最快的（低延迟）进程间通信方法

Question

我有一个Java应用程序，通过TCP套接字连接到用C / C ++开发的“服务器”。

应用程序和服务器都在同一台机器上运行，这是一个Solaris机器（但我们正在考虑最终迁移到Linux）。交换的数据类型是简单的消息（登录，登录ACK，然后客户端要求某些内容，服务器答复）。每个消息大约300字节长。

当前，我们正在使用套接字，并且一切都很好，但是我正在寻找使用IPC方法交换数据（更快的延迟）的更快方法。

我一直在研究网络，并提出了以下技术的参考：

• 共享内存
• 管道
• s列
• 以及所谓的DMA（直接内存访问）

但是我找不到对它们各自性能的适当分析，也找不到如何在JAVA和C / C ++中实现它们（以便它们可以相互通信）的方法，但也许我可以想象如何做。

在这种情况下，任何人都可以评论每种方法的性能和可行性吗？任何指向有用的实现信息的指针/链接？

编辑/更新

在我到达这里的评论和答案之后，我找到了有关Unix Domain
Sockets的信息，该信息似乎是通过管道构建的，将为我节省整个TCP堆栈。它是特定于平台的，因此我计划使用JNI或juds或junixsocket对其进行测试。

下一个可能的步骤是直接实现管道，然后实现共享内存，尽管我已经被警告过额外的复杂性…

谢谢你的帮助

Answer 1

刚刚在我的Corei5 2.8GHz上测试了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/

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）更安全。