两个程序如何在Java中相互通信？

Question

我想减少CPU使用率/ ROM使用率/ RAM使用率 - 通常，我的应用程序使用的所有系统资源 - 谁不使用？ ：）

出于这个原因，我想从应用程序的其余部分拆分首选项窗口， 并让首选项窗口作为独立程序运行。

首选项程序应该写入Property文件（根本不是问题）并向主程序发送“更新信号” - 这意味着它应该调用更新方法（我写的） ）在主类中找到的。

如何从首选项程序调用主程序中的更新方法？

换句话说，这是一种构建首选项窗口的方法，当窗口出现时，它会占用系统资源 吗？

这种方法 - 分离程序并让它们彼此交谈（不知何故） - 加速程序的正确方法吗？

Answer 1

您所描述的内容听起来像Premature Optimisation。如果您正在编写玩具应用程序之外的其他内容，那么确信您的优化实际上解决了一个真正的问题非常重要。你的程序运行缓慢吗？如果是这样，您是通过分析器运行它还是确定性能不佳的地方？

如果您已确定要执行的操作将解决性能问题，建议您查看在不同线程中运行组件concurrently，而不是在不同的进程中运行。然后，您的组件可以避免相互阻塞，您将能够利用多核处理器，而不会承担通过网络套接字等进程间通信的复杂性和性能开销。

Answer 2

您可以使用套接字来回通信。 Here's a tutorial of how to do something similar.。

不幸的是，我认为这不会帮助您最大限度地减少CPU使用率，RAM等...如果有什么可能会增加CPU使用率，RAM使用率等，因为您需要运行两个JVM而不是一个。除非你有一些非常复杂的偏好窗口，否则你可能不需要担心这么多资源。通过添加网络通信，您只需添加更多复杂性而不会增加任何好处。

编辑：

如果您已阅读“Filthy Rich Clients”一书，本书的主要内容之一就是Rich Effects不需要占用大量资源。本书的大部分内容都致力于展示如何在不占用大量资源的情况下为应用添加炫酷效果。在整本书中，他们非常小心地计时，以显示需要很长时间和不需要的东西。这在使您的应用程序减少资源浪费时至关重要。编写你的应用程序，看看感觉很慢，为那些速度慢的特定项目添加计时代码，并加快代码的这些特定部分。检查您的计时代码，看看它是否真的更快。冲洗并重复。否则，您正在进行可能没有任何区别的优化。如果没有为代码计时，即使您在优化后加快了代码，也不知道代码是否需要加速。

其他人提到在单独的线程中加载属性窗口。重要的是要记住，Swing只有one thread called the EDT能够对屏幕进行所有像素绘制。任何导致屏幕上像素改变的代码都应该从EDT调用，因此不应该从单独的线程调用。所以，如果你有一些可能需要一段时间才能运行的东西（可能是一个Web服务调用或一些昂贵的计算），你可以从EDT启动一个单独的线程，当它完成在EDT上运行代码来进行UI更新时。有SwingWorker等库可以让您更轻松。如果要将对话框设置为可见，则不应该在单独的线程上，但如果构建这些数据结构很耗时，则可以在单独的线程中构建数据结构。

使用Swing Worker是肮脏的富客户端中许多有价值的想法之一，可以让UI感觉更具响应性。使用本书中的想法，我已经采用了一些资源相当密集的用户界面，并使用它们，因此用户界面几乎没有使用任何资源。

Answer 3

你可以在主窗口中创建一个ServerSocket并让首选项应用程序与常规Socket连接，使用的协议可能非常简单，但是......我认为你应该真的寻找第二种方法：构建首选项窗口，以便在系统资源出现时占用系统资源？

要做到这一点，您必须构建窗口及其所有资源，直到用户执行首选项操作，保存文件（或将内容传递到主应用程序）并处置所有资源首选项窗口的所有引用都不可访问。垃圾收集器将处理其余的事情。

Answer 4

也许您可以使用某种目录观察器，如this，或者可能实现某种信号量。 老实说，如果您有某种用户可以访问的菜单项，我认为您应该能够解决问题。一旦用户保存首选项，这些将被写入文件。然后，应用程序会在需要时从文件中加载值。 如果您的系统运行缓慢或挂起，您可能会考虑使用线程，或增加线程数。

Answer 5

实际上，正如其他人所解释的那样，您可以使用套接字进行进程间通信。 但是，这根本不会降低您的整体CPU / RAM使用率。 （甚至可能会略微恶化您的资源使用情况）

对于您的情况，您可以在不同的线程而不是其他进程中启动“Perference”窗口。 线程更轻，操作系统可以处理，并且不会为进程间通信带来额外的复杂性。

Answer 6

似乎没有人提到DBUS - Linux系统上的开发人员可以使用它。我想如果您正在尝试制作Windows /跨平台应用程序并不好，但DBUS是一个现成的应用程序通信平台。它有助于解决以下问题：

• 其他人可能已经在使用您正在尝试的端口。对于你的客户端应用程序（我猜的“首选项”窗口）来说，无法知道在该端口上侦听的东西是你的主应用程序，还是恰好在那里的其他东西，所以你必须做某种握手，并实施冲突解决机制
• 对于未来你或任何来维护你的应用程序的人来说，为什么你在这个端口上都不会显而易见。这可能看起来并不重要，但在Socket 5574上进行通信对我来说并不像在org.yourorganisation.someapp频道上进行通信那样简洁。
• 防火墙（我认为有人已经说过了）可能有点过于热心了

此外，值得深入了解DBUS - 它可以与大量其他应用程序进行通信，例如您在最近的Ubuntu发行版或某些即时消息客户端等中找到的小弹出通知内容。< / p>

---

你可以在这里阅读我正在谈论的内容（并且可能在我所说的一些事情上纠正我）：http://www.freedesktop.org/wiki/Software/dbus。看起来他们正在努力让它在Windows上发生，这很不错。