Linux下运行的程序偶尔会毫无征兆地退出，终端只留下「Segmentation fault」或者没有任何提示，后台服务就此中断。理解进程崩溃背后的机制，才能从根源上解决问题，而不是每次靠重启掩盖故障。
一、进程崩溃的常见信号来源
当进程被迫终止时，通常是因为收到了某些致命信号。最常见的有SIGSEGV（段错误，编号11）、SIGABRT（中止，编号6）、SIGKILL（强制杀死，编号9）以及内核触发的OOM Killer行为。SIGSEGV一般源于非法内存访问，例如解引用空指针或越界写数组；SIGABRT多由调用abort()或断言失败引起；SIGKILL则往往是运维手动操作或系统资源耗尽时OOM Killer所为。
了解信号类型有助于缩小排查范围。可以用如下简单代码模拟段错误，观察进程退出时的表现：
#include <iostream>
int main() {
int* p = nullptr;
// 故意解引用空指针，触发SIGSEGV
std::cout << *p << std::endl;
return 0;
}
编译运行后，shell通常会打印「Segmentation fault (core dumped)」，如果系统未开启core dump，则括号内不会显示core dumped字样，这会给后续分析带来不便。
二、利用core dump还原崩溃现场
core dump是进程在收到致命信号时，由内核将其内存映像写入磁盘的文件。默认情况下，很多发行版通过ulimit禁用了core文件生成。我们需要先放开限制：
# 查看当前core文件大小限制 ulimit -c # 设置为不限制 ulimit -c unlimited # 指定core文件命名格式 echo "/tmp/core-%e-%p-%t" > /proc/sys/kernel/core_pattern
配置完成后再次运行有问题的程序，便能在/tmp下找到core文件。接着使用gdb加载二进制与core文件：
gdb ./your_program /tmp/core-your_program-1234-1700000000 # 进入gdb后查看调用栈 (gdb) bt
通过回溯栈帧，可以精确定位到发生崩溃的函数与代码行。对于已部署的服务，建议在启动脚本中统一设置ulimit，并将core_pattern指向专用目录，方便集中收集。
三、系统层面辅助排查工具
除了core dump，dmesg和strace也是常用手段。dmesg可以查看内核日志，OOM Killer杀死进程的记录会出现在其中：
dmesg | grep -i "killed process"
如果看到类似「Out of memory: Killed process 2345 (java)」的条目，说明是内存不足导致。此时应从调整JVM堆大小、优化程序内存占用或增加交换分区入手。
strace则用于跟踪系统调用，适合排查进程启动即崩溃或卡死的情况：
strace -f -o /tmp/trace.log ./your_program
在日志中观察进程最后调用的函数，常能发现试图访问不存在的文件、错误的socket连接等线索。不过strace会带来明显性能开销，生产环境应短时开启。
四、动态库与线程竞态问题
另一种隐蔽的崩溃来自动态库版本错配。当程序编译时链接了某一版本的so文件，而运行环境安装了不兼容的新版，就可能因符号缺失或结构体布局变化而崩溃。用ldd检查依赖是一种好习惯：
ldd ./your_program
若输出中有「not found」项，需安装对应开发包或设置LD_LIBRARY_PATH。多线程程序中，未加锁的共享变量修改也会引发竞态，表现为偶发崩溃。此时可借助ThreadSanitizer编译检测：
g++ -fsanitize=thread -g -o app app.cpp ./app
该工具会在竞态发生时输出详细冲突位置，比反复试错高效得多。
五、守护与自愈方案
对于必须长期运行的服务，除了修复代码，还应建立守护机制。用systemd管理进程时，可在单元文件中配置自动重启：
[Service] ExecStart=/opt/app/run.sh Restart=on-failure RestartSec=5 MemoryMax=512M
上述配置表示进程异常退出后等待5秒重启，并限制最大内存防止拖累整机。配合监控脚本定期检测端口存活，能够显著降低崩溃带来的业务影响。归根结底，崩溃不可怕，建立从信号认知、现场保留到工具定位的完整链条，才是稳健运维的核心。