是什么导致线程的执行顺序不可预测？
是什么导致线程的执行顺序不可预测？调度程序是否在某个时刻使用随机数或检查系统资源或查看哪个线程已等待足够长的时间或......？
What makes the execution order of threads unpredictable? Does the scheduler at some point use random numbers or check system resources or see which thread has waited long enough or ...?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
调度程序通常是操作系统的调度程序。它受到许多因素的影响，包括机器上的其他进程正在做什么、硬件正在做什么（中断）等。根据操作系统，我想有时可能会涉及随机数，但我怀疑通常不会。这更多的是多个可变时间间隔可以重叠的不可预测的方式。
The scheduler is, usually, the OS's scheduler. It is influenced by many factors, including what other processes on the machine are doing, what the hardware is doing (interrupts), etc. Depending on the OS, I suppose there may sometimes be random numbers involved, but I suspect generally not. It's more just the unpredictable way that multiple variable time intervals can overlap.
在调度程序中使用随机数会给操作系统的关键部分带来不必要的开销，因此这不太可能是原因，至少在任何主流操作系统中都是如此。
线程通常会一直运行，直到它发出会阻塞的操作系统调用，或者直到发生中断，或者直到其时间片到期（最终只是计时器中断）。即使您可以仔细构建事物，以便两个线程始终按确定的顺序阻塞，您也无法精确控制后两种效果何时发生。应用程序中线程的执行顺序最终将受到应用程序外部事件的影响。
Using random numbers in the scheduler would introduce unnecessary overhead into a critical section of the OS, so it's very unlikely that is the cause, at least in any mainstream OS.
A thread usually runs until it makes an OS call that would block, or until an interrupt occurs, or until its time slice expires (which ultimately is just a timer interrupt). Even if you could carefully construct things so that two threads would always block in a deterministic order, you have no control over precisely when the latter two effects will occur. The order the threads in your application are executed in will eventually be influenced by events outside your application.
其他问题在技术细节上提出了很好的观点，但是：
准确地说，Java 中的线程调度是通过锁、wait/notify/notifyAll、sleep 相当有效地控制的。 方法和其他并发控制。
仅在应用程序执行期间当这些不存在时，不同线程的执行顺序未定义。
主要原因可能是为了Java在不同硬件/操作系统中的可移植性。这也是合乎逻辑的，如果您作为开发人员没有使用上述并发控制来定义应用程序中不同线程的执行顺序，您不关心它，那么它就无关紧要，并且可以是任意方式由 JVM 选择。
Other questions make good points with technical details, but:
To be precise, thread scheduling in Java is fairly efficiently controlled by locks, wait/notify/notifyAll, sleep methods and other concurrency controls.
Only at those times during application execution, when these are not present, the execution order of different threads is left undefined.
Main reason is probably for the sake of ease of portability of Java in different hardware/OS systems. It is also only logical, that if you as a developer do not define order in which different threads in your app should be executed using above mentioned concurrency controls, you do not care about it and it just does not matter then and arbitrary way may be chosen by the JVM.
根据 JVM 的不同，JVM 可能会按原样将线程传输到操作系统，操作系统调度程序将调度该线程，或者 JVM 可能会决定自行调度线程，因此第一个区别（同一情况下在两台不同机器上的不可预测的行为）出现这里，线程是由 JVM 还是 OS 调度的，你不能确定......
而且因素有很多，线程的优先级是一个因素（我们可以设置优先级），资源是另一个因素......不太可能涉及随机数。
Depending upon the JVM, JVM might transfer the thread as it is to OS and OS scheduler will schedule the thread, or JVM may decide to schedule the thread itself, so the very first difference (unpredictable behavior on 2 different machine for same situation) comes here, whether thread is being scheduled by JVM or OS, u cant be really sure.....
Moreover there are number of factors, priority of thread is one factor (we can set the priority), resource is another factor....Its less likely that random numbers are involved.
现代操作系统使用所谓的抢占式多任务。它保证系统上的每个进程都有一段 CPU 时间，并有各种规则规定何时中断每个进程并让下一个进程轮流执行。这就是为什么您的计算机上的每个进程不需要一个 CPU 的原因 :)
它不是随机的，但通常是不可预测的。
Modern operating systems use what's known as Preemtive multitasking. It guarantees each process on the system a slice of CPU time, with various rules for when to interrupt each one and let the next have a turn. This is why you don't need one CPU per process on your machine :)
It's not random, but it is generally unpredictable.