5

我有一个我不信任的 C 库（从某种意义上说，它可能经常崩溃）。我从 Java 进程中调用它。

为了防止 C 库崩溃带来整个 Java 应用程序。下来，我认为最好为这个库生成一个专用的 Java 进程，并让它与 Java 应用程序交互。通过套接字编程或 RMI。然后，如果发生崩溃，我可以生成另一个并继续处理。

是ProcessBuilder要走的路吗？或者还有其他更简单的方法吗？

谢谢！

4

3 回答 3

3

是的，在单独的 Java 进程中托管本机代码是保护您的应用程序免受本机代码影响的唯一方法。

至于更简单的方法，只是很小的实现差异。例如，不从 Java 应用程序生成代码并将本机代码包装在配置为自动启动的本机包装器中。如果您了解 C 和套接字，这将简化解决方案。在这种方法中，RMI 不是最佳选择。

即使您将本机代码包装在 Java 中，我仍然不会选择 RMI。我在 WAN 上遇到了 Windows 的网络问题。如果可能的话，我会保持沟通简单。如果数据太复杂，可能是一个基本的序列化库。如果您沿着 XML 路线走，有几个选择。这是矫枉过正，但你也可以嵌入一个 http 服务器和 web 服务层。我不知道你的系统要求，bu

复苏将带来各种挑战。如果它停止响应，您是否只是生成另一个进程...您愿意这样做多少次...来自 Java 的进程管理，还有很多不足之处。

于 2010-12-18T13:55:51.833 回答
2

我不知道更简单的方法。

对于父母和孩子之间的交互，我不会使用 RMI 或套接字——我会使用孩子的标准输入和输出流，可以通过 Process 对象访问。这是简单、高效和私密的。您可以像使用套接字流一样使用流，但无需考虑身份、地址、身份验证等。您可以自己编写协议，或者使用 Thrift 或 Protocol Buffers 之类的东西从实体定义构建协议。

于 2010-12-18T16:42:29.940 回答
0

如果性能不是问题，并且如果其他应用程序有可能访问您的“本机”服务，我会采用 RESTful 或其他某种面向 Web 服务的方式。正如其他人所提到的，就崩溃时的重新生成而言，只需将进程作为服务生成，您应该一切顺利。

如果您的应用程序是唯一会访问此本机服务的实体，那么我更愿意采用 RMI 方式，而不是纯套接字方式。IMO，RMI 非常适合进程间通信（其中进程是 Java 进程）。RMI 具有“可激活”远程对象的概念，根据您的要求（崩溃时自动生成），这将是一个自然的选择。此外，如果使用 RMI，您的应用程序将通过明确定义的 Java 接口而不是 ad-hoc 协议合同与本机进程对话（这可以使用其他高级解决方案如 Web 服务来实现，但对于原始套接字来说真的很痛苦） .

顺便说一句，JFTR，我们正在我们的生产应用程序中使用这种策略，并且运行良好，YMMV。:-)

于 2010-12-18T16:58:40.990 回答