在线程中加入（长毫秒）而不是睡眠（长毫秒）有什么用[重复]答案

【问题标题】：What is the use of join(long milliseconds) over sleep(long milliseconds) in Thread [duplicate]在线程中加入（长毫秒）而不是睡眠（长毫秒）有什么用[重复]
【发布时间】：2018-02-17 06:37:50
【问题描述】：

我想知道 join(long millis) 对 sleep(long millis) 的使用，因为它们都会暂停该线程一段时间。

所以如果被另一个线程加入的线程在这段时间之后仍然会被调用，即使加入的线程完成与否。那为什么要用milli的join而不是milli的sleep呢。

虽然，我收到了这个问题的答案，只是想清楚地解释这个问题。

谢谢，

【问题讨论】：

请阅读文档，这两种方法做的事情完全不同。
The difference is clearly explained in the Javadoc。如果您感到困惑，请edit您的问题描述您的困惑。
是的，先生，我明白你的意思，但正如文档中所述。两者都在一段时间内停止线程。我知道在加入的情况下，它会等待加入的线程在这段时间内死亡。但是通过使用 sleep 我们也可以让一个线程等待那个特定的时间。那么，如果我们不依赖该线程来完成其工作，那么为什么要使用毫秒连接。
因为 if 另一个线程完成得更快，那么您就不必等待一些额外的时间，在此期间您应该继续工作。
我认为您问错了问题：IMO，您应该将 t.join() 和 t.join(n) 视为 one 函数，可以在有或没有可选超时参数的情况下调用.然后问，“为什么有人想要带有超时参数的版本？”

标签： java multithreading

【解决方案1】：

假设您有一个线程：使用sleep(timeout) - 它总是会等待timeout 秒才能继续。

假设你有两个线程：

选项 1：线程 1 应该等待，与线程 2 无关 - 使用 sleep(timeout) - 在继续之前，它将始终等待 timeout 秒。
选项 2：Thread1 确实与 Thread2 有关，因此（并且仅因此）在 Thread2 上调用 join(timeout)。
- 选项 2.1：线程 2 在超时之前完成。知道 Thread2 已完成，Thread1 可以立即继续其处理。它不会等待timeout 秒。
- 选项 2.2：线程 2 在超时后结束。 Thread1 现在知道 Thread2 仍在做一些工作，并且可能会向用户显示“该过程需要更长的时间”，甚至可以取消其他任务。此时它将等待timeout 秒。这类似于睡眠，但您事先不知道会发生 2.1 还是 2.2，因此 sleep 不是一个合适的选择。

【讨论】：