#yyds干货盘点#进程的各种状态详解进程和内存管理相关原理 _管理相关

少年击剑更吹箫，剑气箫心一例消。这篇文章主要讲述#yyds干货盘点#进程的各种状态详解进程和内存管理相关原理相关的知识，希望能为你提供帮助。
1. 进程状态
进程的基本状态
创建状态：进程在创建时需要申请一个空白PCB(process control block进程控制块)，向其中填写控制和管理进程的信息，完成资源分配。如果创建工作无法完成，比如资源无法满足，就无法被调度运行，把此时进程所处状态称为创建状态
就绪状态：进程已准备好，已分配到所需资源，只要分配到CPU就能够立即运行
执行状态：进程处于就绪状态被调度后，进程进入执行状态
阻塞状态：正在执行的进程由于某些事件（I/O请求，申请缓存区失败）而暂时无法运行，进程受到阻塞。在满足请求时进入就绪状态等待系统调用
终止状态：进程结束，或出现错误，或被系统终止，进入终止状态。无法再执行
状态之间转换六种情况
运行——> 就绪：1，主要是进程占用CPU的时间过长，而系统分配给该进程占用CPU的时间是有限的；2，在采用抢先式优先级调度算法的系统中,当有更高优先级的进程要运行时，该进程就被迫让出CPU，该进程便由执行状态转变为就绪状态
就绪——> 运行：运行的进程的时间片用完，调度就转到就绪队列中选择合适的进程分配CPU
运行——> 阻塞：正在执行的进程因发生某等待事件而无法执行，则进程由执行状态变为阻塞状态，如发生了I/O请求
阻塞——> 就绪:进程所等待的事件已经发生，就进入就绪队列以下两种状态是不可能发生的：
阻塞——> 运行：即使给阻塞进程分配CPU，也无法执行，操作系统在进行调度时不会从阻塞队列进行挑选，而是从就绪队列中选取
就绪——> 阻塞：就绪态根本就没有执行，谈不上进入阻塞态
进程更多的状态：
运行态：running
就绪态：ready
睡眠态（处于最多的是睡眠态）：分为两种，可中断：interruptable，不可中断：uninterruptable
停止态：stopped，暂停于内存，但不会被调度，除非手动启动
僵死态：zombie，僵尸态，结束进程，父进程结束前，子进程不关闭，杀死父进程可以关闭僵死态的子进程
僵尸态
?

[root@centos8 ~]#bash
[root@centos8 ~]#echo $BASHPID
1809
[root@centos8 ~]#echo $PPID
1436
#将父进程设为停止态
[root@centos8 ~]#kill -19 1436
#杀死子进程，使其进入僵尸态
[root@centos8 ~]#kill 1809
[root@centos8 ~]#ps aux #可以看到上面图示的结果，STAT为Z，表示为僵尸态

#恢复或杀死父进程
[root@centos8 ~]#kill -18 1436
#或者
[root@centos8 ~]#kill -9 1436
#再次观察，可以僵尸态的进程不存在了
[root@centos8 ~]#ps aux

2. LRU 算法LRU：Least Recently Used 近期最少使用算法（喜新厌旧），释放内存
?
假设序列为 4 3 4 2 3 1 4 2，物理块有3个，则
第1轮 4调入内存 4
第2轮 3调入内存 3 4
第3轮 4调入内存 4 3
第4轮 2调入内存 2 4 3
第5轮 3调入内存 3 2 4
第6轮 1调入内存 1 3 2
第7轮 4调入内存 4 1 3
第8轮 2调入内存 2 4 1
3. IPC 进程间通信IPC: Inter Process Communication
同一主机：
pipe 管道,单向传输
socket 套接字文件
Memory-maped file 文件映射,将文件中的一段数据映射到物理内存，多个进程共享这片内存
shm shared memory 共享内存
signal 信号
Lock 对资源上锁，如果资源已被某进程锁住，则其它进程想修改甚至读取这些资源，都将被阻塞，直到锁被打开
semaphore 信号量，一种计数器
不同主机：
socket=IP和端口号
RPC remote procedure call
MQ 消息队列，生产者和消费者，如：Kafka，RabbitMQ，ActiveMQ
利用管道文件实现进IPC

[root@centos8 ~]#mkfifo /data/test.fifo
[root@centos8 ~]#ll /data/test.fifo prw-r--r-- 1 root root 0 May 6 14:32 /data/test.fifo
[root@centos8 ~]#cat > /data/test.fifo
magedu

#在另一个终端用cat命令可以从文件中读取数据，实现进程间通信
[root@centos8 ~]#cat /data/test.fifo
magedu

查找socket文件

find/ -type s -ls

4. 进程优先级
CentOS 优先级
?
进程优先级：
系统优先级：数字越小，优先级越高
0-139（CentOS 4,5），各有140个运行队列和过期队列
0-98，99（CentOS 6）
实时优先级: 99-0 值最大优先级最高
nice值：-20到19，对应系统优先级100-139或99
Big O：时间（空间）复杂度，用时（空间）和规模的关系
O(1), O(logn), O(n)线性, O(n^2)抛物线, O(2^n)
5. 操作系统分类：操作系统分类：
协作式多任务：早期 windows 系统使用，即一个任务得到了 CPU 时间，除非它自己放弃使用
CPU ，否则将完全霸占 CPU ，所以任务之间需要协作——使用一段时间的 CPU ，主动放弃使用
抢占式多任务：Linux内核，CPU的总控制权在操作系统手中，操作系统会轮流询问每一个任务是否需要使用 CPU ，需要使用的话就让它用，不过在一定时间后，操作系统会剥夺当前任务的 CPU使用权，把它排在询问队列的最后，再去询问下一个任务
进程类型：
守护进程: daemon,在系统引导过程中启动的进程，和终端无关进程
前台进程：跟终端相关，通过终端启动的进程
注意：两者可相互转化
按进程资源使用的分类：
CPU-Bound：CPU密集型，非交互
IO-Bound：IO密集型，交互
6. IO调度算法在LINUX 2.6中,有四种关于IO的调度算法,下面综合小结一下:
NOOP
NOOP算法的全写为No Operation。该算法实现了最简单的FIFO队列，所有IO请求大致按照先来后到的顺序进行操作。之所以说“大致”，原因是NOOP在FIFO的基础上还做了相邻IO请求的合并，并不是完完全全按照先进先出的规则满足IO请求。NOOP假定I/O请求由驱动程序或者设备做了优化或者重排了顺序(就像一个智能控制器完成的工作那样)。在有些SAN环境下，这个选择可能是最好选择。Noop 对于 IO 不那么操心，对所有的 IO请求都用 FIFO 队列形式处理，默认认为 IO 不会存在性能问题。这也使得 CPU 也不用那么操心。当然，对于复杂一点的应用类型，使用这个调度器，用户自己就会非常操心。
Deadline scheduler
DEADLINE在CFQ的基础上，解决了IO请求饿死的极端情况。deadline 算法保证对于既定的 IO 请求以最小的延迟时间，除了CFQ本身具有的IO排序队列之外，DEADLINE额外分别为读IO和写IO提供了FIFO队列。读FIFO队列的最大等待时间为500ms，写FIFO队列的最大等待时间为5s。FIFO队列内的IO请求优先级要比CFQ队列中的高，，而读FIFO队列的优先级又比写FIFO队列的优先级高。优先级可以表示如下：
FIFO(Read) > FIFO(Write) > CFQ
Anticipatory scheduler
CFQ和DEADLINE考虑的焦点在于满足零散IO请求上。对于连续的IO请求，比如顺序读，并没有做优化。为了满足随机IO和顺序IO混合的场景，Linux还支持ANTICIPATORY调度算法。ANTICIPATORY的在DEADLINE的基础上，为每个读IO都设置了6ms 的等待时间窗口。如果在这6ms内OS收到了相邻位置的读IO请求，就可以立即满足 Anticipatory scheduler（as) 曾经一度
是 Linux 2.6 Kernel 的 IO scheduler 。Anticipatory 的中文含义是”预料的, 预想的”, 这个词的确揭示了这个算法的特点，简单的说，有个 IO 发生的时候，如果又有进程请求 IO 操作，则将产生一个默认的 6 毫秒猜测时间，猜测下一个进程请求 IO 是要干什么的。这对于随即读取会造成比较大的延时，对数据库应用很糟糕，而对于 Web Server 等则会表现的不错。这个算法也可以简单理解为面向低速磁盘的，因为那个”猜测”实际上的目的是为了减少磁头移动时间。
CFQ
CFQ算法的全写为Completely Fair Queuing。该算法的特点是按照IO请求的地址进行排序，而不
是按照先来后到的顺序来进行响应。在传统的SAS盘上，磁盘寻道花去了绝大多数的IO响应时间。CFQ的出发点是对IO地址进行排序，以尽量少的磁盘旋转次数来满足尽可能多的IO请求。在CFQ算法下，SAS盘的吞吐量大大提高了。但是相比于NOOP的缺点是，先来的IO请求并不一定能被满足，可能会出现饿死的情况。
Completely Fair Queuing （cfq, 完全公平队列) 在 2.6.18 取代了 Anticipatory scheduler 成为 Linux Kernel 默认的 IO scheduler 。cfq 对每个进程维护一个 IO 队列，各个进程发来的 IO 请求会被 cfq 以轮循方式处理。也就是对每一个 IO 请求都是公平的。这使得 cfq 很适合离散读的应用 (eg: OLTP DB)

【#yyds干货盘点#进程的各种状态详解进程和内存管理相关原理】