进程、线程与作业#

进程拥有地址空间等资源，线程是进程内的执行单元，通常共享这些资源。PID 标识进程，PPID 指向父进程，TID 标识线程；标识可能被复用，操作前应核对启动时间与命令。

Shell 的作业是它跟踪的一条命令或流水线，可以包含多个进程。jobs 只显示当前 Shell 管理的作业，不是全系统进程清单。

查找与观察进程#

1
ps -eo pid,ppid,user,stat,etime,%cpu,%mem,args --sort=-%cpu
2
pgrep -a -x nginx

pgrep -x 按进程名精确匹配；应用可能修改进程名，必要时再检查命令行、可执行文件与服务归属。ps 的 CPU 百分比通常基于进程生命周期统计，与 top 的采样区间含义不同。

前台、后台与退出状态#

以下示例只操作自己新建的 sleep 进程：

1
sleep 30 &
2
task_pid=$!
3
jobs -l
4
ps -p "$task_pid" -o pid,stat,args
5
wait "$task_pid"
6
printf '退出状态：%s\n' "$?"

& 启动后台任务，$! 保存最近一个后台任务的 PID，wait 等待它退出并返回状态。后台不等于脱离终端；任务是否会在断线后继续，取决于终端、Shell 和信号处理。

需要重连交互会话可使用 tmux；需要长期运行、自动重启和开机启动则使用服务管理器。

信号与服务生命周期#

处理 systemd 服务应优先使用服务接口，例如：

1
systemctl status nginx
2
sudo systemctl stop nginx
3
systemctl is-active nginx
4
journalctl -u nginx --since "10 minutes ago"

示例要求系统确实安装该服务。停止后还要确认监听端口和相关任务是否消失；服务可能由 socket、定时器或其他单元再次激活。

对于独立进程，先核对 PID、属主、启动时间和命令，再发 TERM，等待业务允许的退出时间。仅在确认不能正常退出、已评估未写入数据和锁的影响后考虑 KILL。不要用名称模糊匹配批量终止进程。

资源判断与优先级#

nice 和 renice 调整普通调度策略下的相对优先级，不是 CPU 使用率上限。资源配额更适合通过 systemd/cgroup 配置，并在变更后观察业务延迟。

进程间通信#

排障时先确认通信端点、访问权限、队列是否积压和对端是否存活。只有需要开发或分析内部行为时，才需要展开具体系统调用。

参考资料#

• ps(1)
• signal(7)
• Bash：作业控制
• systemctl 手册