我看到了這個問題：Communication between two separate Java desktop applications（回答：JGroups），我正在考慮用JavaGroups或直接RMI實現某些東西，但速度是至關重要的。我並沒有發送大量數據（MIDI消息的內容，因此每個3個字節，每三毫秒只能說兩條消息），這將全部在同一臺計算機上。 認爲在同一臺物理機器上的RMI/JGroup會很慢嗎？RMI有多快？
（我的想法是，我不能超過1毫秒的延遲，因爲我已經得到了一些，但我不知道如何左右的速度最好的談話在這方面。）
我想我真正的問題是：是否有任何選項可以通過Java比較比TCP/IP更快的方式進行交互通信？我的意思是已經在Java中實現的東西，而不是JNI的可能性，我需要實現:)
我知道，不要儘早優化和所有，但也比對不起更安全。
是否有任何選項用於Java中的互操作性通信，比TCP/IP要快一些？
不顯着... AFAIK。
但我認爲你正在考慮這個錯誤的方式。假設你正在移動小消息，主要的性能殺手將是撥打電話的開銷，而不是字節移動的速度。這些開銷包括諸如進行系統調用所需的時間，在客戶端和服務器端切換進程上下文，處理內核中的消息包頭以及路由數據包等。任何類似RPC的交互都需要等待回覆;即應用程序 - >服務器 - >往返時間。
獲得更大的吞吐量的方式是集中在以下幾點：
減少應用程序需要的RPC的數量;例如通過將它們組合成更粗粒度，並且尋找將同步交互轉變爲異步交互的方式;例如使用基於消息的而不是基於RPC的技術。
This benchmark大約兩歲，但它表明唯一受歡迎的Java遠程解決方案比RMI更快是Hessian 2（它仍處於測試階段，我相信）。
但是，如果您的郵件只有單個數字字節，使用任何遠程處理解決方案似乎是矯枉過正，特別是如果進程在同一臺計算機上。如果可能的話，我建議將它們整合到一個單獨的過程中。你也可以考慮只使用plain old Java sockets。
絕對沒錯，普通舊式Java套接字可能會這樣做。儘管如此，我還是擔心下面的堆棧（TCP/IP？）......它爲一個應用程序添加了多少延遲，讓它有兩個應用程序可以通過簡單的舊Java套接字進行通信？ – 2010-01-15 02:24:00
對不起，沒有提到：如果可以的話，我會將它們合併成一個過程。但我不能，因爲一個將是一個獨立的應用程序，另一個是VST插件。 – 2010-01-15 02:25:06
我真的不能說使用套接字的延遲會增加多少。這並不會太多，但當我們談論這麼小的時間單位時，我無法確切地說出預期會有多少。 使用某種共享內存模型進行通信應該會更快，但我不確定如何在JNI之外執行此操作。這並不是說那裏有東西可以工作。 但是，如果您的應用程序易受延遲的影響，它似乎是一個設計缺陷。您可能需要考慮使用java.nio類的一些緩衝功能來幫助緩解這種情況。 – 2010-01-15 03:09:35
如果速度是關鍵，那麼應該在同一個線程中進行調用。使用網絡的速度不會這麼快。
但是，假設速度並不那麼重要，您可以在約500微秒內執行Java RMI調用，並使用自定義編碼的RPC，您可以在大約24微秒內通過環回進行調用。即使在同一個JVM中的線程之間傳遞數據也可能需要8微秒。
您需要決定您願意允許進行網絡通話的時間。您還需要確定開始呼叫的時間是否至關重要，或者返回結果的時間。 （通常後者的開銷是雙倍的）
注意：我在這裏說的是微秒，而不是毫秒。我會忽略任何需要幾毫秒才能達到目的的選項。
哇，不知道我當時錯過了這個答案。所以RMI基本上快速發展。 – 2011-12-10 17:40:12
@Yar它的所有親戚。 0.5毫秒可能足夠快，在這種情況下，RMI很可能是最好的選擇。通過調整系統和JVM，您可以使套接字通過環回接口和共享內存將往返延遲縮短至6微秒，您可以將其降至200納秒。 – 2011-12-10 20:07:47
的確，它們都是相對的，但只是在用戶與音樂程序進行交互的系統上添加這種延遲，完全沒問題，假設它只是旋鈕和按鈕。即使是鼓，只要延遲相對一致，我認爲25微秒是不明顯的。 – 2011-12-11 20:12:58
謝謝斯蒂芬，我認爲這是正確的，並且是一個很好的答案。我實際上不會說雙向的：一個程序會使用另一個程序來進入一個應用程序上下文（VST主機，對於編制的術語感到抱歉），它本身不運行。此外，雖然在我的特定情況下只有一小部分聚合是可能的（他們進來時需要消息），但我認爲你的聚合和異步同步是正確的。 – 2010-01-15 13:08:19