线程正在等待异步回调

Question

我有一个Thread，称之为WorkerThread，它的任务是让一个给定的对象SomeObject定期做一些工作。

SomeObject涉及通过套接字进行一些通信。它需要做的一些工作是在另一个专用于套接字I/O的线程上执行的。打电话给CommsThread。我认为CommsThread是SomeObject的内部实现。

虽然SomeObject正在忙于其工作，但想法是在监视器对象上WorkerThread将wait()。当异步回调从SomeObject发生时，将在回调处理程序中调用notify()，然后Thread A将继续其快乐的方式。

这以前工作 - 但仅仅是因为Object A发生的CommsThread范围内被执行其异步回调，这意味着notify()可以在监控对象上调用，让WorkerThread唤醒并继续。

我一直在重构一些东西，并意识到我认为这是非常糟糕的设计，我的类异步回调线程，而不是实例化的线程，或者这些回调发生在“内部“线程。回调以前发生在CommsThread的情况下。因此，在SomeObject内我已经使用Android Handler在实例化SomeObject的线程上发生异步回调。我相信这是更好的设计。但是这现在导致关于WorkerThread的死锁情况。当然WorkerThread现在无限期地位于wait()。

这使我想到了两个相关的问题：

• 如果我设计一个具有异步回调的类或接口，是公约或只是一般一件好事回调发生无论是在线程创建对象，还是在UI线程上？

• 假设我按照上面的设计我的类，并且异步回调不会在单独的线程上发生，那么WorkerThread应该如何有效等待这种回调？想到的一种解决方法是在创建WorkerThread之前在UI线程上实例化SomeObject，然后将其传递给线程。异步回调将在UI线程的上下文中发生，因此wait()/notify()将起作用。

Answer 1

第三种解决方案是完全放弃使用古老的wait/notify机制并使用真正的并发结构。

我建议你仔细研究你的需求，并考虑使用BlockingQueue进行线程间通信或者使用一些小心的Lock。

如果您可以扩展您的实际需求，而不是假设回调是正确的方法，我相信我们可以提供更多帮助。

目前对回调的态度是，它们几乎总是一种气味。但是，有一些模式看起来很像被认为可接受的回调。