我已经看到了这个问题：Communication between two separate Java desktop applications（回答：JGroups），我正在考虑用JavaGroups或直接RMI实现某些东西，但速度至关重要。我不会发送大量数据（MIDI消息的内容，每个3个字节，不过每三毫秒说两个消息），这将全部在同一台机器上。 认为同一台物理机上的RMI / JGroups会变慢是不是很糟糕？
（我的想法是我承受不起超过1毫秒的延迟，因为我已经有了一些，但我不确定如何在这种情况下最好地谈论速度。）
我想我真正的问题是： Java中的interspp通信是否有任何选项可以比TCP / IP更快？我的意思是已经用Java实现的东西，而不是JNI的可能性。 d需要实施:)）
我知道，不要尽早优化所有这些，但也比抱歉更安全。
答案 0 :(得分：5)
Java中的interspp通信有没有比TCP / IP更快的选择？
不显着...... AFAIK。
但我认为你正在以错误的方式思考这个问题。假设您正在移动小消息，主要的性能杀手将是进行调用的开销，而不是移动字节的速度。这些开销包括进行系统调用所需的时间，在客户端和服务器端切换进程上下文，在内核中处理消息包头以及路由数据包等。任何类似RPC的同步交互都需要拨打电话等待回复;即应用程序 - ＆gt;服务器 - ＆gt;往返时间。
获得更高吞吐量的方法是关注以下内容：
减少应用程序所需的RPC数量;例如通过将它们组合成更粗粒度，
研究将同步交互转变为异步交互的方法;例如使用基于消息而不是基于RPC的技术。
答案 1 :(得分：2)
如果速度至关重要，则应在同一个线程中进行调用。使用网络，你不会像这样快。
但是，假设速度不是很重要，您可以在大约500微秒内执行Java RMI调用，并使用自定义编码RPC，您可以在大约24微秒内通过环回进行调用。即使在同一JVM中的线程之间传递数据也需要8微秒。
您需要决定允许拨打网络电话的时间。您还需要确定启动呼叫的时间是否至关重要或返回结果的时间。 （后者往往是开销的两倍）
注意：我在这里说微秒，而不是毫秒。我会忽略任何需要几毫秒的选项。
答案 2 :(得分：1)
This benchmark大约两年了，但它表明唯一比RMI更流行的Java远程处理解决方案是Hessian 2（我相信它仍处于测试阶段）。
但是，如果您的消息只是单个数字字节，那么使用任何远程处理解决方案似乎都有点过分，特别是如果进程位于同一台机器上。如果可能的话，我建议将它们合并到一个进程中。您也可以考虑使用plain old Java sockets。
答案 3 :(得分：0)
以为同一台物理计算机上的RMI / JGroups会变慢是不是很愚蠢？
如果您的计算机不错，则可能是:)如果您运行的计算机上有大量进程占用CPU等，则情况可能会有所不同。一如既往，找出您是否会遇到与我相同的事物的最佳方法就是进行测试。
以下是在同一JVM中使用nanoTime花费的时间（以毫秒为单位） 使用rmi发送字符串“ 123”，并在服务器上将其与“ abc”连接以获取 “ 123abc”并返回。
冷JVM：大约0.25毫秒的延迟
0.250344
0.262695
0.241540
0.282461
0.301057
0.307938
0.282102
温暖的JVM：大约0.07毫秒的延迟。
0.87916
0.72474
0.73399
0.64692
0.62488
0.59958
0.59814
0.66389
因此，如果RMI服务器和客户端在本地运行，那么您会在1毫秒之内。