有没有人知道Observer a.k.a. Listener模式的替代方案? 我对在异步中运行良好的东西很感兴趣 环境。
我面临的问题是我有一个使用它的应用程序 模式很多,这本身并不是一件坏事,但随着听众数量的增加,它会成为一个瓶颈。结合线程原语(互斥体,关键部分 - 当然在我的特定环境中),对性能的打击非常糟糕。
答案 0 :(得分:7)
Message Queue怎么样?
答案 1 :(得分:3)
如果观察者太多,那么被观察的线程没有取得任何进展,那么反转关系可能是明智之举。不是让观察到的线程调用每个观察者,而是让观察者等待一个类似于条件变量或与观察到的线程相关的事件。然后观察者代码可以阻塞,等待条件变量发出信号。然后观察到的线程只能发出条件变量的信号,而不是调用观察者;观察者可以注意到信号,并在自己的时间内处理后果。
答案 2 :(得分:1)
如果您的代码中的听众减少是您的主要目标Jeffrey Richter and his AsyncEnumerator,请查看它。这种技术使异步programmin看起来更像是同步的。
使用这种技术,您的单个方法可以发出一个Asynch调用,并且该方法可以充当事件处理程序,因此整个invokation和事件监听器代码可以作为一个函数进行调用。
答案 3 :(得分:0)
我的两个选择:使用actor模型(如akka框架)或使用executor来限制并行化。 Executor基本上只是一个线程池,它将限制线程数并重用已完成的线程。
答案 4 :(得分:0)
很难说没有更具体的描述,但Mediator pattern是相关的,并且可以在通信对象的数量开始激增时使用。您可以实施一些政策,以便在这些活动中以更有条理的方式协调活动。