在Java中，何时选择多个进程而不是线程？

出于什么原因，人们会选择几个进程而不是几个线程来实现Java应用程序

我正在重构一个较旧的java应用程序，它目前被划分为几个较小的应用程序（进程），运行在同一台多核机器上，通过套接字相互通信

我个人认为这应该使用线程而不是进程来完成，但有什么论据可以为原始设计辩护呢？

我（和其他人，请参见下面的属性）可以想到几个原因：

历史原因

• 这个设计是从只有绿色线程可用的时候开始的，最初的作者/设计师认为这些线程不适合他

健壮性和容错性

• 您使用的组件不是线程安全的，因此不借助多个进程就无法并行化

• 有些组件有缺陷，您不希望它们影响多个进程。比方说，如果一个组件有内存或资源泄漏，这最终可能会迫使进程重新启动，那么只有使用该组件的进程才会受到影响

• 正确的多线程处理仍然很难做到。取决于您的设计，比多重处理更难。然而，后者也不太容易

• 您可以有一个模型，其中有一个看门狗进程，可以主动监视（并最终重新启动）崩溃的工作进程。这还可能包括进程的挂起/恢复，这对于线程来说是不安全的（感谢您的指出）

操作系统资源限制和管理

• 如果使用单个线程的进程已经使用了所有可用的地址空间（例如，对于Windows 2GB上的32位应用程序），则可能需要在进程之间分配工作

• 限制资源（CPU、内存等）的使用通常只能在每个进程的基础上进行（例如，在Windows上，您可以创建需要单独进程的“作业”对象）

安全注意事项

• 您可以使用不同的帐户（即“用户”）运行不同的进程，从而在它们之间提供更好的隔离

兼容性问题

• 支持多个/不同的Java版本：使用不同的流程，您可以为应用程序部件使用不同的Java版本（如果第三方库需要）

位置透明度

• 您可以（潜在地）将应用程序分布在多台物理机器上，从而进一步提高应用程序的可伸缩性和/或健壮性（有关更多详细信息，请参阅/原始想法）

---

如果你决定使用线程，你将限制你的应用程序在一台机器上运行。此解决方案不可扩展（或在某种程度上可扩展）-始终存在硬件限制

通过套接字进行通信的不同进程可以分布在机器之间，这样您就可以添加几乎无限数量的进程。以进程间通信速度慢为代价，这样可以更好地扩展

---

决定哪种方法更合适本身就是一项非常有趣的任务。而且，一旦你做出决定，也不能保证在未来几年内，当需求发生变化或新的硬件可用时，你的继任者会觉得它很愚蠢。

非常正确。在这种情况下，应用程序应该总是在一台机器上运行，但通常是一个非常有效的考虑点。+ 1覆盖了我可能列出的所有内容。（我要强调的是资源管理和权限分离项目；它们是没有单独的进程就无法做到的，尽管现在有时候你会超越这一点来分离虚拟机。）+1的健壮性是否包括“容错”——就像一些进程启动和观看其他进程一样（postgres做了一些类似的事情）。@Jayan well老实说，当我写它的时候，我没有考虑它，但我肯定会把它（作为一个论点）放在这一点下。@Christian.K。那太好了。这个问题出现在谷歌搜索结果中的几率很高。让我们有一个参考答案！