操作系统的线程模型

操作系统的线程调度有几个重要的概念：

调度器（Thread Scheduler）：内核通过操纵调度器对内核线程进行调度，并负责将线程的任务映射到各个处理器上
内核线程（Kernel Level Thread）：简称KLT，每个内核线程可以视为内核的一个分身，这样操作系统就有能力同时处理多件事情。同时支持多线程的内核就叫做多线程内核
轻量级进程（Light Weight Process）：简称LWP，在实际程序中我们一般不直接使用内核线程，用户线程与内核线程之间需要一种中间数据结构，它由内核支持且是内核线程的高级抽象，这个高级接口被称为轻量级进程（Light Weight Process）轻量级进程就是我们通常意义上所讲的线程，当然也属于用户线程；由于每个轻量级进程都由一个内核线程支持，因此只有先支持内核线程，才能有轻量级进程。通俗理解把轻量级进程当做内核线程在用户空间的代理线程就好了
用户线程（User Level Thread）：简称ULT，LWP虽然本质上属于用户线程，但LWP线程库是建立在内核之上的，LWP的许多操作都要进行系统调用，因此效率不高。而这里的用户线程（User Thread）指的是完全建立在用户空间的线程库，用户线程的建立，同步，销毁，调度完全在用户空间完成，不需要内核的帮助。因此这种线程的操作是极其快速的且低消耗的。

操作系统线程模型

线程实现在用户空间中
当线程在用户空间下实现时，操作系统对线程的存在一无所知，操作系统只能看到进程，而不能看到线程。所有的线程都是在用户空间实现。在操作系统看来，每一个进程只有一个线程。过去的操作系统大部分是这种实现方式，这种方式的好处之一就是即使操作系统不支持线程，也可以通过库函数来支持线程。在用户空间实现线程时，每一个进程针对自己的线程维护了一个用于保存线程运行的各种变量，比如寄存器，PC，状态等信息的线程表(Thread Table)，该线程表在进程的Run-Time System中维护，当一个线程被block，她的当前运行状态会被保存在线程表中，当再次启动时，也会读取线程表中已经保存的状态，从该状态进行再次运行。用户线程的创建、调度、同步和销毁全由库函数在用户空间完成，完全不需要内核的帮助。

优点：
线程的调度只是在用户态，减少了操作系统从内核态到用户态的切换开销。
用户空间的线程可以自定义调度算法，程序员完全可以自己写一套针对自己程序的线程调度算法。
缺点：
对于内核来说，不管进程里面有多少个线程，内核仍然按照单线程进程来处理这个进程，所以同一时间一个进程里面只能有一个线程运行，就算有多个cpu空闲，也只能有一个线程运行，所以无法最大限度的使用资源
当一个进程中的某一个线程进行系统调用时，比如缺页中断而导致线程阻塞，即使这个进程中其它线程还在工作，此时操作系统会阻塞整个进程。
由于每个进程中只有一个内核线程，所有用户态的线程共用一个内核线程，所有这又被称作 N:1线程模型
线程实现在操作系统内核中
内核线程是建立在内核空间的线程库，只运行在内核态。内核线程就是内核的分身，一个分身可以处理一件特定事情。内核线程同样有线程表(Thread Table)，该线程表在内核中维护，内核线程可以在全系统内进行资源的竞争，它们的建立和销毁都是由操作系统负责、通过系统调用完成的。通俗的将就是，程序员直接使用操作系统中已经实现的线程，而线程的创建、销毁、调度和维护，都是靠操作系统（准确的说是内核）来实现，程序员只需要使用系统调用，而不需要自己设计线程的调度算法和线程对CPU资源的抢占使用。

内核线程驻留在内核空间，它们是内核对象。有了内核线程，每个用户线程被映射或绑定到一个内核线程。用户线程在其生命期内都会绑定到该内核线程。一旦用户线程终止，两个线程都将离开系统。这被称作1:1线程映射
用户线程加轻量级进程混合实现
一个应用程序中的多个用户级线程被映射到一些（小于或等于用户级线程的数目）内核级线程上。在这种混合实现下，即存在用户线程，也存在轻量级进程。用户线程还是完全建立在用户空间中，因此用户线程的创建、切换、析构等操作依然廉价，并且可以支持大规模的用户线程并发。而操作系统提供支持的轻量级进程则作为用户线程和内核线程之间的桥梁，这样可以使用内核提供的线程调度功能及处理器映射，并且用户线程的系统调用要通过轻量级进程来完成，大大降低了整个进程被完全阻塞的风险。在这种混合模式中，用户线程与轻量级进程的数量比是不定的，即为N:M的线程模型

明白了前面两种模型，就应该很好理解这种线程模型了，但实际上现在主流的操作系统已经不太常用这种线程模型了。目前来说，作为异步回调以外的另一种解决方案，这种m:n的线程模型可以说大有可为，Golang的协程就是使用了这种模型，在用户态，协程能快速的切换，避免了线程调度的CPU开销问题，协程相当于线程的线程。

Java线程在操作系统上本质
在JDK1.2之前，开发者们为JVM开发了自己的一个线程调度内核，而到操作系统层面就是用户空间内的线程实现。而到了JDK1.2及以后，JVM选择了更加稳健且方便使用的操作系统原生的线程模型，通过系统调用，将程序的线程交给了操作系统内核进行调度

Java线程在JDK1.2之前，是基于称为“绿色线程”（Green Threads）的用户线程实现的，而在JDK1.2中，线程模型替换为基于操作系统原生线程模型来实现。因此，在目前的JDK版本中，操作系统支持怎样的线程模型，在很大程度上决定了Java虚拟机的线程是怎样映射的，这点在不同的平台上没有办法达成一致，虚拟机规范中也并未限定Java线程需要使用哪种线程模型来实现。线程模型只对线程的并发规模和操作成本产生影响，对Java程序的编码和运行过程来说，这些差异都是透明的。

对于Sun JDK来说，它的Windows版与Linux版都是使用一对一的线程模型实现的，一条Java线程就映射到一条轻量级进程之中，因为Windows和Linux系统提供的线程模型就是一对一的。也就是说，现在的Java中线程的本质，其实就是操作系统中的线程，Linux下是基于pthread库实现的轻量级进程，Windows下是原生的系统Win32 API提供系统调用从而实现多线程。

Java的绿色线程、原生线程/内核线程与虚拟线程的区别
Java 21将会正式推出尝试已久的虚拟线程技术，国内外已经有了很多报道。大约从Java 14开始，就开始引入尝鲜版的技术，当时叫什么的都有，虚拟线程，纤程或轻量级线程。看起来，以后会叫虚拟线程。由于写新闻的这些人，年龄不够大，文章跟测评都写的很好，但是没有见过Java以前的样子，感觉没有抓住本质，我尝试从历史的角度来写一下这玩意的进化史。

先从Java 1.0那个年代算起吧，那时候是1995年，硬件没有双核，软件以Linux为例，2003年前的Linux不支持线程。当时Linux可以用进程来模拟线程，用的是LinuxThreads这个线程库，但是总归有诸多的缺陷。

而Java呢，在没有双核/多核，没有操作系统支持线程的情况下，竟然支持了线程。你可能会问，都没有双核/多核，你支持线程有什么用呢？还是有用处的，可以并发运行，比如在等待打印机的时候，我们可以玩一把游戏，提高电脑并发的速度。因为当时都是单核，而多核要在2005年以后才出现。Java如何做到的呢？把线程做到JVM（Java虚拟机）中。要不然能怎么办？当时JVM自己就一个主线程。这样做的好处是：就算不支持多线程的操作系统（当年的Linux）也可以用上Java的“绿色”线程。缺点越来越明显：因为后来支持多核了，你就一个主线程，那肯定没法用上多核心啊。

后来操作系统都支持多线程了（Linux 2.6之后)，大家也都用扣肉，4核，8核，32核的CPU了，绿色线程的模型越来越不好用了，于是，Java改成了线程交给操作系统来管理，将Java线程映射为操作系统级别的线程。这种线程模型也通常被称为”原生线程”或”内核线程”。

然而，操作系统线程也有其缺点。比如，创建、销毁和切换线程都需要消耗相当多的资源，因此在一个系统中同时存在的线程数量是有上限的。此外，大量的线程可能会导致线程调度器过载，从而影响系统的性能。

那怎么办呢？那就再把线程管理收归“Java虚拟机”所有啊！这次新发布的虚拟线程是在Java虚拟机（JVM）内部实现的，它们比操作系统线程更轻量级，创建和切换的成本更低。虚拟线程并不直接映射到操作系统线程，而是由JVM和运行时系统调度和执行。因此，可以在一个系统中创建大量的虚拟线程，而不会对系统性能产生太大的影响。

感觉像转了一圈：最初的绿色线程是由JVM管理的，后来为了追求性能，又交给了操作系统，后来操作系统又成了系统的瓶颈，JVM又收回了线程的管理。但是，这个圆圈可不是原地踏步，而是螺旋上升的。

进程、线程、协程介绍

进程：系统中所有的应用程序都是以进程(process)的方式运行，是系统进行资源分配和调度的基本单位，每个进程都有自己的独立的地址空间，使得进程之间的地址空间相互隔离。进程拥有自己的堆栈，不共享堆和栈，是由操作系统进行调度的。

线程：线程是程序执行流的最小单元上，通常意义上，一个进程由一个到多个线程组成，各个线程之间共享程序的内存空间(包括代码段、数据段、堆等)及一些进程级的资源(如打开的文件和信号)。线程拥有自己的独立的栈和共享的堆，也是由操作系统进行调度。

协程：协程在Go语言中，由轻量级线程实现，由Go运行时(runtime)管理。Go协程也叫用户态线程，协程之间的切换发生在用户态，在用户态没有时钟中断，系统调用等机制，因此效率高。协程共享堆，不共享栈，协程的调度由用户控制。