进程这个话题我在不同场合讲过很多次但每次讲完总有人追着问一些看似基础但一深究就懵的问题ps 输出里的 STAT 那么多字母到底啥意思为什么程序卡在 D 状态怎么 kill 都杀不掉fork 出来的子进程到底复制了什么多个进程之间要怎么优雅地通信这些零零散散的问题其实全都是进程这一个知识体系下的东西。这篇我打算把 Linux 进程从概念到实操、从命令到原理、从通信到调度完整梳理一遍把我这些年踩过的坑和积累的经验一次性倒出来。适合刚接触 Linux 的运维新手、写 C/C/Go/Java 的服务端开发以及被端口占用、CPU飙高、进程杀不掉折磨过的普通用户花半小时读一遍后面能省很多排查时间。1. 进程到底是什么——先搞清楚你每天打交道的东西1.1 程序和进程的区别别再说进程就是运行中的程序很多教程会告诉你进程是运行中的程序这句话对但不完整。我更愿意用做饭来类比程序是菜谱它安静地躺在磁盘上进程是照着菜谱正在灶台上操作的厨师它占据着灶台CPU、操作着锅碗瓢盆内存、文件句柄。菜谱可以被很多厨师同时照着做一个程序也可以被启动成多个进程。从操作系统内核的角度来看进程是一个动态实体也是系统资源分配的基本单位。每个进程拥有自己的虚拟地址空间、文件描述符表、信号处理方式、当前工作目录、环境变量等一堆属性。内核靠一个叫task_struct的结构体来管理每个进程你可以把它理解成每个学生的档案袋里面记录了姓名、学号、各科成绩、家庭住址等等。所有进程的档案袋串成一个链表调度器就靠遍历这些档案来决定谁先上 CPU 跑。这里有个容易混淆的细节程序和进程不是一一对应的。同一个程序启动 100 次就有 100 个进程每个进程的地址空间、打开的文件、PID 都不同。反过来一个进程在运行过程中也可以通过exec家族函数把自己替换成另一个程序程序变了但 PID 没变——所以严格说进程是一次运行的全过程程序只是这个过程某一阶段加载的代码。1.2 进程的内存画像虚拟地址空间长什么样进程之所以能相互隔离、不越界访问核心靠的是虚拟地址空间这个抽象层。每个进程拥有独立的虚拟地址空间从低地址到高地址大致是这样排列的文本段代码段存放编译后的机器指令只读多个相同程序的进程可以共享这一部分。数据段存放全局变量、静态变量细分为已初始化数据段.data和未初始化数据段.bss。堆程序运行期间动态分配内存的区域向高地址方向增长malloc/new 分配的内存就在这里。内存映射区mmap 映射的文件、动态链接库、共享内存都在这块区域。栈存放局部变量、函数调用帧向低地址方向增长每个线程都有自己的栈。堆和栈一个向上长一个向下长中间是空闲地带。这也是为什么递归调用太深会导致栈溢出而不是堆溢出——两个方向往中间对冲空间总有用完的时候。理解了这张图你看 pmap 或者 /proc/PID/maps 输出时就不会一脸茫然了。为什么要搞虚拟地址空间这么一层两个好处第一是隔离我的进程不能随便读你的进程内存第二是简化开发每个进程都以为自己独占整个内存空间不用管物理内存碎片和分配细节。写操作系统的人用页表把虚拟地址翻译成物理地址这个翻译过程是 CPU 的 MMU 硬件做的所谓缺页中断、写时复制这些概念全都依托在这层机制上。1.3 进程、线程和进程池从浏览器和微信说起你看任务管理器会发现 Chrome 开一堆进程微信开一堆进程很多人不理解一个应用为什么要搞那么多进程直接所有功能放一个进程里跑不行吗这就说到进程和线程的分工了进程是资源分配的单位线程是 CPU 调度的单位。一个进程里可以有一到多个线程线程共享进程的地址空间和文件描述符表但各自有独立的栈和寄存器上下文。线程切换比进程切换轻量因为不需要切换页表但线程间共享内存也带来了同步麻烦一个线程崩了段错误往往整个进程都崩所有线程都得陪葬。浏览器和微信选择多进程架构图的是崩溃隔离和安全。渲染页面、插件、GPU 这些组件各自放进独立进程一个标签页死了不影响其他页一个进程被攻击了也拿不到别的进程的内存数据。Electron 应用比如 VS Code、很多桌面工具也是这个套路主进程管生命周期和原生能力渲染进程管界面它们之间的通信靠的就是 IPC——这个 IPC 和我们下面要讲的进程间通信是一套思路只是内核帮你把通道封装好了。进程池也好、线程池也好目的都类似进程创建和销毁的开销很大要分配地址空间、建页表、初始化各种资源与其频繁创建销毁不如预先造好一批放在池子里随取随用用完归还而不是销毁。Java 的线程池、MySQL 的连接池、Nginx 的 worker 进程模型都是同一套哲学。2. 进程的一生从出生到消失2.1 进程状态机ps 里的 STAT 字母到底代表什么运行ps aux的时候STAT 列会出现一串字母。这是进程当前所处的状态也是排查问题时第一个要看的字段。内核视角下进程状态大致分为这几种状态对应字母含义说明运行态R正在运行或可运行在就绪队列里等着上 CPU或在 CPU 上跑着睡眠态S可中断睡眠等一个条件发生能响应信号最常见不可中断睡眠D不可中断睡眠等待 IO 完成卡在内核态信号杀不掉停止态T被跟踪/被停止收到 SIGSTOP 或被调试器暂停僵尸态Z僵尸幻影子进程已死但父进程没回收残留 task_struct空闲态I内核空闲线程不在本文讨论范围看到不用慌其中 D 状态是最让人头疼的。网上流行一句进程卡在 D 状态怎么办重启吧话糙理不糙。D 状态通常是进程在内核态等待磁盘 IO 或网络 IO 完成比如 NFS 服务器挂了、磁盘坏了内核线程阻塞在 IO 上。这个状态下的进程用 kill -9 都杀不掉因为信号处理要等它回到用户态才有机会执行而它压根回不来。真遇到一堆 D 状态进程先检查底层存储网络是不是出问题了把 IO 故障解决进程自然恢复实在不行等内核兜底或者重启机器。僵尸进程则是另一番景象子进程已经退出但它向父进程发的 SIGCHLD 信号没有被处理父进程没调 wait/waitpid 回收它的残留信息。僵尸本身不耗 CPU 也不占内存资源已经释放了问题在于内核的 task_struct 还在进程表项被占着PID 号也占着。进程表是有限的几千个僵尸就能把系统的 PID 耗尽害得新进程都 fork 不出来。2.2 fork 与 exec创建进程的两板斧写 C 的人肯定绕不开 fork。fork()的调用一次返回两次在父进程中返回子进程的 PID在子进程中返回 0。这个设计一开始很反直觉但内核的实际操作是复制一份父进程的 task_struct、页表、文件描述符表等然后让调度器去调度这个新 task。Linux 的 fork 用了写时复制技术刚开始父子进程共享物理内存页只有在某一方要写入时才真正复制出独立的页。这一点是 fork 能高效创建进程的关键。另外必须提醒fork 之后缓冲区也是会复制的。最经典的笑话就是父子进程都在退出前 printf结果同一行输出打了两遍——因为标准库的缓冲区在 fork 时也继承了退出时 flush 自然 flush 了两次。解决办法是 fork 前 fflush(stdout)或者直接用 unbuffered 输出。exec 家族函数则是另一件事它用新的程序镜像替换当前进程的代码段、数据段、堆和栈但 PID 保持不动。我们常说的运行一个外部命令本质就是先 fork 一个子进程再在子进程里 exec 一个命令。shell 每次执行 ls、ps 都是走这个流程。创建进程的完整路径是父子协作父进程负责生exec 负责换魂。2.3 回收子进程wait 和僵尸的缘分子进程死后会变成僵尸等你调wait()或waitpid()来收尸。wait 这个系统调用的作用有两层第一获取子进程的退出状态码让你知道它是正常退出还是被信号杀的第二彻底释放子进程残留的内核数据结构把它从进程表里移除。很多服务端进程会 fork 出大量子进程去处理任务那就需要处理 SIGCHLD 信号在信号处理器里调用 waitpid 循环回收子进程。如果不处理就会攒一堆僵尸。新手最容易踩的坑是在信号处理器里只调一次 waitpid结果父进程一次性崩出十个子进程时只收了一两个尸体剩下的全变僵尸了——正确姿势是 while (waitpid(-1, status, WNOHANG) 0) 循环收收到返回 -1 才停。那孤儿进程呢父进程提前挂了子进程被 init/systemd 收养这就叫孤儿。孤儿的父进程 PID 会变成 1它会正常走完生命周期、被 init 回收一般不会留僵尸。反过来如果你写的守护进程 fork 之后父进程退出但没设置好会话子进程还守着终端就可能出现终端关闭进程也被干掉了的情况这点后面讲 nohup 时再展开。2.4 进程树和老祖宗PID 1 是怎么来的所有用户进程的祖先在传统 System V 世界里是 init在现代 Linux 发行版里基本是 systemd。它是操作系统启动后内核启动的第一个进程PID 永远是 1负责拉起各种系统服务、管理运行级别、收养孤儿进程。你可以跑pstree -p看看整棵进程树顶部就是 PID 1。排查一个服务谁启动的、互相之间什么关系pstree 比 ps 直观得多。容器场景里 PID 1 的地位更特殊容器里那个 PID 1 进程如果退出了整个容器就跟着没了。所以在容器里做进程管理的时候很多人会用 tini 之类的工具充当容器内 PID 1负责信号转发和僵尸回收避免出现docker exec 进去 kill 个服务把整个容器搞挂的尴尬。3. 命令行实战像老手一样查进程、控进程3.1 ps静态快照怎么读才对ps 命令是最常用的但新手经常把 ps -ef 和 ps aux 混在一起分不清。其实两者展示的信息几乎一样差别主要在选项风格ps aux 是 BSD 风格ps -ef 是 System V 风格在大多数 Linux 发行版上都能用。如果你要自定义字段用ps -eo pid,ppid,user,stat,start,time,%cpu,%mem,cmd这种组合想排序列直接就--sort-%cpu让 CPU 占用高的排前面。ps 输出里 COMMAND 那一列显示的未必是完整的命令行特别是内核有 comm 字段 15 字节的限制最早的实现里进程名超过 15 个字符就会被截断。我见过不少同事排查时对着ps aux | grep java的输出死磕却发现两个 Java 进程的 COMMAND 一模一样——因为那段长命令行被截断了根本看不出 jar 包路径的区别。要拿完整命令请用ps -f或者去看/proc/PID/cmdline那里是完整的参数列表用tr \0 把参数间的分隔符换成空格才好读。另一个高频场景是找进程所在目录和可执行文件路径ll /proc/PID/exe能显示这个进程真正的可执行文件ll /proc/PID/cwd显示它的工作目录。当你有多个同名进程想确认哪个才是你要找的看这两个就够了。3.2 top 和 htop动态监控的正确姿势ps 是拍快照top 是直播。top 运行时按大写的 P 按 CPU 排序按大写的 M 按内存排序按数字 1 看每个 CPU 核的使用率按大写 T 看累计 CPU 时间。还有一个常被忽略的参数d可以调整刷新间隔比如按一下d然后输入 0.5 就可以让刷新加快。top 里的 load average 有三个数字是过去 1 分钟、5 分钟、15 分钟的平均负载。很多人看到 load 大于 1 就慌其实负载要除以 CPU 核数来理解。四核机器 load 是 4.0相当于每个核都在满负荷干活这才算满载load 是 2.0 说明有一半空闲是正常的。另外 load 高不代表 CPU 高多线程阻塞在 IO 上也会拉高负载所以要结合 top 第一行的 us/sy/wa/id 这几个百分比综合看。htop 是 top 的增强替代品彩色界面、可以鼠标点击排序、显示进程树、直接 F9 发信号还能用搜索定位进程。Linux 发行版大多数仓库都有装一个不亏线上排查时效率能高不少。3.3 kill 的正确姿势上来就 kill -9 是大忌先说信号本身kill -l能看到全部列表但日常你只需要重点掌握这五个信号数字触发方式默认行为可以捕获吗SIGHUP1终端断开/重载配置终止进程可以SIGINT2CtrlC 键盘中断终止进程可以SIGQUIT3Ctrl\终止并产生 core dump可以SIGTERM15kill 默认信号终止进程可以SIGKILL9强杀立即终止无法捕获不可以kill默认发的是 SIGTERM也就是 15给进程一个善终的机会清理资源、保存状态、关闭文件描述符。很多服务端程序都会注册 SIGTERM 的处理函数来做优雅下线。而 SIGKILL 是绕开一切、由内核直接终止进程进程没有机会做任何清理。所以我强烈建议按这个顺序来先 kill PID等几秒看看进程安静退掉没没退再用 kill -9 兜底。这在处理 Nginx、MySQL、Java 应用时尤其重要直接 kill -9 十有八九会留下没写完的数据或者没关干净的连接。按名字杀进程用pkill和killall。pkill 支持按进程名精确匹配也能跟-f用完整命令行匹配。这里有个大坑pkill -f 是按整个命令行字符串匹配的如果命令行里包含了你自己输入的搜索词搞不好会杀到自己。我曾经见过一个同事执行 pkill -f test.py 想把测试脚本干掉结果那个 pkill 命令自己的命令行里就有 test.py把自己也匹配进去杀掉了。后面你会发现进程管理这件事精准定位永远是第一原则。3.4 前后台切换、nohup 与守护进程化一条命令后面加个 让它进后台跑这是最基础的用法。但 shell 的后台进程跟前台一样依附于当前终端会话你关掉终端会话结束时系统会给这个会话里的所有进程发 SIGHUP后台任务默认会被终止。想要终端关了进程还活着方案有三种用nohup 命令 nohup 的作用是让进程忽略 SIGHUP这样终端断开它不会收到挂断信号。输出默认写到 nohup.out 文件里。用setsid 命令让进程开启一个新的会话、脱离当前终端更彻底。在 shell 里先CtrlZ暂停任务用jobs查看bg放到后台再disown把它移出 shell 的作业表关终端也不会收到信号了。为什么终端关了进程会挂因为普通进程属于某一个会话session会话关联着一个控制终端。控制终端断开时内核会给会话首进程发 SIGHUP。setsid 就是绕开这个挂断链路nohup 则是在进程层面忽略掉 SIGHUP。很多系统服务跑起来之后你找不到它挂在哪就是因为它已经 setsid 成功脱离终端完全变成一个孤儿守护进程了。更正式的守护进程化还会涉及到 fork 一次让父进程退出、chdir 根目录、重定向标准输入输出、设置 umask 等步骤简单理解就是把自己从用户的世界里摘出去。4. 进程间通信IPC让多个进程协作起来4.1 管道最朴素的通信方式管道是最好理解也最常用的 IPC一个进程往管道里写另一个进程从管道里读数据像水流一样单方向流动。shell 里的竖线|用的就是匿名管道ps aux | grep nginx的本质是两个进程一个写一个读甚至你可以把这整条命令理解为左侧进程的 stdout 接到右侧进程的 stdin不必落盘。匿名管道只能在父子进程或者有亲缘关系的进程之间用因为它需要继承文件描述符。毫无关系的两个进程要用管道就得走命名管道FIFO命令是mkfifo myfifo然后一个进程cat myfifo另一个进程cat myfifo两边都阻塞着等对方。这个机制虽然简单粗暴但在脚本里做简易的消息传递很实用。管道很容易踩的坑是管道缓冲区和阻塞问题。管道默认有 64KB 的缓冲写入端快速写入而读取端不及时读写满之后 write 会阻塞反过来读端一直读而写端关了读端会收到 EOF。写代码时如果不清楚这一点容易出现程序卡住不动的假象实际是管道两头堵住了。4.2 信号操作系统给进程打的电话信号本质上是一种软件中断让内核有机会通知进程外部发生了一件事。比如网络连接被对方关了内核可能给进程发 SIGPIPECtrlC 会向整个前台进程组发 SIGINT子进程退出会向父进程发 SIGCHLD。信号的局限在于它只能携带极少的语义你顶多知道有信号来了具体什么事情得靠约定。handler 里你能做的操作有限——如果你在信号处理函数里 sleep 或者 malloc可能直接引发死锁或未定义行为因为信号可能在任意执行点打断进程而被打断的代码可能正持有锁。所以业界普遍的做法是信号处理器里只写一个标志位或者往一个管道/事件循环里丢一个消息然后回到主逻辑循环里去判断处理。这是很多新手写守护进程时的经典翻车点记住了这个原则能少踩很多坑。在信号应用层还有个特别常见的案例Nginx 改完配置后不用重启直接向 master 进程发 SIGHUP 信号master 会重新加载配置并平滑重启 worker向 master 发 SIGUSR1 可以重开日志文件。这些都是信号作为控制指令的经典用法。4.3 System V IPC共享内存、消息队列和信号量管道传输需要拷贝数据速度有限。如果你需要高频、大数据量的交互共享内存是最快的方式多个进程把同一块物理内存映射到各自的虚拟地址空间一方写入另一方立即可见内核不参与数据搬运。代价是你要自己处理同步否则两边同时写入就会出现脏数据。配套的同步工具就是信号量本质是一个计数器加 PV 操作P减和 V加必须是原子的用来保证只有一个进程在同一时刻访问共享区域。消息队列则是另一种折中由内核管理写入端 send 消息读取端 recv 消息消息带类型、按先后顺序排队读写双方不直接见面。它的优点是天然带消息边界你收到的一条消息就是对方发送的完整一条不像管道那样一行一行字节流还要自己解析缺点是性能比共享内存低而且系统消息队列的数量有上限fs.msgmni、msgmax 等内核参数控制量大了容易踩阈值。这三个工具日常运维中用到 ipcs 和 ipcrm 的频率更高ipcs -m查共享内存段、ipcs -q查消息队列、ipcs -s查信号量集。程序异常退出后这些内核 IPC 资源可能残留下来占着名额手动ipcrm -m shmid或者ipcrm -q msgid清理即可。4.4 套接字socket与其他 IPC 的选型跨机器通信只能走网络 socket本机进程之间也能用特别是 Unix domain socket本地套接字路径名写在文件系统上。它的效率远高于 TCP 回环因为省去了 TCP/IP 协议栈的开销。Nginx、MySQL、Redis 都支持用 Unix socket 做本地通信性能指标比 TCP 好不少。做技术选型时我的经验是命令行管道、脚本这种轻量协作用管道需要进程间传递控制消息、事件通知用信号要传大量数据、追求吞吐用共享内存进程间要解耦、异步排队、保证消息边界用消息队列跨机通信只有 socket。下面这张表可以帮你快速对号入座IPC 方式通信方向是否需要同步性能适用场景管道单向否中命令行、父子进程流式数据信号单向否高事件通知、控制命令共享内存双向是最高大数据量高频交互消息队列双向否中解耦、异步消息信号量控制信号是高互斥与同步不传数据Unix socket双向否高本机服务间通信多说一句 Electron 之类的桌面应用主进程和渲染进程之间 IPC 用的是 Chromium 内置的 IPC 通道底层还是本地管道或者 socket 这一类内核机制它和这里讲的概念是打通的你可以把它理解成框架帮你封装好了一套 IPC 工具。理解内核层的进程通信方案写上层应用框架的代码时也更容易读懂文档里那些message channel、port名词到底指什么。4.5 一个容易遗忘的 IPC文件锁与文件作为通讯渠道严格说文件不算正统 IPC但很多服务确实在用文件锁flock / fcntl 锁来实现互斥比如定期任务、单实例守护进程启动时独占锁一个路径拿不到锁说明已有实例在跑自己就退出。这种写法简单可靠、可读性极强比搞一个复杂的信号量方案更合适。同理进程间传小数据也可以约定写到一个临时文件里虽然性能差但调试排查非常直观因为你可以直接 cat 看内容。我的建议是生产环境不要滥用文件做 IPC但简单问题用简单方案这个原则永远值得记住。5. 调度的艺术CPU 时间片到底怎么分5.1 nice 值和优先级为什么有的进程响应快你在 ps 里看到的 NI 列就是 nice 值范围 -20 到 19数值越小进程优先级越高越容易被调度器照顾。PRpriority列则是动态优先级实际调度优先级受 nice 影响。启动一个进程时可以用nice -n -5 命令调低 nice 值让优先级高一点对一个已经在跑的进程用renice -n -5 PID调整。但普通用户有个限制只能调高自己的 nice 值比如把 nice 5 调到 10不能调负把优先级提上去否则人人都把自己的进程调到最高优先级系统公平性就没了。只有 root 才有资格调负值。这个设计背后是经典的资源配额哲学不能让用户互相抢资源。IO 密集型和 CPU 密集型进程对调度的需求完全不同。IO 密集进程大部分时间在等数据偶尔起来跑一点就继续等它希望自己被抢时间片时别太久否则输入输出延迟会很高CPU 密集进程则希望拿尽量长的时间片跑完计算。调度器要同时照顾这两类性格迥异的进程难度就在这里。5.2 CFS 调度器的核心思想现代 Linux 默认的调度器是 CFS完全公平调度核心思路不是每个进程轮流跑固定大小的时间片而是用一个虚拟运行时间 vruntime 来记账。每个进程都有 vruntime它按实际运行时间加权累计权重由 nice 值决定。调度器每次选择 vruntime 最小的进程来运行——谁的 vruntime 小说明谁被亏待得多就该让它多跑一会。这个设计是 O(log n) 的红黑树结构每次取最左节点就是 vruntime 最小的进程可扩展性很好。CFS 还设置了调度粒度CPU 密集型进程因为很少主动让出 CPU时间片值会被设得比较长IO 型进程经常主动让出调度器会尽快把它再唤醒。如果你感受到两台机器同样的代码、同样的负载一个交互响应丝滑一个卡顿很可能就是调度参数 cfs_period、cfs_quota 或者 cgroup 的 cpu 限流配置不一样。线上排查时可以用cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us这类文件查看容器的 CPU 配额配额打满了你配置的进程再高优先级也没用。5.3 绑核CPU 亲和性和 NUMA 感知现代多核服务器上一个进程在 CPU 核之间来回切换是有代价的缓存不热、TLB 失效、核间调度开销。taskset -c 2-3 命令可以把进程绑定到固定的 CPU 核上运行。查看进程当前亲和性用taskset -cp PID修改运行中的进程亲和性也用这个命令配合指定 CPU。绑核真正发威的场景是 NUMA 架构也就是多路服务器上每个 CPU 有自己的内存控制器访问本节点内内存比跨节点内存快得多。如果你跑的数据库、大内存业务不感知 NUMA内存可能分配在很远的内存控制器上延迟高一大截。很多大型数据库运维都会配合 numactl 做内存分配策略。什么时候该绑核、什么时候不能绑我的实操心得是数据库、消息队列这类延迟敏感、又对缓存命中率依赖很高的服务适合绑通用 Web 服务、很多异步非阻塞框架反而让调度器自由迁移更灵活绑死了反而容易浪费空闲核。5.4 Linux 的进程名限制与改名技巧进程名comm 字段在内核里只有 15 或者 16 个字节这是为什么你看到ps aux里 Java 启动脚本的名字只有 15 字符出头就被砍断了。每个程序的线程名也有长度限制。改名的场景通常是监控平台、进程管理脚本需要按名字识别进程但你的启动命令太长做不了精确匹配。最简单的方案是启动时用exec -a custom_name 命令给进程指定 argv[0] 的别名这样 ps 里显示成你要的名字。代码里要动态改名则用prctl(PR_SET_NAME, newname)比如 C 程序、Python 的 ctypes 调用 prctl 都可以改。改完 ps 和 top 显示的名字变了/proc/PID/cmdline里原始参数还在可以靠这个确认它到底是从哪个目录跑起来的。Java 那边还可以在 JVM 启动脚本里用-Djava.security.manager之类的方式配合 ps 命令做标记不过最清晰的还是给每个进程不同颜色的日志标识别指望进程名解决所有识别问题。6. 高频排查实录进程问题怎么一步步定位6.1 端口被占用8080 的锅到底谁来背开发时最常遇到的就是端口被占用。排查思路非常固定lsof -i:8080看谁占着 8080或者用ss -lntp | grep 8080更传统的方式是netstat -tlnp | grep 8080。lsof 胜在直接给出进程 PID 和进程名ss 是新版 iproute2 自带、不用额外装包。找到 PID 后看一眼这个进程是什么再决定动它。很多新手看到端口被占用就直接kill -9结果把别人机器上的生产服务干没了。正确做法是叠加ll /proc/PID/cwd和cat /proc/PID/cmdline确认进程身份再决定是停掉它还是换个端口。如果确实要按端口强杀fuser -k 8080/tcp可以用但慎用误杀成本很高。还有一个坑ss -lntp不带 sudo 看不到 PID因为进程名属于系统信息普通用户无权查看所有进程的细节。开机自启的进程你不知道由谁拉起的去翻 systemd 服务列表systemctl list-units | grep 你猜的服务名或者看 /proc 下面进程的父进程是谁顺藤摸瓜就能定位。6.2 CPU 飙高从进程到线程一步到位CPU 飚到 99%第一件事当然是 top 找到那个最耗 CPU 的 PID。但落在多线程程序上你看到的是进程整体占用具体是哪个线程在跑需要往下追一层。top -H -p PID能看到该进程下所有线程的 CPU 占用再配合ps -Lp PID也能看到线程列表。Java 程序还要进一步用jstack PID把线程的堆栈导出来跟线程 ID 对上号才能定位到代码行。定位思路再延伸perf top 和火焰图是分析 CPU 开销的神器。perf top 能直接看到当前热点函数复杂场景下用 perf record 采样一段时间再用火焰图脚本生成可视化页面一眼就能看出瓶颈在用户态还是内核态。这里我插一句经验很多 Java 项目 CPU 高的原因不是业务代码而是 GC 线程在疯狂回收或者线程池开太大了先看 GC 日志再查代码往往效率更高。6.3 内存占用高和进程泄漏线索用free -m看整体内存用ps aux --sort-%mem按内存排序找出大户。但进程内存高要区分是物理内存占用RSS还是虚拟内存占用VSZ和RSS别混淆。要看更细的分布pmap -x PID能列出每个内存段的大小排查泄漏时特别有用两个采样时间点之间的堆段大小持续增长基本可以判定是 C/C 堆泄漏。Java 应用的堆外内存一直是个让人头疼的话题。你调了多少 Xmx但实际 RSS 比 Xmx 大一大截很可能是 DirectBuffer、JNI 调用、线程栈、metaspace、GC 本身这些堆外区域在吃内存。排查时要先看cat /proc/PID/status里的 VmRSS、VmSwap再看jcmd PID GC.class_histogram或者开 Native Memory Tracking。有一个极端但常见的原因操作系统大量页缓存page cache把内存吃了free 显示 available 很低但应用其实不缺内存需要区分缓存和实际占用。6.4 进程秒退和起不来dmesg 和 ulimit 帮大忙服务进程一启动就消失第一反应不应该是去看应用日志先确认它是不是被内核杀了。dmesg | tail -50能看到 OOM killer 的痕迹杀掉进程时消息里会有 oom-kill、Out of memory 字样。如果真被 OOM 杀了解决方向有两个调大机器内存或者优化应用内存占用也可以调整 overcommit 策略。排除了 OOM再看资源限制。ulimit -a列出的 open files 文件描述符数量限制常见 1024、max user processes 进程数限制都是隐形杀手。文件句柄数超了进程可能报 Too many open files 直接崩溃进程数超了fork 不出来。修改方式临时用ulimit -n 65535持久化写到 /etc/security/limits.conf 或者 systemd 服务文件里的 LimitNOFILE。很多数据库和中间件生产部署文档都会要求把 nofile 调高到 65535 以上原因就在这里。还有一个秒退原因是当前用户对这些路径没有执行权限或者动态链接库缺失。排查用ldd /path/bin看依赖库在不在用ls -l看可执行权限用su - 应用用户 -c 命令模拟实际运行身份把报错复现出来这些都比瞎猜快。6.5 进程卡住不动和 D 状态的应对服务还能响应健康检查但业务请求全部堆着不动可能不是进程死了而是卡在了不可中断睡眠或者线程池全部阻塞。先看ps aux是不是大量 D 状态进程是的话检查底层磁盘/存储/网络是否异常参考第一节里讲的方法处理。如果只是线程全阻塞住用 top -H 或者 jstack 看线程栈是等锁还是等 IO。这里我提供一个百试百灵的排查顺序CPU 看 top内存看 free 和 psIO 看 iostat网络看 ss线程栈看 jstack/gdb。排查的次序对了问题就能定位到模块层面。6.6 systemd 和 journald现代服务进程的病历本最后再说一句 systemd。现在大多数发行版的服务都由 systemd 管理服务状态用systemctl status 服务名查日志用journalctl -u 服务名 -n 100看。进程反复重启systemctl status会显示 Active: failed 或者 Restartalways 导致的自动拉起次数配合 journalctl 的近期输出能快速看到崩溃前最后打印的错误。如果是退出码 137通常是进程被 SIGKILL 杀了可能是被 OOM、人为 kill 或者 systemd 的 StopTimeout 强制终止退出码 143 则对应 SIGTERM多半是外部主动终止或者关机流程。看到这些退出码再结合日志排查方向基本就锁定了。我个人在实际排查工作中进程相关的问题出现频率最高上面这些常规手段用了无数遍。工具永远在变但思路是稳定的先用 ps/top 定位进程在不在再看状态和资源占用最后顺着信号、日志、系统调用往下钻。最后再分享一个小技巧刚接手一台不熟悉的机器先跑一遍pstree -p、ps aux --sort-%cpu | head、free -m、df -h这四个命令基本就能摸清这台机器的健康情况。至于更深入的内核细节sched_debug、/proc 文件系统、perf 事件都是后续可以继续挖的方向——进程这口井很深但看完这篇你已经有了完整的地图。