我在新分配的项目中发现了一堆脚本，它们是“关闭”脚本。他们只是做一些基本的搜索并运行 Unix kill 命令。他们有什么理由不应该以这种方式关闭进程？这是否确保动态分配的内存将正确返回？还有其他负面影响吗？我的直觉是，这是终止进程的最后手段。
【问题讨论】：
标签： unix memory-management operating-system kill
kill 是程序结束的礼貌请求。它清理它的内存，关闭它的句柄和其他类似的细节。它发送一个 SIGTERM
kill -9 告诉操作系统抓住进程并把它扔出酒吧。显然它并不关心细节——尽管它确实回收了所有内存，因为它是操作系统的责任来跟踪它。但是因为它是强制关闭，所以在尝试再次运行程序时可能会遇到问题（例如不清理 .pid 文件）
【讨论】：
kill 只是向进程发送一个信号。该进程可以捕获信号（信号 9 除外）并运行代码以执行关闭。应用程序的关闭应该是短暂的，但可能不是瞬时的。
无论如何，一旦进程退出，操作系统将回收动态分配的内存，关闭打开的文件描述符和其他资源。
可能有一些资源仍然存在，例如，如果应用程序持有共享内存或套接字也被其他（仍然存在的）进程持有。
【讨论】：
kill 命令向 Unix 进程发送信号。该信号默认为 SIGTERM，这是程序退出的礼貌请求。
当进程因任何原因退出时，Unix 操作系统确实清理其内存分配、文件句柄和其他资源。唯一没有被清理的资源是那些应该被共享的资源，比如文件和共享内存的内容（比如 System V IPC）。
许多程序在退出时不需要做任何特殊的清理，并使用默认的 SIGTERM 行为，即让操作系统停止进程。
如果一个程序确实需要特殊行为，它可以安装一个信号处理程序，然后它可以运行一个函数来处理信号。
现在 SIGKILL 信号，即 9 号，是邪恶的，但也是必要的。这个信号永远不会到达进程本身，操作系统会简单地停止进程。这应该只在真正需要时使用。在陷入死锁的多线程程序或安装了 TERM 信号处理程序但在退出过程中搞砸的程序中，这通常变得必要。
【讨论】：
kill 默认情况下会发送一个终止信号，允许进程正常退出。如果进程似乎没有及时退出，那么一些脚本将退回到 kill -9 强制退出，“准备好与否”。
在所有情况下，操作系统管理的东西都将被返回，例如动态内存、文件关闭等。但应用程序级别的东西可能不会在 -9 杀戮时被整理。
【讨论】：
kill -9
是最后的手段，而不是kill。
【讨论】：
每个进程都在自己的受保护地址空间中运行，并且当进程结束时（无论是自愿退出还是被外部信号杀死），该地址空间都会被完全回收。所以是的，只要它的内存被正确释放。
根据进程，下次尝试运行它时可能会也可能不会导致其他问题。例如，如果它被意外终止，它可能会打开一些文件并使它们处于不一致的状态。 （文件会自动关闭，但可能是在写入一些应用程序数据的过程中，如果被中断，文件可能包含不完整/不一致的数据。）
通常当系统关闭时，所有进程都将收到信号 15 (SIGTERM)，在该信号中它们可以执行所需的任何清理/关闭操作。然后不久之后，他们将收到信号 9 (SIGKILL)，立即杀死他们，而没有给他们任何反应的机会。这使所有进程都有机会自行清理，然后强行终止任何未及时响应的进程。
【讨论】：