在软件的世界里，没有啥是一辈子完美的。
只要人类还在写逻辑代码，甭管运行在啥硬件上，总会在某个时刻搞错。
这时候，要是系统不“死机”要么“重启”，那才是最大的事故。
这种“在身上跳来跳去强行拉你回正轨”的机制，就叫软件看门狗。它不是来帮你做老板的，它只是来问一句：“老板，你最近累不累？还有没有停一停？” 想象一下你在做 SPA 项目，写了一个比较复杂的自动下单逻辑，逻辑跑通了，代码也编译通过了，部署到造环境。结局呢？半小时后，订单页面的按钮突然坏了，要么后台数据库突然变红，根本没法修。你慌了，下意识地要重启服务，结局重启后，那个“按钮坏了”的 bug 又回来了，就连可能出于重启害得数据丢失。
这时候，大量人会想，我是不是被系统卡住了，能不能重启？能不能看个监控脚本直接找到是哪个函数报错，然后修？ 实际上，不是的。 看门狗的本质，就是那个在代码里写死的、自动重启服务的小程序。它自己不干任何业务逻辑，它的唯一任务就是每过 30 秒（要么 1 分钟），去问一次：“我在哪？我跑得如何样了？”要是它发现这 30 秒里，系统没有形成它预设的“死机”状态，比如内存溢出、CPU 降频要么进程挂起，它就会立马跳出来，执行一次“重启服务”的命令。 这个重启动作，往往不是鼠标点一下，而是直接执行 shell 命令，杀掉进程，然后重新启动它。
这就好比你身体里突然冒出一只蚂蚁，你感觉不到，就当作它是虫子爬在地上，结局你赶紧去把虫子拔出来，它自己却还在不动。
看门狗就是那个在你感觉不到的时候，自动把坏掉的东西修好的人。 大量人对看门狗有误解，总当作它是个“监控器”，天天盯着屏幕上的红字报警。
实际上不然，看门狗是“盲干”的。它根本不需求知道代码里到底逻辑错在哪，也不用去分析变量值对不对，它只需求知道“服务没死”。
只要发现服务没死，它就得动手。 举个例子，有个做电商的同学，写了一个订单系统，逻辑写得挺完美，测试环境跑了好几次都没难题。结局上线后，一天后他发工资，发现系统崩溃了，发出来的价格不对，害得客户投诉。他去查监控，发现是数据库连接池满了，然后去查数据库，发现是某个定时任务出于线程池被占满而没执行完，害得主线程被卡死，整个进程挂起了。 他本来想手动重启，但重启了之后，发现那个“定时任务”的线程池被占满了，还是没死，还是没执行完。
这时候他当作看门狗罢工了，要么系统忒复杂根本没人能修好。但他发现看门狗实际上一直在，它每 15 秒问一次：“老板，你跑了吗？”系统说：“汇报了汇报，汇报了，我活着！”看门狗没死，它还在原地等着重启。 这时候，看门狗就会再次触发，执行重启。重启之后，服务又挂了。
看着看着，看门狗又报警了，手动重启，难题仍然。
这时候，智慧的同学启动用脚本，手动杀掉进程了。但难题是，杀掉进程了，它是不是又跑起来了？ 这就有点尴尬了。
要是让它自己重启，可能出于重启过程中的资源释放不及时，害得第二次重启就挂了。
要是手动重启，那忒累了。
这时候就需求引入一个更高级的工具，比如"Killer"进程，要么在代码里加一个“看门狗自提”的功能。 “看门狗自提”这个功能，就是让看门狗自己把自己杀掉，然后去重启别的进程。就像你帮老板买瓶水，水买回来了，老板不喝，你自己喝一口，然后跑去重启那个坏死的系统。 这时候，你就要小心了。
要是看门狗自己把自己杀死了，那你得自己把它给重启过来。但重启过之后，它又如何样？它是不是又挂掉了？
是不是又要被它自己重启？ 这就陷入死循环了。你发现，每次手动重启服务，看门狗就报警。它一直在报警，一直在重启。你越帮它，它越挂。 这时候，看门狗的智慧就体现出来了。
既然手动重启忒费事，并且好办搞砸，看门狗应当学会“自提”自己重启服务。它要是发现服务挂掉了，就自己把自己杀掉，然后去重启那个挂掉的服务。 这就好比老板突然晕倒了，你把他捞起来，把他哄好，然后自己去重启他。结局呢？他本来好了，你也哄好，结局把他自己杀了，重启服务时，他又不中了，你又要哄他，又要重启他。 故此，大量出色的看门狗实现，都是设计成这样子的：它有一个“自提”定时器。每过一段工夫，它就去检查一下，要是服务挂了，要么服务重启了，它就去把自己杀掉，然后去重启服务。 要是服务挂了，它自己重启，那就好，服务好了，它也不用管了。
要是服务没挂了，它自己重启，那就也是一种保护。它自己把自己重启了，说明系统状态可能不稳定，它先把自己杀掉，防止出于重启过程中的死循环害得系统彻底崩了。重启服务成功了，它再去重启服务，这时候它就在系统里“隐身”了，不再打扰业务。 这就给系统供给了一层动态的保护。它不是死的代码，它是活的。它会根据系统的状态，来拍板是帮忙重启，还是自己重启。 有些同学可能会问，那要是看门狗自己把自己重启了，它能不能自动去重启那个被它重启过的服务？这就涉及到看门狗的“自提”策略了。 一般这种策略有两种：一种是看门狗重启自己的与此同时，也重启了原本挂掉的服务。另一种是看门狗重启自己的与此同时，也重启了原本没挂掉但可能出于重启害得不稳定，要么可能出于重启害得其他进程出现难题，它可能会选择重启那个最依赖于它的服务。 比如，要是你的服务 A 依赖服务 B，服务 B 挂了，服务 A 挂了如何办？看门狗应当优先重启 B，要么 B 挂了之后，看门狗也应当去重启 A。 有时候，一个服务挂了，另一个服务也没挂。
这时候看门狗该如何处理？它可能只是好办地重启服务 A，至于服务 B 呢？它可能不管，要么也重启一下。
这取决于看门狗的配置文件要么实现逻辑。 有些看门狗实现会比较复杂，它会维护一个状态列表。它知道哪些服务是依赖的，哪些服务是独立的。
要是服务 A 挂了，它可能只重启 A，不管 B。
要是服务 B 挂了，它可能只重启 B，不管 A。 故此，看门狗策略的核心，就是“动态”和“智能”。它不是机械地每 30 秒就重启一次，而是根据系统的状态，来拍板啥时候重启。 要是系统挺稳定，看门狗可能每 1 分钟才重启一次。
要是系统不稳定，比如 CPU 时常降频，内存时常爆，它可能会每 15 秒就重启一次。 有些同学可能会问，看门狗重启忒频繁了，会不会害得系统更不稳定？ 这就是所谓的“看门狗自提”的代价。
看门狗自己重启了，系统确实变不稳定了。
故此，看门狗设计的时候，一般会寻思“看门狗自提”和“看门狗守护”的混合模式。 “看门狗守护”模式，就是看门狗负责重启自己。它自己重启了，系统稳定了，看门狗再重启自己。 “看门狗自提”模式，就是看门狗负责重启服务。它自己重启了，系统不稳定了，它负责重启服务。 这两种模式各有优劣。
看门狗守护模式，系统稳定，但看门狗可能出于重启忒频繁而害得系统更不稳定。
看门狗自提模式，系统不稳定，但看门狗能更好地保护系统。 故此，大量出色的系统，要么看门狗实现，会尝试把两者结合。既要有看门狗守护，也要有看门狗自提。 比如，一个看门狗程序，它每 30 秒自动重启一次服务。
要是重启时服务没挂，它自己就重启了，然后系统稳定，它又去重启一次。
要是重启时服务挂了，它自己就重启了，然后服务恢复，它再去重启一次。 这就是看门狗工作得最好的时候。它既没有挂掉，也没有害得系统崩溃。它一直在默默工作，守护着系统。 自然，这种动态机制也是会消耗资源的。
要是看门狗自己重启了服务，那它肯定是在消耗系统资源。
要是它自己重启次数忒多，那系统资源也会消耗忒多。
故此，看门狗的设计，一般也会寻思自己重启的阈值。 要是看门狗自己重启超过 10 次，它可能会暂停自己重启，转而由系统自动重启服务。
这样，看门狗就不必一直在重启了，系统也会自动重启服务。 总而言之，软件看门狗，就是一个在系统里不断问自己“我如何样？”的助手。它不关心业务逻辑，不关心代码如何写，它只关心服务活不活。
要是服务没活，它就把服务救活；要是服务活，它就去救自己。 它的工作方式，有时候挺像人生中的“看自己”。你问自己“我累不累？我健康吗？”要是状态不好，你就去休息。
要是状态好，你就去忙别的。你问自己的时候，往往不是为了求医治，而是为了给自己一个提醒。 故此，看门狗不是技术的先进与否，而是它的设计理念。它用一种好办、直接、动态的方式，守护着系统的稳定。 它不会说“系统挺稳定，你不用揪心”，它只会说“系统目前不健康，你快修一下”。
这种直白，可能就是它最精彩的地方。 在软件的世界里，没有完美的代码，只有不断被修正的过程。而看门狗，就是那个在系统崩溃前，第一个知道“我要崩溃了”的人。它用一种笨办法，却保证了系统的生存。
