java - Java 中默认的未捕获信号处理程序策略的基本原理是什么？

Question

关于一般异常的智慧以及特别是在 Java 中使用已检查异常与未检查异常的文章很多，但我感兴趣的是看到对将线程终止作为默认策略的决定的辩护应用程序终止的方式与 C++ 中的方式相同。这个选择对我来说似乎非常危险:程序员没有随机计划的某些情况会导致程序的某些部分在记录堆栈跟踪后死亡，但程序的其余部分士兵坚决继续，可能会出什么问题？我的直觉和经验表明，这里可能会出现很多问题，而默认策略是那种只能由有特定理由选择它的人专门选择的东西，那么这种策略的好处是什么这么大的缺点？我是否高估了风险？

编辑:根据目前的答案，我觉得我需要更加专注于对我所感知的危险的描述；我说的是使用多线程(例如在线程池中)更新共享状态的应用程序的情况。我知道此策略不会对单线程应用程序造成问题。

EDIT2:从对 Thread.stop() 方法为何被弃用的解释(可在此处找到:http://docs.oracle.com/javase/7/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html)中，您可以看出语言维护者意识到了这些风险。当线程由于未捕获的异常而意外终止时，也会出现完全相同的问题。他们一定是设计了 JVM，以便在线程终止时自动解锁所有监视器，这似乎是一个糟糕的实现选择；在监视器锁定时线程死掉应该表明整个程序应该死掉，因为替代方案几乎可以肯定是某些共享状态的内部不一致。

Answer 1

@BD，不确定您的经验对此有何看法，因为您尚未在此处进行解释。但是，这是我作为开发人员的经历:

1. 通常，如果应用程序的某个组件因任何原因(例如数据库重启或某些文件被替换)而失败(暂时或永久)，那么让应用程序失败是个坏主意。例如，如果我在系统中引入了一种新的交易类型，并且出现了一些问题，它不应该关闭我的应用程序。

2. Web/应用程序服务器等应用程序应该能够继续工作并响应用户，即使它的任何部署抛出任何奇怪的异常也是如此。

根据您对异常的担忧，通常所有应用程序都有一个健康监控系统来监控它们的健康状况，例如 CPU/磁盘/RAM 使用或日志中的错误等，并相应地发出警报。

我希望这能解决您的困惑。