好的，我知道了如何使用 RMI 将单例服务器对象绑定到一个众所周知的名称，以便其他 JVM 可以找到它。
假设我有许多进程，每个进程都运行一个 JVM，每个进程都创建一个支持 FooRemote 接口的对象，我希望通过 RMI 公开它。每个进程都有一个不可预测的生命周期，它对应于某些东西，无论是来自用户输入，还是来自资源的可用性。
如何在不发生命名冲突的情况下绑定它们？使用 JNDI 会有帮助吗？
实际上，我希望做的是拥有一个相似对象池，每个对象都位于不同的 JVM 上（这样做的原因很重要，但超出了这个问题的范围）。我需要一个客户端能够枚举哪些对象可用，并选择一个进行进一步交互。
（我强调单独的 JVM 的原因是，如果它们都在同一个 JVM 中，我可以只使用一个单例管理器来处理组池，并让所有组实例都可以通过管理器访问。但我可以'如果组池由不同 JVM 中的独立实例组成，则不要这样做。）
【问题讨论】：
这不是很有效，但你可以在每个 JVM 中拥有一个单例管理器（工厂），它创建并枚举池中属于该 JVM 的所有对象。
显然，您必须询问他们所有人才能了解全貌。这可能是也可能不是您想要的，具体取决于您的实际用例。虽然它准确无误，但网络流量和延迟会极大地影响性能，因此如果您查询池的次数多于更新池的次数，请不要尝试此方法。
另一种解决方案是将您的客户端变成服务器，并允许服务器在池中对象的状态发生变化时调用回调。此解决方案在网络流量方面可能更有效，但更新程度较低：如果其中一台服务器突然终止，则在您实际尝试使用它们并失败之前，它的对象不会从池中删除。这种行为可以通过 keepalive 调用和超时来跟踪服务器的可用性来改进，但显然是以增加流量和解决方案复杂性为代价的。
【讨论】：
UUID.randomUUID()）并将该上下文中的对象放在随机名称下。要查找所有对象，您可以执行 InitialContext.listBindings()，它将返回上下文下的所有对象。
Registry 来做，它有一个list() 方法。使用您更熟悉的东西可能是更好的选择。
Registry.list() -- 感谢您的参考...如果有层次结构，我认为 JNDI 可能更合适；来自Registry.list() 的平面列表只是给了我一堆名字让我涉水而过。想学JNDI很久了，但是好像找不到好的入门参考。