用户态线程和内核态线程的区别

用户级线程

“既然你已经看过线程的基本概念，那我就直接跳过这一部分了。很久很久之前，线程的概念是出现了，但操作系统厂商可不能直接就去修改操作系统的内核，因为对他们来说，稳定性是最重要的。贸然把未经验证的东西加入内核，出问题了怎么办？所以想要验证线程的可用性，得另想办法。”

“我知道我知道，那些研究人员就编写了一个关于线程的函数库，用函数库来实现线程！”小白得意的说：“这个我刚刚在网上看到了。”

“是的，他们把创建线程、终止线程等功能放在了这个线程库内，用户就可以通过调用这些函数来实现所需要的功能。”小明找了张纸，写上了几个函数：pthread_creat，pthread_exit ，pthread_join ，pthread_yield ，接着说：“这是几个重要的功能，我马上会讲到，你应该能大概猜出这些函数的功能吧？”

“emmmm，让我想想，pthread_creat 是创建一个新线程，pthread_exit 是结束线程，pthread_join 嘛，我猜是准备运行，最后一个，我就不知道了。”

“不知道也没关系，一会你就清楚了。”小明接着讲：“要知道，刚刚我们说的线程库，是位于用户空间的，操作系统内核对这个库一无所知，所以从内核的角度看，它还是按正常的方式管理。”

小白问道：“也就是说操作系统眼里还是只有进程喽？那我用线程库写的多线程进程，只能一次在一个 CPU 核心上运行？” （因为操作系统调度的是进程，每次只能调度不同的进程，所以同一个进程里的线程无法并行）

小明点点头，说：“你说的没错，这其实是用户级线程的一个缺点，这些线程只能占用一个核，所以做不到并行加速，而且由于用户线程的透明性，操作系统是不能主动切换线程的，换句话讲，如果线程 A 正在运行，线程 B 想要运行的话，只能等待 A 主动放弃 CPU，也就是主动调用 pthread_yield 函数。”

注：对操作系统来说，用户级线程具有不可见性，也称透明性。

“停一下，让我想一想，”小白飞速思考着小明的话，“是不是说，即使有线程库，用户级线程也做不到像进程那样的轮转调度？”

“非常正确！看来你对进程的概念很清楚嘛。不过呢，虽然不能做到轮转调度，但用户级线程也有他自己的好处——你可以为你的应用程序定制调度算法，毕竟什么时候退出线程你自己说了算。刚刚说了，因为操作系统只能看到进程的存在，那如果某一个线程阻塞了，你觉得会发生什么？”

“在操作系统眼里，是进程阻塞了，那么整个进程就会进入阻塞态，在阻塞操作结束前，这个进程都无法得到 CPU 资源。那就相当于，该进程中所有的线程都被阻塞了。”小白得意的回答。

“没错，所以如果任由线程进行阻塞操作，进程的效率将受到很大的影响，所以在这个过程中，出现了一个替代方案——jacket。所谓 jacket，就是把一个产生阻塞的系统调用转化成一个非阻塞的系统调用。”

小白惊讶地问：“这怎么做得到？该阻塞的调用，还能变得不阻塞？”

小明答道：“我来举个例子吧，不是直接调用一个系统 I/O 例程，而是调用一个应用级别的 I/O jacket 例程，这个 jacket 例程中的代码会检查并且确定 I/O 设备是不是正忙，如果忙的话，就在用户态下将该线程阻塞，然后把控制权交给另一个线程。隔一段时间后再次检查 I/O 设备。就像你说的，最后还是会执行阻塞调用，但使用 jacket 可以缩短被阻塞的时间。不过有些情况下是可以不被阻塞的，取决于具体的实现。”

小明停顿了一会，说：“用户级线程的概念大概就这么多，我们接下来讲内核级线程吧。”

内核级线程

“有了用户级线程的铺垫，内核级线程就好讲多了。现在我们知道，许多操作系统都已经支持内核级线程了。为了实现线程，内核里就需要有用来记录系统里所有线程的线程表。当需要创建一个新线程的时候，就需要进行一个系统调用，然后由操作系统进行线程表的更新。当然了，传统的进程表也还是有的。你想想看，如果操作系统「看得见」线程，有什么好处？“

小白自信的回答：“操作系统内核如果知道线程的存在，就可以像调度多个进程一样，把这些线程放在好几个 CPU 核心上，就能做到实际上的并行了。”

“还有一点你没有说到，如果线程可见，那么假如线程 A 阻塞了，与他同属一个进程的线程也不会被阻塞。这是内核级线程的绝对优势。”

“那内核级线程就没有什么缺点吗？”

“缺点当然是有的，你想想看，让操作系统进行线程调度，那意味着每次切换线程，就需要「陷入」内核态，而操作系统从用户态到内核态的转变是有开销的，所以说内核级线程切换的代价要比用户级线程大。还有很重要的一点——线程表是存放在操作系统固定的表格空间或者堆栈空间里，所以内核级线程的数量是有限的，扩展性比不上用户级线程。”

用户级线程（User-Level Threads ULT）

用户空间运行线程库，任何应用程序都可以通过使用线程库被设计成多线程程序。线程库是用于用户级线程管理的一个例程包，它提供多线程应用程序的开发和运行的支撑环境，包含：用于创建和销毁线程的代码、在线程间传递数据和消息的代码、调度线程执行的代码以及保存和恢复线程上下文的代码。
所以线程的创建、消息传递、线程调度、保存/恢复上下文都由线程库来完成。内核感知不到多线程的存在。内核继续以进程为调度单位，并且给该进程指定一个执行状态（就绪、运行、阻塞等）。

纯用户级线程的特点：

线程切换不需要内核模式，能节省模式切换开销和内核资源。

允许进程按照特定的需要选择不同的调度算法来调度线程。调度算法需要自己实现。

由于其不需要内核进行支持，所以可以跨OS运行。

不能利用多核处理器的优势，OS调度进程，每个进程仅有一个ULT能执行

一个ULT阻塞，将导致整个进程的阻塞。

jacketing技术可以解决ULT一个线程阻塞导致整个进程阻塞。

jacketing的目标是把一个产生阻塞的系统调用转化成一个非阻塞的系统调用。例如,当进程中的一个线程调用IO中断前，先调用一个应用级的I/O jacket例程，而不是直接调用一个系统I/O。让这个jacket例程检查并确定I/O设备是否忙。如果忙，则jacketing将控制权交给该进程的线程调度程序，决定该线程进入阻塞状态并将控制权传送给另一个线程（若无就绪态线程咋可能执行进程切换）。

这种在系统调用周围从事检查的这类代码称为包装器（jacket 或 wrapper）。这种处理方法需要重写部分系统调用库，所以效率不高也不优雅，不过没有其他的可选方案了。——《现代操作系统 - 第4版》

内核级线程（Kernel-Level Threads, KLT 也有叫做内核支持的线程）

线程管理的所有工作（创建和撤销）由操作系统内核完成
操作系统内核提供一个应用程序设计接口API，供开发者使用KLT

纯内核级线程特点：

进程中的一个线程被阻塞，内核能调度同一进程的其他线程（就绪态）占有处理器运行

多处理器环境中，内核能同时调度同一进程的多线程，将这些线程映射到不同的处理器核心上，提高进程的执行效率（这样可以实现并行）。

应用程序线程在用户态运行，线程调度和管理在内核实现。线程调度时，控制权从一个线程改变到另一线程，需要模式切换，系统开销较大。

可以看出，用户级线程和内核级线程都有各自的优点和缺点，在应用上主要表现为：

用户级多线程对于处理逻辑并行性问题有很好的效果。不擅长于解决物理并行问题。
内核级多线程适用于解决物理并行性问题。

线程实现的组合策略

由操作系统内核支持内核级多线程，由操作系统的程序库来支持用户级多线程，线程创建完全在用户空间创建，线程的调度也在应用程序内部进行，然后把用户级多线程映射到（或者说是绑定到）一些内核级多线程。编程人员可以针对不同的应用特点调节内核级线程的数目来达到物理并行性和逻辑并行性的最佳方案。

多对一（Many to One）

顾名思义，多对一线程模型中，多个用户线程对应到同一个内核线程上，线程的创建、调度、同步的所有细节全部由进程的用户空间线程库来处理。这样，极大地减少了创建内核态线程的成本，但是线程不可以并行。因此，这种模型现在基本上用的很少。我再多说一句，这里你可能会有疑问，比如：用户态线程怎么用内核态线程执行程序？

程序是存储在内存中的指令，用户态线程是可以准备好程序让内核态线程执行的。

优点：

用户线程的很多操作对内核来说都是透明的，不需要用户态和内核态的频繁切换。使线程的创建、调度、同步等非常快。

缺点：

由于多个用户线程对应到同一个内核线程，如果其中一个用户线程阻塞，那么该其他用户线程也无法执行。
内核并不知道用户态有哪些线程，无法像内核线程一样实现较完整的调度、优先级等

一对一（One to One）

该模型为每个用户态的线程分配一个单独的内核态线程，在这种情况下，每个用户态都需要通过系统调用创建一个绑定的内核线程，并附加在上面执行。这种模型允许所有线程并行执行，能够充分利用多核优势。目前 Linux 中的线程、OpenJDK Java 线程等采用的都是一对一线程模型。每一个JVM线程，都有一个对应的内核线程。

优点：

实现起来较为简单

该模型的缺点是：

每创建一个用户线程，相应地就需要创建一个内核线程，开销较大，因此需要限制整个系统的线程数量。
对用户线程的大部分操作都会映射到内核线程上，引起用户态和内核态的频繁切换。

多对多（Many To Many）

这种模式下会为 n 个用户态线程分配 m 个内核态线程。m 通常小于 n。一种可行的策略是将 m 设置为核数。这种多对多的关系，减少了内核线程，同时也保证了多核心并行。多对多模型中线程的调度需要由内核态和用户态一起来实现，例如线程间同步需要用户态和内核态共同实现。用户态和内核态的分工合作导致实现该模型非常复杂。Linux多线程模型曾经也想使用该模型，但它太复杂，要对内核进行大范围改动，所以还是采用了一对一的模型！

该模型的缺点是：