在生产应用程序中会导致哪个问题kill -9（确切地说是在 linux 中）？
我有做一些定期工作的应用程序，停止这些工作需要很长时间，而且我不在乎某些工作是否会中止 - 工作可以通过新流程完成。那么我可以kill -9立即停止它吗？否则会导致严重的操作系统问题？
例如，Unicorn，将其用作正常工作程序：
当您的应用程序出错时，BOFH 可以“杀死 -9”失控的工作进程，而不必担心会破坏所有客户端，只需一个。
但是这篇文章声称：
kill(1) 的 -9（或 KILL）参数永远不应该在 Unix 系统上使用
PS：我知道kill -9应用程序无法处理，但我知道对于可能的应用程序它不会造成任何问题，我只是想知道它会导致操作系统级别的一些问题吗？shared memory segments active, lingering sockets对我来说听起来很危险。
kill -9不会让应用程序有机会干净地关闭。
通常，应用程序可以捕获SIGINT/SIGTERM并干净地关闭（关闭文件、保存数据等）。应用程序无法捕获 a SIGKILL（与 a 一起发生kill -9），因此它无法进行任何此类（可选）清理。
更好的方法是使用标准kill，如果应用程序仍然无响应，则使用kill -9.
kill -9不会导致任何“严重的操作系统问题”。但是该过程将立即停止，这意味着它可能会使数据处于奇怪的状态。
这取决于它是什么类型的应用程序。
像数据库这样的东西可能会丢失数据（如果它没有一次将所有数据写入持久事务日志），或者下次启动需要更长的时间，或者两者兼而有之。
尽管Crash-only是一个很好的原则，但目前很少有应用程序符合它。
例如，mysql 数据库不是“仅崩溃”，使用 kill -9 杀死它会导致启动时间显着延长（比干净关闭）、数据丢失或两者兼而有之，具体取决于设置（在某种程度上， 运气）。
另一方面，Cassandra实际上鼓励使用 kill -9 作为关闭机制；它不支持其他任何东西。
应用程序无法捕获 KILL 信号。如果应用程序在您杀死它时正在将一些复杂的数据结构写入磁盘，则该结构可能只写入了一半，从而导致数据文件损坏。通常最好实现一些其他信号，例如 USER1 作为“停止”信号，因为它可以被捕获并允许应用程序以受控方式关闭。