kill -15 允许进程自主回收资源，保障数据一致性与连接正常终止；kill -9 由内核强制终止，跳过应用层清理，易致文件损坏、连接异常、数据丢失等副作用。
Linux 中 kill -15 和 kill -9 的本质区别，不在“是否能终止进程”，而在于操作系统是否允许进程参与资源回收过程。这个差异直接决定了文件是否损坏、连接是否异常中断、数据是否丢失等关键问题。
kill -15（SIGTERM）：进程自主完成资源释放
它向进程发送一个可被处理的终止请求信号。进程收到后，若已注册信号处理器，就会执行预设的退出逻辑：
- 关闭打开的文件描述符（如日志文件、数据库连接句柄）
- 将内存缓存中的数据刷写到磁盘（例如 Redis 的 RDB 保存、MySQL 的事务提交）
- 向子进程发送退出通知，并等待其结束（避免孤儿进程）
- 释放锁、清理临时文件、更新状态标记（如服务注册中心下线）
如果进程正阻塞在系统调用（如 read() 等待网络响应），它可能暂时不响应；但一旦恢复运行，仍会处理该信号。这也是为什么 kill -15 不保证立即退出，但能保障退出行为是可控和安全的。
kill -9（SIGKILL）：内核绕过进程，直接回收全部资源
该信号由内核强制介入，进程无法捕获、忽略或延迟处理。系统会立刻：
- 从调度队列中移除该进程，停止其所有 CPU 时间片分配
- 释放其占用的虚拟内存空间（包括未 flush 的 page cache）
- 关闭所有打开的文件描述符——但不触发文件系统级的写入完成动作
- 终止其所有线程，销毁线程本地存储（TLS）
这意味着：正在写入的文件可能截断、数据库事务回滚不完整、socket 连接突然断开（无 FIN 包）、共享内存未清理、信号量未释放。这些都属于非原子性中断带来的副作用，而非“资源没回收”——资源确实被回收了，只是回收过程跳过了应用层语义。
实际影响对比：以 Web 服务器为例
假设一个 Nginx 工作进程正在处理一个大文件上传请求：
- 用 kill -15：Nginx 主动关闭监听套接字，拒绝新连接；等待当前请求完成或超时后退出；临时上传文件被正常移动为最终文件
- 用 kill -9：进程瞬间消失；客户端收到 RST 包；临时上传文件残留且内容不全；worker 进程持有的共享内存页未归还，下次启动可能因校验失败拒绝加载配置
如何验证资源回收行为是否发生
不能只看进程是否消失，要检查系统级痕迹：
- 用 lsof -p PID 查看进程打开的文件句柄 —— kill -15 后应快速清空；kill -9 后该命令报错（进程不存在），但需额外检查是否有残留 inotify 或 eventfd 句柄未释放
- 用 ss -tulnp | grep PID 检查端口占用 —— kill -15 后端口通常几秒内释放；kill -9 后端口可能短暂处于 TIME_WAIT，但不会长期被占
- 观察磁盘日志：如 journalctl -u nginx.service，kill -15 一般有 “exiting gracefully” 类记录；kill -9 则无任何退出日志
不复杂但容易忽略：优雅退出不是“慢”，而是“可预期”；强制终止不是“快”，而是“不可控”。选哪个，取决于你愿不愿意为那几秒钟，承担后续排查两小时的风险。
