Java 协作调度与抢占式调度？

在《Java核心：第1卷基础知识》->《多线程》一章中

作者写道：

“所有现代桌面和服务器操作系统都使用抢占式 但是，手机等小型设备可能会使用 合作调度……”

我知道这两种调度类型的定义/工作原理，但想了解为什么在较小的设备中，协作调度优于抢占式调度

---

有人能解释一下原因吗

与抢占相比，协作调度的最大好处是协作调度不使用“上下文切换”。上下文切换涉及存储和恢复应用程序（或线程）的状态。这是昂贵的

目前，小型设备之所以能够摆脱协作调度，是因为小型设备上只有一个用户。协作调度的问题是一个应用程序可能占用CPU。在抢占式调度中，每个应用程序最终都有机会使用CPU几个周期。对于涉及多个恶魔或用户的较大系统，协作调度可能会导致问题

---

减少上下文切换是现代编程中的一件大事。您可以在Node.js、Nginx、epoll、ReactiveX和许多其他地方看到它。

抢占式调度必须解决一个难题——让各种地方的各种软件高效地共享一个CPU

协作调度解决了一个简单得多的问题——允许为协同工作而设计的程序之间共享CPU

---

因此，如果你能侥幸逃脱，那么合作计划就更便宜、更容易了。允许协作调度工作的小型设备的关键在于，所有软件都来自一个供应商，所有程序都可以设计为协同工作。

协作调度的同步问题更少

协作调度可以在某些（大多是人为的）场景中具有更好的性能

协作调度对线程的设计和实现引入了约束

由于糟糕的I/O性能，协作调度对于大多数实际用途基本上是无用的，这就是几乎没有人使用它的原因

即使是小型设备，如果可能的话，也会倾向于使用抢占式调度。智能手机、流媒体（尤其是视频）以及需要良好I/O的应用程序在协作系统中基本不可能实现

---

剩下的是微不足道的嵌入式烤箱控制器等。

首先，你必须找到抢占这个词的含义

抢占是指在不需要计算机系统配合的情况下，临时中断计算机系统正在执行的任务，并打算在以后恢复该任务的行为。已执行任务的此类更改称为上下文切换。（）

因此，区别是

• 在抢占式模型中，操作系统的线程调度程序是 允许随时介入并将控制从一个线程转移到另一个线程 时间（可以强制暂停任务）

• 在协作模型中，一旦一个线程被赋予控制权，它将继续执行 运行直到它显式地产生控制（将CPU控制权移交给下一个任务）或直到它阻塞为止

两种模式各有优缺点。当CPU必须运行各种互不相关的软件时，抢占式调度效果更好。当运行为协同工作而设计的程序时，协作调度工作得更好

协作调度线程的示例：

Windows光纤（）

索尼的PlayStation4SDK（）

如果您想了解这些协作调度光纤的实现，请参阅本书（）

---

你的书中提到“手机等小型设备”，可能是作者指的是几年前的手机。他们只有很少的程序可以运行，而且都是由手机制造商提供的。因此，我们可以假设这些程序是为协同工作而设计的。

硬实时控制应用程序通常要求至少一个线程/任务不被抢占中断，而其他线程则更宽容。此外，最高优先级的任务可能需要在严格的时间表上执行，而不是任由最终提供时间段的调度器摆布。对于这些应用程序，协作式多任务处理似乎比抢占式多任务处理更接近所需，但它仍然不是一个完全合适的方法，因为某些任务可能需要立即按需中断响应，而其他任务对多任务处理方案不太敏感。

协作调度 任务将在一个名为（同步点）的点上放弃CPU。它可以在POSIX中使用类似的内容：

• pthread.yield（任务ID）

抢占式调度

---

这里的主要区别在于，在抢占式调度中，调度程序可能会强制任务放弃CPU。例如，两个优先级相同的任务，其中一个在运行时，其时间片结束。

谢谢您的回答，因此，具有减少上下文切换和同质软件条件的单用户环境有利于协作调度。。。希望我理解正确。手机，尤其是智能手机，非常需要i/O。它们可能是最糟糕的例子，说明合作调度是有用的。你的书是。。可怜的马丁·詹姆斯，你能推荐一个更好的吗……：），除了Java文档…@Roshan如果你只想学习Java本身：Deitel-Java如何编程，真正的android，使用抢占式时间切片，然后