进程状态的学习
进程状态就是 task_struct 内的一个整数
状态间是可以进行转化的
运行：
每一个框都是进程的task_struct，都有唯一的pcb和pid来标识它的唯一性
让CPU选择一个进程去运行，本质是选择一个进程的PCB去运行，task_struct里一定有内存指针用来找到我们要运行的对应进程的代码和数据
头部的优先级比较高，尾部的优先级比较低
只要在这个队列里，进程状态都是running，不是说正在被CPU调度的进程才是运行
要么就是正在被CPU运行，要么就是准备好了随时等待被调度
-->运行+准备就绪
阻塞？
例子：
scanf 进程自己就停下来了，等用户输入
准确来说不是等用户输入，而是等待硬件键盘就绪
意义？
等待某种设备或资源就绪，一直不就绪，我们的进程就不会被调度也就卡在那里不动了
OS对软硬件进行管理？
怎么做？
先描述再组织，创建对应的数据结构，所有设备用struct device 来描述起来，为每一个设备构建一个struct device的结点，用指针把设备链接起来，每种设备都是对应底层不同的硬件设备，转化成对链表的增删查改
和我们的进程一样，管理也要先描述再组织
struct device 描述的就是目标设备的所有属性
OS有运行队列也要有设备队列，每个设备都有自己的等待队列
假设我们的CPU正在运行我们的这个进程，运行的时候执行这个进程的代码，发现这个进程要进行canf读取了，读取时OS发现我们要都键盘，转而去帮我们检查键盘的 status 状态，发现我们的键盘并没有任何按键被按下，当前设备不是活跃的，这个进程无法读取到键盘的数据，无法进行执行了，所以OS把这个进程从cpu上拿下来，并且把这个进程从运行队列中移走，把它的pcb链入到我们对应的特定的等待队列当中，一旦链入到其他队列当中，不在运行队列里了，他就永远不会被调度了，那么这个进程就处于阻塞状态，卡在了那里，不在运行队列里，只有在运行队列里才会被cpu调度，在设备的等待队列里了，那这个进程就叫做阻塞
从运行队列到阻塞的本质其实是吧pcb链入到不同的队列结构当中
那我们的进程就在等这个设备里，那我们的键盘被按下了，键盘被我们用户按下时，我们这个进程
他不知道，键盘按下属于硬件就绪OS作为硬件的管理者，硬件状态发生变化，OS要第一时间知道
os一旦知道了，os就直接查看对应的这个就绪设备的这个结点，将状态设置为活跃的，并且检查等待队列，发现等待队列里指针不为空，就将该等待队列里头部的这个进程的状态设置为运行状态，然后将该进程重新链回我们的进程队列里，这个时候进程还没有被调度，键盘上的数据还没有被进程读取，再后来cpu调度这个进程时，这个进程就会继续运行曾经的scanf，然后把对应的数据从设备上读到进程当中，来被我们拿到
从阻塞回到运行状态，本质上是找到我们的pcb，再把我们的pcb链回到运行队列里面，这样他就变成运行状态了
阻塞挂起：
有一些数据当前不会被立即访问，但是他们还是占着内存
我们这些等待状态的进程，这些进程的代码和数据不会被执行使用，除非这个设备已经就绪了，他没有就绪的时候，pcb代码数据都是闲置的，占着内存空间
内存不足的时候我们OS就要去处理
我们的磁盘存在一个swap交换分区，干什么的？
我们的内存严重不足，把阻塞状态进程的代码和数据直接交换到我们对应的磁盘的swap分区上
只保留进程的pcb，把对应的代码和数据换出到对应的磁盘上，再想运行时，就再把资源还给他们
OS就把这些在阻塞队列当中的进程的代码和数据交换到磁盘当中，此时这些进程的状态就叫做阻塞挂起
内存不足时，OS要做一些内存置换的办法，把一些不会被调度的进程或相关内存块交换到对应的磁盘上，这个时候，这些没有代码和数据只有PCB的进程成为阻塞挂起
OS一旦好了，就会把我们对应的进程曾经换入到磁盘的代码和数据重新加载到内存，重新构建指针映射，让我们找到，把曾经加换到磁盘当中的代码和数据换入内存，换入内存之后形成完整进程。再把这个完整进程放到运行队列里，这个过程叫做swap交换分区的换入和换出操作
被换出到交换分区称为阻塞挂起
换入时，把阻塞挂起进程重新回到运行队列中，该进程就可以继续被调度
挂起是把对应进程的代码和数据挂到外设上
运行挂起状态：
如果这样内存还是不够，OS就只能把正在运行队列末端的进程的代码和数据也全部交换到交换分区真正调度到我们时再换回来
就算是有很多CPU，也不可能调用全部的进程
此时，我们又把这个称之为运行挂起状态
挂起本质是把进程代码和数据换入换出到磁盘swap交换分区里
理解内核链表的话题
首先设置 list_head 的结点，包含next和lprev指针
定义一个结构体（内核当中的任何一个结构体）
链表的结点是不包含任何的数据的，而是把链表的结点的next和prev指针单独封装成一个结点类型，把这个结点类型作为新的目标数据结构的一个成员
有很多个 task_struct 连接节点的时候，我们这个结点是怎么链接的？
并不需要让next直接指向下一个 task_struct
next指针指向的是下一个 list_head
我们以前的这个链表结点的next都是会指向下一个的整个node
Linux内核当中我们的next只会指向目标结构体内部的某个成员对象
比如这里的links
我们要遍历整个进程，能从这个links到下一个links，那一部分是很方便遍历的
要是我们想访问 task_struct 结构体里面的其他属性呢？
-->
在一个结构体里面，结构体变量本身的地址和结构体变量的第一个成员的地址在数字上是相等的
一个结构体内，所有内部成员的地址从上往下是依次增大的
我们要访问结构体里面任何的属性怎么做到呢？
强转
我们认为从0号位置地址处就存在task_struct结构体，然后我们再直接去访问它对应的links再对他进行取地址，
-->我们就得到了links相较于结构体开始位置的偏移量
-->我们只知道当前linsk的地址
拿到next的值，它的值就是下一个结构体变量links的起始地址
-->减去偏移量，此时整个指针的内容就指向结构体的头部了
再强转成 struct task_struct，这样未来这个结构体的所有属性我们都能访问了
可以在 struct task_struct 内部有很多个这样的结点
我们可以在这个字段把进程用双链表链接起来
可以把任何 struct task_struct 一套对象，一种属性的每一个 struct task_struct 既属于运行队列，又属于全局列表
只要是结点类型的，可以放到我们想放的任何地方
-->
一个 pcb在内核当中只存在一份，可以同时隶属于多种数据结构
状态：
R状态
S 阻塞
t：追踪状态
要被debug，断点：进程被暂停了
T 暂停
D 深度睡眠，不可中断睡眠，深度睡眠
S 休眠状态，可中断休眠，浅睡眠
X 死亡状态，结束状态
Z
僵尸--为了获取退出信息
我们创建子进程的目的，是为了让子进程完成某种事情的
结果相关的信息，父进程得知道
所以在子进程退出之后，父进程获取子进程退出之前，就必须有一个叫做Z状态
代码和数据可以释放掉，但必须维持进程退出的基本信息，让我们的父进程知道我们退出的信号
信息保存在 task_struct
父进程不获取，就一直是那个状态
模拟验证 Z ？
如果父进程一直不管，不回收，不获取子进程的推出信息，那么Z就会一直存在
pcb就一直维护，内存就一直占用-->内存泄漏问题
进程退出了，内存泄漏问题就不在了
启动之后不退出的，我们称之为常驻内存的进程-->常驻内存
关于内核结构申请的
维护一张废弃的task_struct的列表 ，叫做unuse
我们可以释放掉，也可以不释放，不释放，我们把这个进程pcb放到我们的unuse列表里，可以让其他列表初始化去使用
形成了，类似数据结构对象的数据缓存，可以加速我们创建进程和释放进程的速度
-->slab