Java - 为什么 Thread#join(millis) 无效？

Question

作为一名初级 Java 开发人员，在编写我的第一个多线程代码时，我记得想要使用 Thread.join(millis)循环中，并在每次线程仍然 Activity 时进行记录。我很惊讶地看到join返回时没有告诉我返回的原因，但认为这是某种像我这样的菜鸟无法理解的原生“魔法”。

最近我又看了一遍java.lang.Thread实现，正如我正在阅读的那样 join我再次想知道它的实现 - 因为它只是等待 isAlive条件，使用线程的最后状态作为返回值不是很自然吗，这样客户端代码就不必在外部显式检查它？

    /**
     * Waits at most {@code millis} milliseconds for this thread to
     * die. A timeout of {@code 0} means to wait forever.
     *
     * <p> This implementation uses a loop of {@code this.wait} calls
     * conditioned on {@code this.isAlive}. As a thread terminates the
     * {@code this.notifyAll} method is invoked. It is recommended that
     * applications not use {@code wait}, {@code notify}, or
     * {@code notifyAll} on {@code Thread} instances.
     *
     * @param  millis
     *         the time to wait in milliseconds
     *
     * @throws  IllegalArgumentException
     *          if the value of {@code millis} is negative
     *
     * @throws  InterruptedException
     *          if any thread has interrupted the current thread. The
     *          <i>interrupted status</i> of the current thread is
     *          cleared when this exception is thrown.
     */
    public final synchronized void join(long millis)
    throws InterruptedException {
        long base = System.currentTimeMillis();
        long now = 0;

        if (millis < 0) {
            throw new IllegalArgumentException("timeout value is negative");
        }

        if (millis == 0) {
            while (isAlive()) {
                wait(0);
            }
        } else {
            while (isAlive()) {
                long delay = millis - now;
                if (delay <= 0) {
                    break;
                }
                wait(delay);
                now = System.currentTimeMillis() - base;
            }
        }
    }

我想答案可能是一个简单的“是的，这是可能的，你应该询问原始的 JDK 实现者。”，但我希望得到一个更具教育意义的答案(如果存在的话)。

Answer 1

wouldn't it be natural to use the last state of the thread as the return value

“自然”不是我会用的词，但它是一个合理的选择。有很多合理的选择。

请记住，Java 中的 API 设计有一些非常不自然的地方。例如，java.util.Date 采用/返回 1900 年之后的年数来表示年份，而不表示年份。同样，将一月表示为月份 0，将十二月表示为月份 11。

谁知道由于这些选择而浪费了多少开发人员时间。至少 Thread.join(long) 是 void 的事实不会误导您；您只需要多付出一点努力就能找到您想知道的内容。

API 是 a) 很久以前设计的，b) 需要传送“某些东西”。它们并不完美，因为它们的设计没有经过事后诸葛亮。正确设计 API 确实很难，即使你完成了，也会有人说“我不喜欢它，因为它不做 X”，或者“我更喜欢它做 Y”。

除非 API 实际上被证明有缺陷 - 而 Thread.join(long) 则不然，因为您只需在它返回时调用 Thread.isAlive() - 或者损坏了，没有真正的动力来修复它，特别是当您像 Java 一样坚定地致力于保持向后兼容性时。