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

Posted 2021-12-15 王华_linux

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)