一、前言
当我们的应用程序在 Java 层发生异常时，可以使用 Thread.setDefaultUncaughtExceptionHandler 来进行全局异常的捕获，这篇文章回答了下面四个问题：
- 在主进程中的主线程、子线程发生崩溃的表现？
- UncaughtExceptionHandler 是由谁调用的？
- 为什么同样都是捕获了异常，主线程会出现异常或者无法响应，而子线程依然可以正常后续的操作？
- 不设置 UncaughtExceptionHandler 时，系统默认的处理逻辑是什么？
二、现象
首先在 Application 中设置：
class ClientApplication: Application() {
companion object {
val TAG: String = ClientApplication::class.java.name
}
override fun onCreate() {
super.onCreate()
Thread.setDefaultUncaughtExceptionHandler {
thread, e -> Log.d(TAG, "thread=" + thread.id + ",throwable=" + e.message)}
}
}
2.1 主进程 + 主线程
class ClientActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
findViewById<Button>(R.id.bt).setOnClickListener {
mainException()
}
}
private fun mainException() {
val exception: String? = null
exception!!.length
}
}
点击按钮触发空指针异常后，程序没有立即退出，而是先打印了空指针的异常：
D/com.lee.clientapplication.ClientApplication: thread=2,throwable=null
但是我们点击屏幕并没有任何的反馈，最终还是抛出了应用出错的提醒。
2.2 主进程 + 子线程
class ClientActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
findViewById<Button>(R.id.bt).setOnClickListener {
threadException()
}
}
private fun threadException() {
thread {
val exception: String? = null
exception!!.length
}
}
}
现在我们在子线程当中触发空指针的异常，在这种情况下，仍然可以看到全局捕获的打印，但是用户仍然可以和页面进行交互：
2021-03-08 13:16:55.015 9516-9673/com.lee.clientapplication D/com.lee.clientapplication.ClientApplication: thread=8879,throwable=null
而假如我们去掉了 Application 中对于异常的全局捕获，那么程序还是会崩溃的。
三、UncaughtExceptionHandler 由谁触发的
我们可以看下官方文档对于这个函数的解释：
Interface for handlers invoked when a Thread abruptly terminates due to an uncaught exception.
When a thread is about to terminate due to an uncaught exception the Java Virtual Machine will query the thread for its UncaughtExceptionHandler using Thread.getUncaughtExceptionHandler() and will invoke the handler's uncaughtException method, passing the thread and the exception as arguments. If a thread has not had its UncaughtExceptionHandler explicitly set, then its ThreadGroup object acts as its UncaughtExceptionHandler. If the ThreadGroup object has no special requirements for dealing with the exception, it can forward the invocation to the default uncaught exception handler.
当一个线程即将因不受捕获的异常即将终止时，JVM 尝试会使用 Thread.getUncaughtExceptionHandler() 方法获得该线程的 UncaughtExceptionHandler 对象并调用其 uncaughtException 方法，其参数为该线程和异常信息。如果没有设置，那么 ThreadGroup 将会作为默认的 UncaughtExceptionHandler，如果 ThreadGroup 也没有处理，那么会采用 default uncaught exception handler。
由此可见 UncaughtExceptionHandler 是由虚拟机通过 dispatchUncaughtException 触发的，调用链为：
- UncaughtExceptionHandler：线程的成员变量，如果没有设置 UncaughtExceptionHandler，那么会调用 group 成员处理。
public class Thread implements Runnable {
public UncaughtExceptionHandler getUncaughtExceptionHandler() {
return uncaughtExceptionHandler != null ?
uncaughtExceptionHandler : group;
}
public final void dispatchUncaughtException(Throwable e) {
getUncaughtExceptionHandler().uncaughtException(this, e);
}
}
- ThreadGroup：group 也是实现了 UncaughtExceptionHandler 接口，内部逻辑是先委托其 parent 处理，直到 parent 为空时，最终 parent 为空时才会走到调用 sDefaultUncaughtExceptionHandler。
public class ThreadGroup implements Thread.UncaughtExceptionHandler {
public void uncaughtException(Thread t, Throwable e) {
if (parent != null) {
parent.uncaughtException(t, e);
} else {
Thread.UncaughtExceptionHandler ueh =
Thread.getDefaultUncaughtExceptionHandler();
if (ueh != null) {
ueh.uncaughtException(t, e);
} else if (!(e instanceof ThreadDeath)) {
System.err.print("Exception in thread \""
+ t.getName() + "\" ");
e.printStackTrace(System.err);
}
}
}
}
- sDefaultUncaughtExceptionHandler：线程的静态成员变量，用于处理该进程中的所有线程，也就是我们在上一部分所举的例子。
这里解释一下：
- 对于子线程来说，其 ThreadGroup 为主线程 [name=main, maxpri=10]
- 主线程的 parent 也是一个 ThreadGroup [name=system, maxpri=10]，其 parent 为 null。
流程图如下：
四、为什么主线程会出现无法响应，而子线程不会
首先我们要知道应用程序和系统间的交互基于的是 消息驱动 的模型：
- 事件源通过 Binder 调用传递到应用程序进程后，会将处理的消息加入到消息队列当中，例如按键、触摸、绘制等。
- 应用程序再不断地从消息队列中取出消息进行处理。
应用程序是在其主线程进行处理这些消息的，这里是通过一个无限循环，即 Looper.loop()，没有消息时休眠，有消息时被唤醒去处理消息，因此主线程不能够结束，结束了就没法处理消息了。
即 ActivityThread.main 方法：
public static void main(String[] args) {
Looper.prepareMainLooper();
Looper.loop();
throw new RuntimeException("Main thread loop unexpectedly exited");
}
由于主线程结束了，那么就无法及时处理 AMS/WMS 发送的消息或者给予反馈，就会触发系统调用错误或者 ANR。
而子线程由于不涉及这些，结束就结束了，和任务执行完了没什么区别，因此也就不会产生异常。
无、默认的处理规则
假如我们没有设置自定义的 handler，那么系统是有自己一套默认的处理逻辑的，这段代码在应用进程启动时，即 RuntimeInit#commonInit 中：
protected static final void commonInit() {
LoggingHandler loggingHandler = new LoggingHandler();
RuntimeHooks.setUncaughtExceptionPreHandler(loggingHandler);
Thread.setDefaultUncaughtExceptionHandler(new KillApplicationHandler(loggingHandler));
}
KillApplicationHandler 会通过 Binder 调用到 AMS 端进行异常信息的记录，最后会调用 Process.killProcess(Process.myPid()) & System.exit(10) 结束掉应用进程，这也是为什么在没有设置自定的 handler 情况下，子线程当中发生异常会导致应用程序退出。
