Question

正如我们在java中所知，Thread.join（long millis）意味着“此线程最多等待毫秒毫秒”，但我发现毫秒不是很精确，请看下面的代码：

public class MyThreadTest {
public void invokeTest() {
    long executionTimeLimit = 10;
    Runner rn = new Runner();
    rn.start();
    try {
        long time = System.currentTimeMillis();
        rn.join(executionTimeLimit);
        long l1 = (System.currentTimeMillis() - time);
        System.out.println("execution_time_limit="+executionTimeLimit+" the invoke method time is "+l1+" millisecond");
    } catch (Exception e) {
        //e.printStackTrace();
    }
}
public static void main(String args[]) {
    MyThreadTest mtt = new MyThreadTest();
    mtt.invokeTest();
}
private final class Runner extends Thread {
    public void run()
    {
        //to make the program a bit longer
        int size = 3000;
        String[][] bb = new String[size][size];
        for(int i=0;i<size;i++) 
            for(int j=0;j<size;j++) {
                bb[i][j] = "bbbbbbbbbbb";
        }

    }
}
}

运行多次时输出日志不一样：

“execution_time_limit = 10，调用方法时间为11毫秒” “execution_time_limit = 10，调用方法时间为32毫秒” “execution_time_limit = 10，调用方法时间为34毫秒”

为什么会这样？

Answer 1

等待（n）或睡眠（n）并且没有中断或通知（）时，它等待至少给定的时间。在join（n）中，两者都是可能的。它在线程的通知/结束时提前唤醒，但在此之后可以随时唤醒。

变化是在线程可以唤醒和唤醒时间之间的变化，有很多工具可以监视这些事情。 jHiccup是最好的之一。

线程唤醒时依赖于onload，也取决于OS。这可能导致线程在它们应该被唤醒后很长时间。 MacOS最近的一个问题涉及延迟空闲系统延迟10秒。

这是Java无法控制的，它取决于您的操作系统。

顺便说一句，如果你看一下微秒级别的抖动，你会看到更多彩色变化/抖动/中断过程。

Micro jitter, busy waiting and binding CPUs

Answer 2

当我们处理线程时，我们永远无法确保时间准确性，因为等待，加入，休眠等操作也依赖于系统资源的可用性。

检查Oracle教程http://docs.oracle.com/javase/tutorial/essential/concurrency/join.html

Answer 3

doxygen让你很困惑，因为它说“等待最多毫秒毫秒才能让这个线程死掉”。

join（）函数只允许调用线程“等待一段时间”而不是永远停留。当join（）函数返回时，你调用它的线程可能仍在运行（即它没有“加入”）。在这种情况下，join（）将等待至少毫秒毫秒，然后该线程没有完成并且join（）放弃了。另一方面，如果已经调用了线程join（），那么实际完成时，join（）将等待不到毫秒。

请记住，除非您的JVM在实时操作系统上运行（并且这些线程具有某些优先级），否则可以调度其他进程/线程，从而导致join（）返回延迟更长时间（发生的情况）当你有34毫秒而不是11毫秒时。

Thread.join（毫秒）在java中不准确吗？

3 个答案: