我是一名CS学生,今天在课堂上我们学习了Java中的多线程编程。教授要求学生编写一个简单的程序来演示线程的安排。每个学生都有这段代码:
public class MyThread extends Thread {
private int num;
public MyThread(int num) {
this.num = num;
}
public void run() {
System.out.println("Thread " + num + " is starting.");
}
public static void main( String [] args ) {
for (int i=0; i<100; i++) {
MyThread mt = new MyThread(i);
mt.start();
}
}
}
由于线程不必在连续时间内执行,我们期待这一行
线程
i
正在开始
不严格按0,1,2 ......到99顺序。相反,我们期待像
这样的东西线程0正在开始
线程5正在开始
线程2正在开始
......(九十行后)
线程95正在启动
线程99正在启动
线程98正在启动
(程序完成运行)
有趣的是,虽然Windows用户似乎有所描述的模式,但Mac用户在前10个线程中只有半随机顺序。之后,线程以严格的升序执行,从Thread 10 is starting
到Thread 99 is starting
。
具体来说,Mac输出如下所示:
Thread 0 is starting.
Thread 3 is starting.
Thread 2 is starting.
Thread 1 is starting.
Thread 5 is starting.
Thread 6 is starting.
Thread 4 is starting.
Thread 8 is starting.
Thread 7 is starting.
Thread 9 is starting.
Thread 10 is starting.
Thread 11 is starting.
Thread 12 is starting.
Thread 13 is starting.
Thread 14 is starting.
Thread 15 is starting.
Thread 16 is starting.
Thread 17 is starting.
Thread 18 is starting.
Thread 19 is starting.
Thread 20 is starting.
Thread 21 is starting.
Thread 22 is starting.
Thread 23 is starting.
Thread 24 is starting.
Thread 25 is starting.
Thread 26 is starting.
Thread 27 is starting.
Thread 28 is starting.
Thread 29 is starting.
Thread 30 is starting.
Thread 31 is starting.
Thread 32 is starting.
Thread 33 is starting.
Thread 34 is starting.
Thread 35 is starting.
Thread 36 is starting.
Thread 37 is starting.
Thread 38 is starting.
Thread 39 is starting.
Thread 40 is starting.
Thread 41 is starting.
Thread 42 is starting.
Thread 43 is starting.
Thread 44 is starting.
Thread 45 is starting.
Thread 46 is starting.
Thread 48 is starting.
Thread 49 is starting.
Thread 47 is starting.
Thread 50 is starting.
Thread 51 is starting.
Thread 52 is starting.
Thread 53 is starting.
Thread 54 is starting.
Thread 55 is starting.
Thread 56 is starting.
Thread 57 is starting.
Thread 58 is starting.
Thread 59 is starting.
Thread 60 is starting.
Thread 61 is starting.
Thread 62 is starting.
Thread 63 is starting.
Thread 64 is starting.
Thread 65 is starting.
Thread 66 is starting.
Thread 67 is starting.
Thread 68 is starting.
Thread 69 is starting.
Thread 70 is starting.
Thread 71 is starting.
Thread 72 is starting.
Thread 73 is starting.
Thread 74 is starting.
Thread 75 is starting.
Thread 76 is starting.
Thread 77 is starting.
Thread 78 is starting.
Thread 79 is starting.
Thread 80 is starting.
Thread 81 is starting.
Thread 82 is starting.
Thread 83 is starting.
Thread 84 is starting.
Thread 85 is starting.
Thread 86 is starting.
Thread 87 is starting.
Thread 88 is starting.
Thread 89 is starting.
Thread 90 is starting.
Thread 91 is starting.
Thread 92 is starting.
Thread 93 is starting.
Thread 94 is starting.
Thread 95 is starting.
Thread 96 is starting.
Thread 97 is starting.
Thread 98 is starting.
Thread 99 is starting.
为什么Mac和Windows的行为有所不同?这与使用的调度算法有关吗?如果是这样,算法是什么以及它如何影响其他JVM多线程程序?
答案 0 :(得分:3)
为什么Mac和Windows的行为有所不同?
线程调度基于操作系统的内部。您可以说,Mac OSX和Windows的行为不同,因为它们是不同的操作系统。如果你有不同的硬件,这也会有所不同。
这与使用的调度算法有关吗?
创建一个线程是非常昂贵的,你的任务很短暂,所以你不太可能在这种情况下看到调度的影响。你真的在测试如何创建线程。
如果是,那么算法是什么以及它如何影响其他JVM多线程程序?
您需要查看操作系统的内部结构。
对编写良好的JVM程序的影响应该完全没有。您应该编写对特定操作系统或硬件如何操作的细微差别不敏感的程序。
你也不应该像疯了一样创建线程,这显然效率低下。推测一个写得不好或效率低下的程序如何运作并不是很有用。
我建议从一个问题开始,这个问题对多个线程的性能要好于一个(在你的例子中,一个线程会更有效),看看调度是否会对一系列CPU类型产生影响。
答案 1 :(得分:0)
在Windows上而不是在Mac上订购这些号码的事实与操作系统中的调度程序有关。从开发人员的角度来看,您不应该依赖于序列是真的,即使在Windows上看起来如此。在不同的负载或不同的架构(处理器上的核心/线程数,使用的jvm)下,无法保证序列正确。