我有一块我不信任的C库（从某种意义上说它可能经常崩溃）。我是从Java进程调用它的。
防止C库中的崩溃带来整个Java应用程序。我认为如果我为这个库生成一个专用的java进程，并让它与Java应用程序接口，那将是最好的。通过套接字编程或RMI。然后，如果发生崩溃，我可以生成另一个并继续处理。
ProcessBuilder还有什么路要走？或者还有其他更简单的方法吗？
谢谢！
答案 0 :(得分：2)
是的，在单独的Java进程中托管本机代码是保护应用程序免受本机代码保护的唯一方法。
至于更简单的方法，只是轻微的实施差异。例如，不从Java应用程序生成代码并将本机代码包装在配置为自动启动的本机包装器中。如果您了解C和套接字，这将简化解决方案。在这种方法中，RMI不是最佳选择。
即使你用Java包装本机代码，我仍然不会选择RMI。我在WAN上遇到了Windows的网络问题。如果可能的话，我会保持沟通简单。如果数据太复杂，可能是基本的序列化库。如果沿着XML路线走，有几种选择。这太过分了，但您也可以嵌入一个http服务器和Web服务层。我不知道你的系统要求，不知道
复苏将带来各种挑战。如果它停止响应，你是否只产生了另一个进程...你愿意做多少次...来自Java的进程管理，还有很多不足之处。
答案 1 :(得分：2)
我不知道更简单的方法。
对于父级和子级之间的交互，我不会使用RMI或套接字 - 我会使用子级的标准输入和输出流，可通过Process对象访问。这是简单，高效和私密的。您可以像使用套接字流一样使用流，尽管不需要考虑身份，地址，身份验证等。您可以自己编写协议，或使用Thrift或Protocol Buffers之类的东西从实体定义构建协议。
答案 2 :(得分：0)
如果性能不是问题，并且如果其他应用程序有可能命中您的“本机”服务，那么我将使用RESTful或其他一些面向Web服务的方式。正如其他人所提到的那样，就崩溃问题重新产生而言，只是把这个过程作为一种服务产生，你应该好好去。
如果您的应用程序是唯一可以访问此本机服务的实体，那么我更倾向于采用RMI方式而不是纯套接字方式。 IMO，RMI自然适合进程间通信（其中进程是Java进程）。 RMI具有“可激活”远程对象的概念，根据您的要求（在崩溃时自动生成），这将是一个自然的选择。此外，如果使用RMI，您的应用程序将通过定义良好的Java接口而不是ad-hoc协议合同（可以使用其他高级解决方案（如Web服务）实现本机进程，但在原始套接字方面真的很痛）
BTW，JFTR，我们正在使用我们的生产应用程序的这个策略，它正在运作得很好，YMMV。 ： - ）