备案中网站打不开网站邮件功能设计理论

备案中网站打不开,网站邮件功能设计理论,天津视频网站开发团队,长沙房产网二手房出售信息新建#xff1a;进程刚被创建#xff0c;正在加载到内存的过程中#xff08;完成内存分配、代码 / 数据加载#xff09;#xff0c;待加载完成后会进入内存并加入就绪队列。就绪#xff1a;进程已准备好执行#xff0c;等待 CPU 调度运行#xff1a;进程正在 CPU 上执行…新建进程刚被创建正在加载到内存的过程中完成内存分配、代码 / 数据加载待加载完成后会进入内存并加入就绪队列。就绪进程已准备好执行等待 CPU 调度运行进程正在 CPU 上执行指令阻塞进程因等待事件如硬件资源、信号暂停释放 CPU挂起就绪就绪进程被换出内存暂存到外存需 “换入” 回内存才能继续等待调度挂起阻塞阻塞进程被换出内存暂存到外存事件发生后先 “换入” 回内存再转为就绪结束进程执行完成资源被系统回收【状态转换逻辑】新建 → 就绪进程加载完成就绪 ↔ 运行CPU 调度就绪进程获得 CPU 转为运行运行进程时间片超时 / 被抢占回到就绪运行 → 阻塞进程等待事件如请求 IO阻塞 → 就绪等待的事件发生就绪 ↔ 挂起就绪内存不足时就绪进程代码和数据被换出PCD对象还在内存中被 “换出” 到外存外存中进程被 “换入” 回内存阻塞 ↔ 挂起阻塞阻塞进程被 “换出” 到外存外存中阻塞进程等待的事件发生后先 “换入” 回内存运行 → 结束进程执行完成【说明】代码语言txtAI代码解释上述是操作系统理论中的全量进程状态而在 Linux 系统中_运行、阻塞、挂起_是最 核心的三种状态实际会通过更具体的状态标识如 R、S、D 等来对应这些逻辑状态。接下来我们就基于进程状态的通用理论模型来详细解析这三种状态的具体定义与特点 1 运行状态进程的运行状态是衡量它在 CPU 调度环节活跃程度的核心状态。 当进程处于这一状态时会呈现两种具体情形CPU 执行中已经获取到 CPU 的使用权正在借助 CPU 完成运算、逻辑处理等实际任务就绪队列待命所有运行前的资源准备都已完成只要操作系统的调度器为它分配 CPU 时间就能马上切换到 CPU 上开始执行这个时候实际上进程处于就绪态。运行状态CPU 执行中是进程 “正在使用 CPU 资源” 的状态而就绪态队列待命是进程 “具备执行条件、等待获取 CPU 资源” 的状态二者共同构成了进程活跃性的核心体现。 2 进程状态转换运行态 - 就绪态进程被调度到 CPU 上运行后不会一直执行到完毕比如while(1);这类无限循环代码也不会独占 CPU核心原因是 “时间片” 机制时间片的定义每个进程会被分配一个固定时长的 CPU 使用权比如10ms时间片的作用时间片耗尽后当前运行态的进程会被从 CPU 上 “拿下来”回到就绪队列对应 “我已经准备好了可以随时被调度” 的状态最终效果通过 “进程切换”频繁将进程在 CPU 和就绪队列间切换在一个时间段内所有进程的代码都会被轮流执行实现并发执行。 3 阻塞状态阻塞状态进程因等待某类资源 / 事件如 I/O 操作、信号、锁而无法继续执行的状态进入条件运行态的进程在执行中需要等待资源比如读取磁盘文件、等待网络数据会主动放弃 CPU由运行态转为阻塞态状态特征处于阻塞态的进程即使 CPU 空闲也无法被调度执行因为缺少必要资源其 PCB 会被移至 “阻塞队列”而非就绪队列退出条件当进程等待的资源 / 事件就绪比如文件读取完成会从阻塞态转为就绪态PCB 被移回就绪队列等待 CPU 调度。简言之阻塞状态是进程 “不具备执行条件缺资源、无法使用 CPU” 的状态是进程非活跃性的典型体现。 4 挂起状态① 阻塞挂起阻塞挂起是挂起状态的核心子状态之一指进程因等待资源 / 事件处于阻塞态时又因系统内存不足其代码和数据被换出到外存如磁盘的状态进入条件系统内存紧张时会将阻塞队列中的进程移动的是代码和数据并且会在PCB中标记移到的位置换出到外存转为阻塞挂起状态状态特征进程既缺少执行所需的资源符合阻塞态的条件同时代码和数据也不在内存双重 “无法执行”退出条件先等进程等待的资源 / 事件就绪阻塞挂起态转为就绪挂起态再等系统内存充足由就绪挂起态换入内存恢复为就绪态。swap 分区是磁盘上的存储空间在阻塞挂起场景中它会暂存进程的代码和数据此时进程 PCB 仍留在阻塞队列是内存不足时实现进程挂起与恢复的关键载体。② 就绪挂起就绪挂起是挂起状态的子状态指进程本身已具备执行条件符合就绪态要求但因系统内存不足且阻塞进程已被优先挂起其代码和数据被换出到外存如 swap 分区PCB 仍保留在就绪队列的状态进入逻辑系统会优先将阻塞态进程挂起释放内存若内存仍不足才会将就绪队列中暂未被调度的进程就绪态的代码和数据换出到外存转为就绪挂起状态PCB 留在就绪队列标记数据外存位置状态特征进程 “能执行但没内存”需等系统内存充足后代码和数据从外存换入内存恢复为就绪态核心逻辑“先阻塞挂起、后就绪挂起” 是因为阻塞进程本就无法执行挂起它们的内存成本更低是系统优先保障资源利用率的策略。二、Linux进程状态下面的状态是在Linux内核源代码中定义的代码语言javascriptAI代码解释/* * The task state array is a strange bitmap of * reasons to sleep. Thus running is zero, and * you can test for combinations of others with * simple bit tests. */ static const char * const task_state_array[] { R (running), /* 0运行状态 */ S (sleeping), /* 1睡眠状态 */ D (disk sleep), /* 2磁盘休眠状态 */ T (stopped), /* 4停止状态 */ t (tracing stop), /* 8跟踪停止状态 */ X (dead), /* 16死亡状态 */ Z (zombie), /* 32僵尸状态 */ };1、R运行状态running定义进程已具备执行条件正在等待 CPU 调度或正在 CPU 上执行R 状态运行状态就绪状态Linux 中用 “R 状态运行状态” 统一指代 “可执行的进程状态”不管是正在执行还是等待调度不再单独区分 “运行态” 和 “就绪态”而是通过 “是否在 CPU 上执行” 来区分 R 状态的两种场景。【测试1】​​​​​​启动这个程序后发现它的进程状态一直是阻塞类状态对应 Linux 中的 S 态。这是为什么呢 因为我们一直在用printf函数向显示器输出内容进程会进入显示器的等待队列等待 IO 资源就绪。这个操作会让进程处于 “等待 IO 资源” 的阻塞状态而 CPU 处理速度极快进程实际占用 CPU 的时间极短所以大多数时间都处于阻塞状态呈现出持续阻塞的状态。S(Sleeping)进程处于可中断休眠状态此时它没在运行而是等待某个条件满足比如等待键盘输入、磁盘读写完成、sleep定时器到期这个状态下不会占用 CPU 资源。(Foreground)表示进程是当前终端的前台进程终端的所有输入包括按CtrlC发送中断信号都会直接作用于它能直接中断进程它会占据当前终端你需要等它运行结束或者按CtrlZ将其暂停并切换到后台切换后进程状态会变成S且不带才能在同一个终端里执行其他命令。无(Background)表示进程是当前终端的后台进程终端的输入包括CtrlC不会影响它无法直接用CtrlC中断若要操作它需要用fg命令将其切回前台或用kill命令发送信号中断也可以在启动进程时直接加例如./test 让进程一开始就在后台运行。【测试2】去掉printf后进程状态始终是R这是因为代码里没有了等待 IO 的操作进程会一直占用 CPU 执行无限循环所以持续处于运行态R同时它是前台进程所以状态显示为R。2、S睡眠状态sleeping定义意味着进程在等待事件完成这里的睡眠有时候也叫做 可中断睡眠 interruptible sleep 运行上述程序你会发现该进程几乎一直处于休眠状态 —— 这是因为代码里循环执行的printf和sleep操作都会让进程进入阻塞休眠状态printf需要向终端输出内容进程会阻塞等待 IO 资源就绪sleep会让进程主动休眠指定时长期间同样处于阻塞状态。这两种操作都会让进程暂时让出 CPU所以它大部分时间都处于休眠阻塞状态。问题为啥bash始终处于S状态bash 始终处于 S 状态是因为它在等待用户输入命令此时处于 IO 阻塞的休眠状态。3、D磁盘休眠状态disk sleepD 状态磁盘休眠状态disk sleep是 Linux 进程的一种阻塞状态指进程因等待磁盘 IO 操作完成而进入的休眠状态。进程在等待磁盘读写比如从硬盘读取文件、向硬盘写入数据此时会暂停执行、不占用 CPU属于不可中断睡眠与 S 态的 “可中断” 不同—— 进程在等待磁盘 IO 期间不会响应普通的信号比如CtrlC只能等磁盘操作完成后才会被内核唤醒。【不可中断睡眠小故事】进程凑到磁盘跟前递过一摞数据“劳烦帮存 1000M存好存坏都跟我说声哈” 磁盘擦了擦磁头应下进程闲着没事往旁边一躺就睡了 —— 这是能被叫醒的 “可中断休眠”S 态。 存到一半操作系统攥着内存统计单急慌慌跑过来瞅见睡着的进程就皱了眉“内存都快挤爆了腾地方” 话没说完直接把进程 “清” 没了。 这边磁盘吭哧吭哧存到 900M突然弹出 “空间不足” 的提示 —— 存失败了。它扭头就喊进程报信可喊破喉咙进程早没了踪影。1000M 数据没处交代只能跟着 “蒸发” 了。这数据要是银行一天的转账记录损失可就大了行长把进程、磁盘、系统都叫到办公室磁盘先摆手“我按进程说的存了最后找不着它我有啥办法”进程委屈巴巴“我睡得好好的莫名其妙就没了我才是冤大头”系统也喊冤“内存都不够撑到下一秒了不杀它系统崩了损失更大”行长听完叹了口气拍板定了规矩“以后进程等磁盘干活时就睡‘叫不醒的觉’—— 叫‘不可中断休眠’D 态。这时候谁都不能动它必须等磁盘把活儿干完、把信儿传给它才能接着来”打这儿起进程再等磁盘这类关键设备干活时就会钻到 D 态的 “保护壳” 里 —— 既能安心等结果也能护着数据不丢啦。不可中断睡眠D 态是系统里比较 “特殊” 的进程状态一旦进程进入这个状态通常只能等它完成磁盘 IO 后自行唤醒哪怕重启系统都未必能终止它极端情况下甚至得靠断电才能强制结束。 而且这个状态在正常系统里很少见 —— 要是你的进程长时间比如持续几秒卡在 D 态基本是计算机出问题的信号大概率是磁盘老化比如用了 5 年以上导致 IO 操作异常才让进程陷在这个 “醒不来” 的状态里。【浅睡眠和深度睡眠对比】维度浅睡眠S 态深度睡眠D 态触发场景等待 IO、定时器等非关键操作等待磁盘等关键 IO 操作信号响应能被普通信号如 CtrlC唤醒不响应普通信号只能等 IO 完成系统操作可被系统杀死如内存不足时系统无法杀死必须等 IO 结束作用灵活等待可中断保护关键数据避免操作中断4、T停止状态stopedT状态停止状态stopped是 Linux 进程的一种暂停状态指进程因接收到暂停信号如 CtrlZ** 而暂时停止执行但并未终止。 核心特点场景 1gdb 调试暂停在 gdb 调试中通过设置断点让进程进入 T 态执行break 行号/函数名比如break main.c:10设置断点当程序运行到断点处时会自动暂停执行进入 T 态此时进程的代码、数据等资源仍保留在内存中可在 gdb 中进行查看变量、单步调试等操作调试完成后执行 gdb 的continue命令进程会从断点处恢复运行。场景 2信号暂停如 CtrlZ用户可通过kill命令向进程发送暂停信号SIGSTOP让进程进入 T 态执行kill -SIGSTOP 进程ID进程会暂停运行内存中的代码、数据等资源保持不释放后续若要恢复进程可执行kill -SIGCONT 进程ID发送继续信号进程会从暂停处恢复执行简单说T 状态是进程 “被暂停但没结束” 的状态随时可以恢复运行。【kill场景演示】此时进程处于S 态可中断睡眠因为它在持续等待 IO 设备输出。我用kill -19对应SIGSTOP信号暂停了进程此时进程进入T 态停止状态。使用kill -18对应SIGCONT信号让进程恢复运行它回到了之前的S 态可中断睡眠同时不再保持前台运行状态。【gdb场景演示】此时 gdb 进程处于S 态可中断睡眠因为它在等待用户输入调试指令。通过b main打主函数断点、r运行程序后程序会在断点处暂停 —— 此时被调试的./test 进程进入 t 态跟踪停止状态gdb 进程仍保持 S 态等待后续调试操作。 这里的t态是停止状态的细分场景它专门对应 “进程被调试器如 gdb跟踪暂停” 的情况和普通的 T 态比如用 CtrlZ 挂起的停止状态在触发场景上有所区别。【t跟踪停止状态tracing stop】核心定义: 进程因为被调试器如gdb跟踪而暂停执行的状态。常见触发方式:代码语言txtAI代码解释1. 程序运行到**断点**处break 命令。 2. 使用**单步执行**命令next, step后。 3. 在程序运行时按下 Ctrl C 主动中断。代码语言txtAI代码解释- 在调试器中使用 continue, next, step 等命令让程序继续执行。【S/D 与 T的区别】S睡眠、D磁盘休眠是 “被动等待”进程是因为缺少资源如 IO 未完成、数据未就绪而被迫进入阻塞等资源满足后会自动恢复T停止是 “主动干预下的等待”进程是被外部信号如kill -STOP或调试工具gdb主动暂停需要人为执行恢复操作如kill -CONT才会继续。5、X死亡状态deadXdead是进程彻底终止前的瞬时状态你不会在ps/top里看到它。核心特点仅存在于内核回收进程资源的瞬间无交互性资源回收完成后进程直接消失。6、Z僵尸状态zombie【僵尸状态由来小故事】下午三点你坐在咖啡馆靠窗的位置刚喝完最后一口拿铁起身拿起包准备离开。 就在你推门的瞬间邻桌的客人突然捂住胸口趴在桌上没了动静。你吓了一跳立刻喊来店员同时拨了急救电话。 店员的第一反应不是直接把人抬走 —— 而是先守在桌边不让其他客人碰桌上的物品手机、药瓶同时等医生和警察到现场。毕竟得先搞清楚是突发疾病还是有其他情况这些 “现场信息” 得留着等专业人员确认。这时候这位客人虽然已经没了意识但还在原地等着 “后续处理”—— 就像进程的僵尸状态自身运行已经停止但 “父进程系统” 还没回收它的状态信息不能直接清理。等医生做完初步检查、警察记录完现场信息工作人员才把人抬上救护车 —— 这个 “信息交接完、彻底离场” 的瞬间就是进程的死亡状态X所有收尾工作完成彻底从系统里消失。总而言之僵死状态Zombies是一个比较特殊的状态。当进程退出并且父进程使用wait()系统调用,后面讲) 没有读取到子进程退出的返回代码时就会产生僵尸进程僵尸进程会以终止状态保持在进程表中并且会一直在等待父进程读取退出状态代码。所以只要子进程退出父进程还在运行但父进程没有读取子进程状态子进程进入Z状态【问题】为什么进程终止后不直接清理反而会进入僵尸状态核心原因是父进程需要获取子进程的 “退出状态” 进程终止时会先将自身的代码、数据、堆栈等内存资源彻底清理但会把 “运行结果”正常结束 / 异常崩溃存在 PCB进程控制块中而父进程需要通过wait()/waitpid()等系统调用读取这个状态才能判断子进程的工作是否完成。这就像 “人意外去世后身体对应进程的代码 / 数据会被处理但现场的证据对应 PCB 里的退出状态会被保留”—— 要等警方对应父进程来调查取证读取退出状态确认死亡原因后才会彻底收尾清理 PCB。若内核直接清理 PCB父进程就会丢失子进程的退出信息相当于 “子进程的工作结果没完成交接”。因此僵尸态是子进程留着 PCB 等父进程 “查收结果” 的临时状态—— 父进程读取状态后内核才会彻底清理 PCB。【僵尸进程演示】进程退出时若父进程未主动回收子进程信息未调用wait()/waitpid()子进程会持续处于僵尸态Z 状态其对应的task_struct结构体进程控制块无法被内核释放仅保留退出状态等必要信息直到父进程处理或自身终止后由 1 号进程接管清理。【问题】为什么父进程不会进入僵尸状态父进程的父进程通常是终端 Shell比如 bash。当我们运行程序时父进程由 Shell 创建并作为其子进程存在。一旦父进程执行结束或被终止Shell 会主动调用wait()类函数回收父进程的退出状态和 PCB 资源不会让父进程残留为僵尸进程。此外即使父进程意外退出系统的 1 号进程init/systemd也会接管并清理其资源因此父进程不会像未被回收的子进程那样成为僵尸。【僵尸进程危害】僵尸进程的定义处于僵尸状态Z 状态的子进程即子进程已退出但父进程未调用wait()/waitpid()读取其退出状态时的进程。僵尸进程的 “内存泄漏” 本质僵尸进程不会造成常规程序的内存泄漏如动态分配内存未释放导致堆内存占用但从系统资源管理角度会引发类似内存泄漏的不良影响子进程进入僵尸状态时代码段、数据段、堆 / 栈等用户空间资源会被系统释放但进程控制块PCB存储在**task_struct**结构体中会被保留用于存储子进程的退出状态如正常结束、信号终止等单个 PCB 占用内存较小几十几百字节但大量僵尸进程的 PCB 会持续积累占用的内存无法被其他进程利用宏观上造成内存资源的 “泄漏”。不同进程的影响差异常驻内存进程如后台服务、守护进程若产生僵尸进程会长期占用资源逐渐拖垮系统短生命周期进程退出时系统会自动回收大部分资源僵尸进程问题相对不突出。系统不主动回收 PCB 的原因task_struct中保存了子进程的退出状态关键信息操作系统需要将这些信息完整交付给父进程因此必须维护PCB直到父进程主动调用wait()获取信息 —— 回收僵尸进程的责任由开发者承担。7、孤儿进程当父进程先于子进程退出时子进程会变成孤儿进程原父进程已消失子进程 “无父”。 此时操作系统会将这个孤儿进程的父进程重新设置为 1 号进程init/systemd系统初始化进程由 1 号进程 “领养” 它。 当孤儿进程后续退出并进入僵尸状态Z 状态时1 号进程会主动调用wait()类函数回收它的退出状态和 PCB 资源避免其残留为僵尸进程。 简单说父进程提前退 → 子进程变孤儿 → 1 号进程领养 → 子进程退出后由 1 号进程回收不会成为僵尸进程。【孤儿进程演示】从图中可以看出父进程结束后子进程的PPID就变成1了这也刚好验证了我们上面说的没问题