最近，高级开发人员告诉我不要使用 Thread.join() 来等待另一个线程完成。我还在 SO 上看到了几个这样的问题，要求候补人员加入。
在我的研究中，我没有发现 join() 有什么问题。事实上，它被广泛使用。
所以我想知道为什么不使用join()？它有什么问题？它是否促进了糟糕的编程或架构？
user2376082
问问题
3936 次
4 回答
33
没什么不好的join()。它和它一样好。
但是，这就是为什么您不应该将应用程序构建为依赖连接的原因。在 Java 中，运行任务的主要抽象不再是线程。它是Executor。也就是说，您将并发任务包装为Callable并简单地将其提交给 anExecutor而无需担心执行细节。这就是Executors 的工作方式。你submit或executeaCallable或Runnable分别并没有必要指定Thread。
所以我想知道为什么不使用join()？
那么这就是你的理由：由于你没有在 Executor 世界中创建或操作线程，所以使用join. 几乎每一个join都可以用其他东西代替（Future.get, CountDownLatch,Locks等）。
注意：我并不是说你在使用 Executors 时不需要操作 Threads。在某些情况下，最好创建自己的 Thread 子类，然后让 Executor 通过ThreadFactory.
于 2013-05-13T01:42:01.360 回答
11
通常使用 Thread.join 没有什么问题，但是您需要非常小心并知道线程来自何处。如果它来自线程池- 那么你确实有麻烦了，因为这样的线程一直在运行，直到池终止并在多个工作人员之间共享。
于 2013-05-13T01:42:17.843 回答
2
Java 7 中引入了 Fork/Join 框架。考虑使用它而不是 Thread.join( ) 。一般来说，您应该尽可能使用包 java.util.concurrent.* 中的类，尽量减少对同步块、等待/通知和加入等原始同步技术的使用。java.util.concurrent 提供了更多的灵活性。
于 2013-05-13T06:30:38.653 回答
1
IMO 加入没有任何问题。您只需要注意确保您正在等待的线程在所有情况下都会终止。因为如果没有，那么执行可能会永远停止。因此，如果您使用 join 使主线程等待某个线程并且该线程没有终止，则可能会导致整个应用程序冻结。
于 2013-05-13T01:38:18.223 回答