linux进程内核态状态核心由state和exit_state字段决定：state控制调度（如task_running=0、task_interruptible=1、task_uninterruptible=2），exit_state管理退出生命周期（如exit_zombie=16），二者分离避免语义混淆，通过task_struct双链表实现高效状态切换与唤醒。
Linux进程状态的内核态视角，核心在于state和exit_state两个字段——它们不是用户看到的符号标签，而是内核调度器实时决策的依据。进程能不能上CPU、要不要被唤醒、该不该回收，全由这两个值决定。
state 字段：决定能否被调度的核心开关
该字段定义在 include/linux/sched.h 中，类型为 volatile long，直接映射到进程控制块 task_struct。它不表示“正在做什么”，而表示“此刻能不能参与CPU竞争”：
- TASK_RUNNING（R）：值为 0，进程在运行队列中；哪怕没真正在执行，只要就绪就归于此态；内核调度器会从中挑选高优先级或时间片未耗尽者上CPU
- TASK_INTERRUPTIBLE（S）：值为 1，进程已主动让出CPU，挂入某等待队列（如等待磁盘IO完成、管道数据到达），但收到任意信号（如 SIGKILL）即中断等待、转为 TASK_RUNNING
- TASK_UNINTERRUPTIBLE（D）：值为 2，进程处于深度睡眠，不响应任何信号；常见于等待不可中断的底层资源（如磁盘驱动I/O、NFS服务器响应）；此时 kill -9 也无效，必须等资源就绪或内核超时
- 其他状态如 TASK_STOPPED、TASK_TRACED：分别对应被调试器暂停或收到 SIGSTOP 后的冻结态，此时进程完全脱离调度器管理
exit_state 字段：专管“退出生命周期”的独立维度
与 state 并行存在，用于标记进程是否进入退出流程，避免 state 被复用导致语义混淆：
- EXIT_ZOMBIE（Z）：子进程已终止，但父进程尚未调用 wait() 回收其退出状态；此时 task_struct 仍驻留内存，仅释放除PCB外的所有资源；Z状态进程不占CPU，但持续消耗内核进程表项
- EXIT_DEAD：wait() 已被调用，task_struct 正在被内核清理；此状态极短暂，用户几乎无法通过 ps 观察到
双链表组织：状态变更的物理基础
内核不靠轮询查状态，而是靠 struct list_head tasks 将所有 task_struct 连成双向循环链表。每个状态对应一个专门队列头（如 runqueue、wait_event_head）：
- 当进程从 R 变为 S，内核将其从运行队列移出，插入对应事件的等待队列
- 当磁盘IO完成，设备驱动直接遍历该IO等待队列，将所有相关进程的 state 改为 TASK_RUNNING，并加入运行队列
- 这种“按需唤醒+链表定位”机制，保证了状态切换高效且无遗漏
为什么用户态看到的 R/S/D/Z 和内核态不完全一一对应？
ps/top 做了两层简化：
- 合并 TASK_RUNNING 的“运行中”和“就绪排队”为统一的 R，不区分当前是否真在CPU上
- 把 TASK_UNINTERRUPTIBLE 和某些特殊内核线程状态（如内核线程的 TASK_IDLE）都显示为 D，但实际内核中它们的 state 值可能不同
- 对僵尸进程，只显示 Z，隐藏了 exit_state == EXIT_ZOMBIE 的真实含义，也不体现父进程是否已忽略 SIGCHLD
