Java RMI 和同步方法

Question

我正在研究《分布式系统》（Tanenbaum 和 Van Steen 所著）一书，他们所说的内容似乎与许多人对 Java RMI 和同步方法的看法相冲突。

我的想法是，即使对该方法的调用来自不同的客户端计算机，在远程对象实现（因此在服务器上运行的实际实现）上使用同步方法也会阻止该方法的并发执行（通过代理调用该方法...又名存根）。

我发现很多人都有相同的观点，例如：Java RMI 和线程同步问题

书中相反说，使用 RMI 时不会阻止同步方法的并发执行。

以下是书中的相关摘录（您只能阅读粗体句子，但如果您愿意，可以阅读上下文）：

从逻辑上讲，阻塞在远程对象中 很简单。假设客户端A调用 远程的同步方法 目的。访问远程 物体看起来总是一模一样 对于本地对象，这将是 需要阻止A 实现的客户端存根 对象的接口以及 A 所拥有的接口 直接访问。同样，另一个 不同机器上的客户端会 本地也需要屏蔽 在其请求可以发送到 服务器。结果就是我们 需要同步不同的客户端 在不同的机器上。正如我们所讨论的 在第 1 章中。 6、分布式 同步可能相当复杂。

另一种方法是 仅允许在服务器上进行阻止。在 原则上，这很好用，但是 当客户端崩溃时就会出现问题 当它的调用正在处理时 由服务器。正如我们在 第一章8、我们可能需要相对 复杂的协议来处理这个问题 情况，并且这可能 显着影响整体 远程方法的性能 调用。

因此，Java RMI的设计者 已选择限制阻止 远程对象仅针对代理 （Wollrath 等人，1996）。这意味着 同一进程中的线程将 可以防止同时发生 访问同一个远程对象，但是 不同进程中的线程将 显然，这些同步 语义很棘手：在语法上 级别（即阅读源代码时） 我们可能会看到一个漂亮、干净的设计。仅有的 当分布式应用程序是 实际执行，未预料到的 可以观察到的行为应该 已经在设计时处理过了。 [...]

我认为论文“Java系统的分布式对象模型”（可用此处）在文本中通过括号之间的注释 Wollrath et all, 1996 引用。然而，我在那篇论文中找到的唯一相关段落是这个：

由于本地和远程的故障模式不同 对象、分布式等待和通知需要 所涉及实体之间的更复杂的协议 （例如，客户端崩溃不会 导致远程对象被永远锁定），并且 这样，不能轻易地安装到本地线程中 Java 中的模型。因此，客户端可以使用通知并等待 远程引用上的方法，但该客户端必须是 意识到此类操作不会涉及实际的远程 对象，仅为远程的本地代理（存根） 对象。

我是否以错误的方式解释了文本，或者实际上声明在使用 RMI 时同步方法“不那么同步”？

Answer 1

您的第一个参考文献所说的是，在单个 VM 实例中，RMI 存根（RMI 服务器的客户端）上的调用将在内部同步。也就是说，存根（或代理，正如文本中所说的那样）本身将阻止多个线程同时调用远程服务器上的方法。然而，它澄清了，两个分别具有远程服务器存根的虚拟机不会被阻止并发调用远程服务器（这是显而易见的，因为它们不能共享锁，并且 RMI 本身不会阻止服务器上的并发）。如果这是不希望的，RMI 服务器将必须实现锁定机制以防止多个并发调用。

第二个参考文献无论如何与第一个参考文献并不矛盾。第二个只是澄清，如果您尝试在存根上进行同步，它只会在本地锁定，并且不会影响远程服务器的并发性。

结合这两篇文章，我们可以看出，在存根上进行同步将阻止同一虚拟机中的多个线程并发访问远程服务器，但不会阻止不同虚拟机中的线程并发访问。

Answer 2

据我所知，对 RMI 服务器的每次调用都会在服务器端创建一个新线程（我的 2000 年日志文件证明了这一点）。如果您在服务器端进行同步，那么您应该是安全的。正如您所发表的，我面临着一些来自文献的古老警告。作为一名实践者，我更喜欢运行该软件一个月左右，并认为它足够稳定，可以用于生产。如果这还不能令人满意，我很抱歉。

Answer 3

您还应该意识到，自 1996 年以来，Java 多线程已经发生了显着变化。作为原始语言设计一部分的 notify() 和 wait() 方法受到了并发专家和 Java 5（2004 年，wiki 说）的强烈批评。 ) 高级并发对象，例如 ReentrantLock 被引入，这是现在的首选方式做事的。

所以你提到的批评可能是正确的，但已经过时了。

Answer 4

你是对的。文字错误。 RMI 存根是线程安全的，可以由单个客户端 JVM 中的多个线程同时调用。我不知道 Wollrath 等人有任何不同的声明或文字，而且我自 1997 年以来一直在关注这个主题。

具体来说：

我的想法是，即使对该方法的调用来自不同的客户端计算机（调用该方法），在远程对象实现上使用同步方法（因此在服务器上运行的实际实现）也会阻止该方法的并发执行通过代理...又名存根）。

你是对的。

书中提到，使用 RMI 时不会阻止同步方法的并发执行。

这本书不仅是错误的，而且还指出了不可能。 RMI 究竟如何阻止同步工作？

从逻辑上讲，阻塞远程对象很简单。假设客户端A调用远程对象的同步方法。

然后，通过 Java 的正常操作，在服务器上发生阻塞。

为了使对远程对象的访问看起来始终与对本地对象的访问完全相同，有必要在实现对象接口且 A 可以直接访问的客户端存根中阻止 A。

垃圾。事实上，远程方法实现是同步的，它完成了所有必要的工作。

同样，不同计算机上的另一个客户端也需要在其请求发送到服务器之前在本地被阻止。

这又是垃圾。

结果是我们需要同步不同机器上的不同客户端。

又是垃圾。

另一种方法是仅允许在服务器上进行阻止。

'允许'？这意味着什么？ synchronized 方法是synchronized。您不能禁止它。

原则上，这工作得很好，但是当客户端在服务器处理其调用时崩溃时，就会出现问题。

又是垃圾。不会出现这样的问题。服务器通过读取超时或写入异常甚至成功完成远程方法从这种情况中恢复。在所有三种情况下，方法都会退出，同步锁都会被释放，并且生命会继续。

正如我们在第 1 章中讨论的那样。 8、我们可能需要相对复杂的协议来处理这种情况，这可能会显着影响远程方法调用的整体性能。

废话。

因此，Java RMI 的设计者选择将远程对象的阻塞仅限于代理（Wollrath 等人，1996）。

除了您引用的摘录之外，我不知道这还可以指什么，而且我已经多次阅读该论文。如果作者想依赖这篇论文，他们应该提供引文以及对章节和诗节的正确引用。

无论如何，RMI 的设计者并没有做出这样的选择。没有这样的选择。 synchronized 是 synchronized，无论 RMI 设计者是否希望，类似地 notify() 和 wait() > 是最终决定。他们不能自由地做出任何选择。您提供的引用不是“选择”：它只是关于 Java 语义的声明。

我是否以错误的方式解释了文本，或者实际上声明使用 RMI 时同步方法“不太同步”？

我认为你的理解是正确的，但它是完全错误的，而且不仅是错误的，而且明显是错误的。怎么可能是对的呢？
Java RMI 不会（而且确实不能）以任何方式改变、删除或扩展同步 的语义。