最近在看Go语言的goroutine调度，看到一篇理论文章，对一些关于Linux多线程的知识进行进一步的了解并且记录。
目录
什么是：CPU寄存器 CPU上下文切换？
进程上下文切换
线程上下文切换
中断上下文切换
Go程序内核线程能有多少个?
Linux创建的线程是用户级还是内核级线程？
什么是：CPU寄存器 CPU上下文切换？
CPU寄存器，是CPU内置的容量小、但速度极快的内存。
在说上下文切换的前，需要知道
程序计数器(Program Counter,PC)，则是用来存储CPU正在执行的指令的位置，或者即将执行的下一条指令的位置。他们(CPU寄存器和程序计数器)都是CPU在运行任何任务前，必须依赖的环境，因此也被叫做CPU上下文。
CPU上下文切换，就是先把前一个任务的CPU上下文(也就是CPU寄存器和程序计数器)保存起来，然后加载新任务的上下文，到这些寄存器和程序计数器，最后再跳转到程序计数器所指的新位置，运行新任务。而保存下来的上下文，会存储在系统内核中，并在任务重新调度执行的时候再加载进来。这样就能保证任务原来的状态不受影响，让任务看起来还是连续运行。
CPU上下文切换分为三种：
进程上下文切换线程上下文切换中断上下文切换进程上下文切换Linux 按照特权等级，把进程的运行空间分为内核空间和用户空间，分别对应着下图中。CPU特权等级的Ring0 和 Ring3(也就是说Ring0和Ring3程序可以在CPU上运行)。
内核空间(Ring 0)具有最高权限，可以直接访问所有资源。用户空间(Ring 3)只能访问受限资源，不能直接访问内存等硬件设备，必须通过系统调用陷入到内核中，才能访问这些特权资源。换个角度看，也就是说，进程即可以在用户空间运行，又可以在内核空间中运行。进程在用户空间运行是，被称为进程的用户态，而陷入内核空间的时候，被称为进程的内核态。
从用户态到内核态的转变，需要通过系统调用来完成，比如当我们查看文件内容时，就需要多次系统调用来完成：首先调用open()打开文件，然后调用read()读取文件内容，并调用write()将内容写到标准输出，最后再调用close()关闭文件。
那么，系统调用的过程有没有发生CPU上下文切换呢？答案是肯定的。CPU寄存器里原来用户态的指令位置，需要先保存起来。接着，为了执行内核态代码，CPU寄存器需要更新为内核态指令的新位置。最后才是跳转到内核态运行内核任务。而系统调用结束后，CPU寄存器需要恢复原来保存的用户态，然后再切换到用户空间，继续运行进程，所以一次系统调用的过程，其实是发生了两次CPU上下文切换。
不过，需要注意的是，系统调用过程中，并不会涉及到虚拟内存等进程用户态的资源，也不会切换进程。这跟我们通常所说的进程上下文切换是不一样的。进程上下文切换，是指从一个进程切换到另一个进程运行；而系统调用过程中一直是同一个进程在运行。
所以，系统调用过程通常称为特权模式切换，而不是上下文切换。但实际上系统调用过程中，CPU的上下文切换还是无法避免的。
那么，进程上下文切换跟系统调用又有什么区别呢？首先，进程是由内核来管理和调度的，进程的切换只能发生在内核态。所以进程的上下文不仅包含了虚拟内存、栈、全局变量等用户空间的资源，还包含了内核堆栈、寄存器等内核空间状态。
因此，进程的上下文切换就比系统调用多了一步：在保存当前进程的内核状态和CPU寄存器之前，需要先把该进程的虚拟内存、栈等用户态资源保存下来；而加载了下一进程的内核态后，还需要刷新新进程的虚拟内存和用户栈。如下图所示，保存上下文和恢复上下文的过程，并不是免费的，需要内核在CPU上允许才能完成。
根据Tsuna的测试报告，每次上下文切换都需要几十纳秒到数微妙的CPU时间。这个时间还是相当可观的，特别是进程上下文切换次数较多的情况下，很容易导致CPU将大量的时间耗费在寄存器、内核栈、以及虚拟内存等资源的保存和恢复上，进而大大缩短了真正运行进程的时间。
另外，我们知道，Linux通过TLB(Translation Lookaside Buffer)来管理虚拟内存到物理内存的映射关系。当虚拟内存更新后，TLB也需要刷新，内存的访问也会随之变慢。特别是在多处理器系统上，缓存是被多个处理器共享的，刷新缓存不仅会影响当前处理器的进程，还会影响共享缓存的其他处理器的进程。
知道了进程上下文切换潜在的性能问题后，我们再来看，究竟什么时候会切换进程上下文？显然，进程切换时才需要切换上下文，换句话说，只有在进程调度的时候，才需要切换上下文。Linux为每个CPU都维护了一个就绪队列，将获取进程(即正在运行和等待CPU的进程)按照优先级和等待CPU的时间排序，然后选择最需要CPU的进程，也就是优先级最高和等待CPU时间最长的进程来运行。
那么，进程在什么时候才会被调度到CPU上运行呢？最容易想到的一个时机，就是进程执行完，终止了，它之前使用的CPU会释放出来，这个时候再从就绪队列里，拿一个新的进程过来运行。其实还有很多其他场景，也会触发进程调度，这里逐个梳理下。
为了保证所有进程可以得到公平调度，CPU时间片被划分为一段段的时间片，这些时间片再被轮流分配给各个进程。这样，当某个进程的时间片耗尽了，就会被系统挂起，切换到其他正在等待CPU的进程运行。进程在系统资源不足(比如内存不足)时，需要等到资源满足后才可以运行，这个时候进程也会被挂起，并由系统调度其他进程运行。当进程通过睡眠函数sleep这样的方法将自己主动挂起时，自然也会重新调度。当有优先级更高的进程运行时，为了保证高优先级进程的运行，当前进程会被挂起，由高优先级的进程来运行。当发生硬件中断时，CPU上的进程会被中断挂起，转而执行内核中中断服务程序。线程上下文切换线程与进程最大的区别在与，线程是调度的基本单位，而进程则是资源拥有的基本单位。所谓内核中的任务调用，实际上的调度对象是线程；而进程只是给线程提供了虚拟内存、全局变量等资源。所以，对于线程和进程，我们可以这么理解：
当进程只有一个线程时，可以认为进程就等于线程。当进程拥有多个线程时，这些线程会共享相同的虚拟内存和全局变量等资源。这些资源在上下文切换时是不需要修改的。线程也有自己的私有数据，比如栈和寄存器等，这些在上下文切换时也是需要保存的。这么一来，线程的上下文切换其实就可以分为两种情况：
前后两个线程属于不同进程，此时，由于资源不共享，所以切换过程就跟进程上下文切换是一样的。前后两个线程属于同一个进程，此时，应为虚拟内存是共享的，所以在切换时，虚拟内存这些资源就保持不动，只需要切换线程的私有数据，寄存器等不共享的数据。所以同为上下文切换，但同进程内的线程切换，要比多进程间切换消耗更少的资源，这也正是多线程代替多进程的一个优势。
中断上下文切换为了快速响应硬件的时间，中断处理会打断进程的正常调度和执行，转而调用中断处理程序，响应设备时间。而在打断其他进程时，就需要将进程当前的状态保存下来，这样在中断结束后，进程仍然可以从原来的状态恢复运行。
因为中断这块一般都不会涉及，所以不做过多介绍。
Go程序内核线程能有多少个?
其实这个是简单的问题(上面已经间接回答了)，在没有看goroutine的MPG调度模型前，我肯定知道，理论上会有N个内核线程；但是看完后，总是模模糊糊的，以为会和CPU个数有关系，其实没有关系，M(即内核线程)是按需创建的，但是如果只有一个cpu（1核）同一时刻只能执行一个内核线程。(这也算是个误区，很多人认为runtime.GOMAXPROCS可以限制系统线程的数量)
虽然M理论上可以有N(但是N<maxcount)个，但是很多以后会有一个问题就是，频繁CPU上下文切换，倒是大多时间都消耗在CPU上下文切换。
Linux创建的线程是用户级还是内核级线程？
你可能知道：线程分为内核态线程和用户态线程，用户态线程需要绑定内核态线程，CPU并不能感知用户态线程的存在，它只知道它在运行1个线程，这个线程实际是内核态线程。
线程的实现曾有3种模型：
多对一(M:1)的用户级线程模型一对一(1:1)的内核级线程模型多对多(M:N)的两级线程模型上面的x对y(x:y)即x个用户态线程对应y个内核调度实体(Kernel Scheduling Entity，这个是内核分配CPU的对象单位)。
多对一用户线级程模型
多对一线程模型中，线程的创建、调度、同步的所有细节全部由进程的用户空间线程库来处理。用户态线程的很多操作对内核来说都是透明的，因为不需要内核来接管，这意味不需要内核态和用户态频繁切换。线程的创建、调度、同步处理速度非常快。当然线程的一些其他操作还是要经过内核，如IO读写。这样导致了一个问题：当多线程并发执行时，如果其中一个线程执行IO操作时，内核接管这个操作，如果IO阻塞，用户态的其他线程都会被阻塞，因为这些线程都对应同一个内核调度实体。在多处理器机器上，内核不知道用户态有这些线程，无法把它们调度到其他处理器，也无法通过优先级来调度。这对线程的使用是没有意义的！
一对一内核极线程模型
一对一模型中，每个用户线程都对应各自的内核调度实体。内核会对每个线程进行调度，可以调度到其他处理器上面。当然由内核来调度的结果就是：线程的每次操作会在用户态和内核态切换。另外，内核为每个线程都映射调度实体，如果系统出现大量线程，会对系统性能有影响。但该模型的实用性还是高于多对一的线程模型。
多对多两极线程模型
多对多模型中，结合了1：1和M：1的优点，避免了它们的缺点。每个线程可以拥有多个调度实体，也可以多个线程对应一个调度实体。听起来好像非常完美，但线程的调度需要由内核态和用户态一起来实现。可想而知，多个对象操作一个东西时，肯定要一些其他的同步机制。用户态和内核态的分工合作导致实现该模型非常复杂。linux多线程模型曾经也想使用该模型，但它太复杂，要对内核进行大范围改动，所以还是采用了一对一的模型！！！
那么，Linux下C语言thread_create函数创建的线程属于用户级还是内核级。其实创建的还是用户级线程，只不过对应了一个内核级的内核调度线程(这个线程实际的内核调度器分配的)，即一对一(1:1)的内核级线程模型。
Go语言中goroutine使用就是一种特殊的两级线程模型(MPG模型)。得益于这种模型，所以Go语言并发性比其他语言都要好。
参考原文：
CPU上下文切换是什么
Linux历史上线程的3种实现模型
Go并发原理