我正在創建一個（半）大數據分析應用程序。我正在使用apache-mahout。我擔心的事實是，用java，我只限於4GB的內存。這種4GB的限制似乎對現代計算機擁有的內存有些浪費。作爲解決方案，我正在考慮使用RMI或某種形式的MapReduce。 （我到目前爲止還沒有任何經驗）JAVA在單臺機器上進行分佈式處理（Ironic，我知道）
首先：多臺JVM在一臺機器上運行並讓它們通話是否合理？如果是的話，我是否正在朝着正確的方向前進？
此外，
在試圖保持這種客觀的問題，我會盡量避免問：「哪個更好」，而是會問：
1）什麼是關鍵的差別（不一定是他們是如何工作內部，但在他們將如何實現我，用戶）
2）有一個或其他的缺點或好處，是否有某些情況下，其中一個或另一個被使用？
3）是否有另一種更具體的我的需求？
在此先感謝
首先，重新4GB的限制，退房Understanding max JVM heap size - 32bit vs 64bit。在32位系統上，4GB是最大的，但在64位系統上，限制要高得多。
這是一個常見的配置，讓多個jvm在同一臺機器上運行和通信。兩個很好的例子是IBM Websphere和Oracle的Weblogic應用程序服務器。他們在一個jvm中運行管理控制檯，並且有三個或更多「工作」jvm受其控制的情況並不少見。
這允許每個JVM獨立運行而不會影響整個系統的反應性。對於最終用戶來說恢復是透明的，因爲一些「工作」的jvm仍然在做他們的事情，而支持團隊正在瘋狂地嘗試修復事情。
您提到了RMI和MapReduce，但是暗示它們在體系結構（通信）中填充同一個插槽。我認爲有必要指出他們填補了不同的空缺--RMI是一種溝通機制，但MapReduce是一種工作負載管理策略。整個MapReduce環境通常依賴於具有（任何）通信機制，但本身不是一個。
對於通信層，您的一些選擇是RMI，Webservices，裸套接字，MQ，共享文件和臭名昭着的「運動鞋網」。在很大程度上，我建議避開RMI，因爲它比較脆弱。只要沒有意外的事情發生，它就可以工作，但是在繁忙的生產環境中，它可能會在意外的時候提出挑戰。這就是說，圍繞RMI建立了許多穩定和高性能的大型系統。
本週世界正在進行跨層通信的方向是SOA，除了彈簧集成或保險絲之外。 SOA將通信機制從等式中抽象出來，允許您隨時（或多或少）將事情掛鉤。
MapReduce（MR）是一種組織批量工作的方法。 MR算法本身基本上是將輸入數據轉化爲一組輸入圖，然後將其減少到產生輸出所需的最小量。MR環境通常由工作負載管理器管理，該管理器接收作業並將作業中的作業分發給其周圍網絡上散播的「工蜂」。通信機制可以由MR庫或其運行的容器來定義。
這是否對您有幫助？
是非常有幫助的！ – sbc
4GB是由於32位字大小。這根本不是'用Java'的問題。 – EJP