RMI有多快？
我已经看到了这样一个问题： 两个独立的Java桌面应用程序之间的通信 （答案：JGroups），我正在考虑用JavaGroups或直接RMI实现某些东西，但速度至关重要。 我不会发送大量数据（MIDI消息的内容，每个3个字节，不过每三毫秒说两个消息），这将全部在同一台机器上。 认为同一台物理机上的RMI / JGroups会慢吗？
（我的想法是我承受不起超过1毫秒的延迟，因为我已经有了一些，但我不确定如何在这种情况下最好地谈论速度。）
我想我的真正问题是： Java中的interspp通信是否有任何选项可以通过比TCP / IP更快的速度？ 我的意思是已经用Java实现的东西，而不是我需要实现的JNI可能性:)
我知道，不要尽早优化所有这些，但也比抱歉更安全。
Java中的interspp通信有没有比TCP / IP更快的选择？
不显着…… AFAIK。
但我认为你正在以错误的方式思考这个问题。 假设您正在移动小消息，主要的性能杀手将是进行调用的开销，而不是移动字节的速度。 这些开销包括进行系统调用所花费的时间，在客户端和服务器端切换进程上下文，在内核中处理消息包头以及路由数据包等。 任何类似RPC的同步交互都需要拨打电话等待回复; 即应用程序 – >服务器 – >往返时间。
获得更高吞吐量的方法是关注以下内容：
-
减少应用程序所需的RPC数量; 例如，将它们组合成更粗粒度的，和
-
研究将同步交互转变为异步交互的方法; 例如，使用基于消息而不是基于RPC的技术。
如果速度至关重要，则应该在同一个线程中进行调用。 使用网络，你不会得到这么快。
但是，假设速度不是那么重要，您可以在大约500微秒内执行Java RMI调用，并使用自定义编码RPC，您可以在大约24微秒内通过环回进行调用。 即使在同一JVM中的线程之间传递数据也需要8微秒。
您需要决定允许拨打网络电话的时间。 您还需要确定开始呼叫的时间是否至关重要或返回结果的时间。 （后者通常会增加一倍的开销）
注意：我在这里说微秒，而不是毫秒。 我会忽略任何需要几毫秒的选项。
这个基准测试大约有两年了，但它表明唯一比RMI更流行的Java远程处理解决方案是Hessian 2 （我相信它仍处于测试阶段）。
但是，如果您的消息只是单个数字字节，那么使用任何远程处理解决方案似乎都是过度的，特别是如果进程位于同一台机器上。 如果可能的话，我建议将它们合并到一个进程中。 您还可以考虑使用普通的旧Java套接字 。
认为同一台物理机上的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毫秒内完成。