我有一个线程，叫做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()状态。
这带我来到两个相关问题：
1.如果我正在设计具有异步回调的类或接口，那么回调是否应该惯例或通常是好事发生在创建对象的线程上或UI线程上？
2.假设我按照上述方式设计我的类，并且异步回调不会在单独的线程上发生，那么WorkerThread如何有效地等待这样的回调？ 一个解决方法是在创建WorkerThread之前在UI线程上实例化SomeObject，然后将其传递到线程中。 异步回调将在UI线程的上下文中发生，因此wait()/notify()将起作用。
当SomeObject忙于工作时，想法是WorkerThread会在监视器对象上等待(wait())。 当来自SomeObject的异步回调发生时，在回调处理程序中调用notify()，然后Thread A将继续前进。
以前这样可以工作——但只是因为Object A碰巧在CommsThread的上下文中执行其异步回调，这意味着可以在监视器对象上调用notify()，从而允许WorkerThread唤醒并继续执行。
我已经对事情进行了重构，并意识到我认为我的类异步地回调不应该在除了它们被实例化的线程之外的其他线程上调用，或者这些回调发生在“内部”线程上是相当糟糕的设计。 回调以前是在CommsThread的上下文中发生的。因此，在SomeObject中，我使用了Android Handler使异步回调在实例化SomeObject的线程上发生。我相信这是更好的设计。 但是，这现在会导致关于WorkerThread的死锁情况。 当然，WorkerThread现在无限期地处于wait()状态。
这带我来到两个相关问题：
1.如果我正在设计具有异步回调的类或接口，那么回调是否应该惯例或通常是好事发生在创建对象的线程上或UI线程上？
2.假设我按照上述方式设计我的类，并且异步回调不会在单独的线程上发生，那么WorkerThread如何有效地等待这样的回调？ 一个解决方法是在创建WorkerThread之前在UI线程上实例化SomeObject，然后将其传递到线程中。 异步回调将在UI线程的上下文中发生，因此wait()/notify()将起作用。