观察者：使用模式（主题和观察者）或线程间通信（等待和通知）实现答案

【问题标题】：Observer: Implement with pattern (subject & observer) or inter-thread communication (wait & notify)观察者：使用模式（主题和观察者）或线程间通信（等待和通知）实现
【发布时间】：2011-09-14 15:29:43
【问题描述】：

我通常使用Observer 模式，但我的同事已经使用线程互通实现了一个观察者（使用wait 和notify/notifyAll）。

我应该使用模式实现我的观察者还是使用等待和通知实现线程间通信？是否有充分的理由避免使用一种方法而始终使用另一种方法？

我总是选择第一个，使用该模式，不符合惯例，因为它看起来更具表现力（涉及的标识符是表达和理解交流内容和方式的好方法）。

编辑：

我在 Swing GUI 中使用该模式，他在 Android 应用程序中使用线程间解决方案。

在他的解决方案中，一个线程生成数据，然后调用notify，以唤醒另一个绘制生成数据的线程，并在每次绘制后调用wait。

他对wait/notify 解决方案的论点是它创建的线程更少，甚至对notify 的多次并发调用也只会导致一个绘制事件，而基于观察者的解决方案会在每次调用时调用一次重绘.他说这只是另一种有效的方法，但并未声称出于性能原因他已经这样做了。

我的论点是我会在 OO 设计级别上表达对象之间的通信，而不是使用使通信几乎不可见的特定于语言的功能。此外，低级线程通信很难掌握，其他读者可能难以理解，而应该在更高级别上实现，即。 e.使用CyclicBarrier。对于一种或另一种解决方案，我没有任何合理的论据，但我想知道对于一种或另一种方法是否有任何合理的论据（即“如果你使用这个，这可能会发生方法，而在另一种方法中是不可能的。”）。

【问题讨论】：

有无数种方法可以处理这种模式，但您需要提供更多信息才能准确确定最佳执行策略。具体来说，您要完成的工作是关键。这是一个胖客户端应用程序吗？一个网络应用程序？您是否使用 JMS 等。答案可能会因您的输入而异。
我在原始帖子中添加了一些信息（太长了，无法作为评论发布）。
使用setChanged 标志可以避免多次调用repaint；这就是它的用途。或者，您的 update 方法可以在这里提供帮助，方法是查看它们从 Observables 收到的消息。其中任何一个都可能比线程同步更容易调试。
听起来他的解决方案可以使用 BlockingQueue 轻松完成，并且完全跳过低级线程的东西。如果您在线程环境中并且只希望一个消费者对多个生产者，这是一种有效的方法。这是观察者/可观察者的特定用例。如果只有一个线程正在生产，一个正在消费并且消费者阻止生产者，我不确定在列出的等待/通知案例中会获得什么。
他确实有几个制作人，忘了说。

标签： java

【解决方案1】：

你在比较苹果和橘子。等待/通知机制用于线程同步，虽然您的同事可能在 Observer/Observable 实现中使用过它，但它本身并不是模式实现。它只是意味着它是一个多线程实现。

这种模式有很多实现，它们通常是根据您工作的环境量身定制的。大多数 UI 框架/工具包中都内置了事件机制。用于分布式环境的 JMS，...

我发现 JDK 提供的通用 Observer/Observable 类没有多大用处，而且根据经验，我也没有发现很多其他开发人员使用它们。大多数人将在适当的情况下使用提供的机制，或者在需要时推出自己的特定且最终更有用的实现。

由于我最近在 OSGi 环境中完成了大部分编码，因此我偏爱一种称为 whiteboard pattern 的观察者/可观察者的变体。这对您来说可能可行，也可能不可行，具体取决于您的环境。

【讨论】：

我知道它们是不同的，我只是想知道一个人是否比另一个人更受青睐 - 我会采用这种模式，但没有一个好点，为什么。感谢您向我指出白板图案！

【解决方案2】：

在 99.99% 的情况下，您应该避免或更确切地说避免线程间通信。如果确实需要多线程解决方案，则应该使用更高级别的并发机制，例如 ExecutorService 或好的并发库，例如 jetlang：http://code.google.com/p/jetlang/。

【讨论】：

我正在寻找合理的论据来解释为什么我应该避免它，以及为什么它不适合他的具体解决方案。

【解决方案3】：

很难。在不明确编写多线程应用程序时，我通常会使用 Observer / Observable。但是，这种情况下的约定可能是您使用他的设计。或许看看你能不能把它抽象出来，以便在以后有必要的时候用观察者模式替换它？

但是，我发现这两篇文章似乎表明 Java 中的 Observer/Observable 模式并不理想，应该避免。

An inside view of Observer 和 The event generator idiom

【讨论】：

没有完全回答我的问题，但有趣的文章，谢谢。