JVM处理未捕获异常的方法详解

前言

继之前的文章详解JVM如何处理异常,今天再次发布一篇比较关联的文章,如题目可知,今天聊一聊在JVM中线程遇到未捕获异常的问题,其中涉及到线程如何处理未捕获异常和一些内容介绍。

什么是未捕获异常

未捕获异常指的是我们在方法体中没有使用try-catch捕获的异常,比如下面的例子

private static void testUncaughtException(String arg) {
 try {
 System.out.println(1 / arg.length());
 } catch (ArithmeticException e) {
 e.printStackTrace();
 }
}

上面的代码很有可能发生如下情况

  • 如果方法参数arg传递null,会出现NullPointerException
  • 如果参数arg传递内容为空的字符串(“”),会出现ArithmeticException

对于上面的问题,我们不难发现

  • 上面可能出现的NullPointerException和ArithmeticException都属于Unchecked Exceptions
  • 而ArithmeticException被我们人为try-catch捕获了,它不符合本文对于未捕获异常的定义
  • NullPointerException 由于我们没有catch住,就变成了我们要聊的未捕获异常
  • 另外,未捕获异常实际是Unchecked Exceptions的子集

UncaughtExceptionHandler 是什么

  • 它是线程遇到未捕获异常的一个处理者接口
  • 它包含一个方法void uncaughtException(Thread t, Throwable e); 用来处理接收处理异常发生后的操作,比如收集崩溃信息并上报等
  • 可以通过 实例方法 Thread.setUncaughtExceptionHandler 为某一个Thread实例设置未捕获异常处理者
  • 也可以通过 静态方法 Thread.setDefaultUncaughtExceptionHandler 设置所有Thread实例的未捕获异常处理者

ThreadGroup 是什么

  • ThreadGroup 是线程的集合
  • ThreadGroup 也可以包含子ThreadGroup
  • 除了初始的ThreadGroup 之外,每个ThreadGroup都有一个父 ThreadGroup
  • ThreadGroup 自身实现了Thread.UncaughtExceptionHandler,用来相应处理其内部的线程和ThreadGroup发生未捕获异常。

未捕获异常处理者 设置指南

线程发生了未捕获异常,JVM怎么处理

分发Throwable实例

当线程A中出现了未捕获异常时,JVM会调用线程A的dispatchUncaughtException(Throwable)方法

/**
 * Dispatch an uncaught exception to the handler. This method is
 * intended to be called only by the JVM.
 */
private void dispatchUncaughtException(Throwable e) {
 getUncaughtExceptionHandler().uncaughtException(this, e);
}

获取未捕获异常处理者

每个线程会有一个变量(uncaughtExceptionHandler)来保存未捕获异常的处理者

在线程需要确定Throwable分发目标的处理者时,优先获取当前线程中uncaughtExceptionHandler变量

如果出问题线程的uncaughtExceptionHandler为null(即没有显式设置异常处理者),则使用自己所在的ThreadGroup来作为未捕获异常处理者。

/**
 * Returns the handler invoked when this thread abruptly terminates
 * due to an uncaught exception. If this thread has not had an
 * uncaught exception handler explicitly set then this thread's
 * <tt>ThreadGroup</tt> object is returned, unless this thread
 * has terminated, in which case <tt>null</tt> is returned.
 * @since 1.5
 * @return the uncaught exception handler for this thread
 */
public UncaughtExceptionHandler getUncaughtExceptionHandler() {
 return uncaughtExceptionHandler != null ?
 uncaughtExceptionHandler : group;
}

如果Throwable分发给ThreadGroup

  • ThreadGroup会尝试转给它的父ThreadGroup(如果存在的话)
  • 如果上面没有找到对应的ThreadGroup,则尝试获取Thread.getDefaultUncaughtExceptionHandler()并分发
/**
 * Called by the Java Virtual Machine when a thread in this
 * thread group stops because of an uncaught exception, and the thread
 * does not have a specific {@link Thread.UncaughtExceptionHandler}
 * installed.
 * <p>
 * The <code>uncaughtException</code> method of
 * <code>ThreadGroup</code> does the following:
 * <ul>
 * <li>If this thread group has a parent thread group, the
 * <code>uncaughtException</code> method of that parent is called
 * with the same two arguments.
 * <li>Otherwise, this method checks to see if there is a
 * {@linkplain Thread#getDefaultUncaughtExceptionHandler default
 * uncaught exception handler} installed, and if so, its
 * <code>uncaughtException</code> method is called with the same
 * two arguments.
 * <li>Otherwise, this method determines if the <code>Throwable</code>
 * argument is an instance of {@link ThreadDeath}. If so, nothing
 * special is done. Otherwise, a message containing the
 * thread's name, as returned from the thread's {@link
 * Thread#getName getName} method, and a stack backtrace,
 * using the <code>Throwable</code>'s {@link
 * Throwable#printStackTrace printStackTrace} method, is
 * printed to the {@linkplain System#err standard error stream}.
 * </ul>
 * <p>
 * Applications can override this method in subclasses of
 * <code>ThreadGroup</code> to provide alternative handling of
 * uncaught exceptions.
 *
 * @param t the thread that is about to exit.
 * @param e the uncaught exception.
 * @since JDK1.0
 */
 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);
  }
 }
 }

将上面的处理流程做成图的形式,就是下图所示

注:上述图片来自https://www.javamex.com/tutorials/exceptions/exceptions_uncaught_handler.shtml

Questions

初始的ThreadGroup是什么

上面提到了初始的ThreadGroup没有父ThreadGroup,是主线程所在的ThreadGroup么?

这个问题,我们可以通过这样一段代码验证

private static void dumpThreadGroups() {
 ThreadGroup threadGroup = Thread.currentThread().getThreadGroup();
 while(threadGroup != null) {
 System.out.println("dumpThreadGroups threadGroup=" + threadGroup.getName());
 threadGroup = threadGroup.getParent();
 }
}

执行该方法对应的输出是

dumpThreadGroups threadGroup=main
dumpThreadGroups threadGroup=system

因此我们可以发现,初始的ThreadGroup是一个叫做system的ThreadGroup,而不是main ThreadGroup

setDefaultUncaughtExceptionHandler 设置的一定会被调用到么

这其实是一个很好的问题,答案是不一定会被调用,因为可能存在以下的情况

  • 出问题的线程设置了对应的UncaughtExcpetionHandler,优先响应分发到这个Handler
  • 出问题的线程所在的ThreadGroup包括其祖先ThreadGroup 重写了uncaughtException 也可能造成线程默认的Handler无法被调用
  • 出问题的线程重写了dispatchUncaughtException 可能性较小
  • 出问题的线程重写了getUncaughtExceptionHandler 可能性较小

参考声明

How uncaught exceptions are handled

总结

以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,如果有疑问大家可以留言交流,谢谢大家对我们的支持。

(0)

相关推荐

  • JVM:早期(编译期)优化的深入理解

    早期(编译期)优化 JVM的编译器可以分为三个编译器: 前端编译器:把*.java转变为*.class的过程.如Sun的Javac.Eclipse JDT中的增量式编译器(ECJ) JIT编译器:把字节码转变为机器码的过程,如HotSpot VM的C1.C2编译器 AOT编译器:静态提前编译器,直接将*.java文件编译本地机器代码的过程 本章的后续文字里,"编译期"和"编译器"都仅限于第一类编译过程 1.Javac编译器 Javac编译器本身就是一个由Java语言

  • JVM中的守护线程示例详解

    前言 在Java中有两类线程:User Thread(用户线程).Daemon Thread(守护线程) 用个比较通俗的比如,任何一个守护线程都是整个JVM中所有非守护线程的保姆: 只要当前JVM实例中尚存在任何一个非守护线程没有结束,守护线程就全部工作:只有当最后一个非守护线程结束时,守护线程随着JVM一同结束工作. Daemon的作用是为其他线程的运行提供便利服务,守护线程最典型的应用就是 GC (垃圾回收器),它就是一个很称职的守护者. 在之前的<详解JVM如何处理异常>提到了守护线程,

  • JVM:晚期(运行期)优化的深入理解

    晚期(运行期)优化 在部分的商用虚拟机中,Java程序最初是通过解释器进行解释执行的,当虚拟机发现某个方法或代码块的运行特别频繁时,就会把这些代码认定为热点代码.为了提高热点代码的执行效率,在运行时,虚拟机会将这些代码编译成与本地平台相关的机器码,并进行各种层次的优化,完成这个任务的编译器称为即时编译器 本章提到的编译器.即时编译器都是指HotSpot虚拟机内的即时编译器,虚拟机也是特质HotSpot虚拟机 1.HotSpot虚拟机内的即时编译器 1).解释器与编译器 当程序需要迅速启动和执行的

  • JVM指令的使用深入详解

    一.未归类系列A 此系列暂未归类. 指令码    助记符                            说明 0x00         nop                                什么都不做 0x01        aconst_null                   将null推送至栈顶 二.const系列 该系列命令主要负责把简单的数值类型送到栈顶.该系列命令不带参数.注意只把简单的数值类型送到栈顶时,才使用如下的命令. 比如对应int型才该方式只能把

  • 详解Java虚拟机(JVM)运行时

    JVM(Java虚拟机)是一个抽象的计算模型.就如同一台真实的机器,它有自己的指令集和执行引擎,可以在运行时操控内存区域.目的是为构建在其上运行的应用程序提供一个运行环境.JVM可以解读指令代码并与底层进行交互:包括操作系统平台和执行指令并管理资源的硬件体系结构.本文主要介绍Java虚拟机(JVM)运行时详解. 我们知道的JVM内存区域有:堆和栈,这是一种泛的分法,也是按运行时区域的一种分法,堆是所有线程共享的一块区域,而栈是线程隔离的,每个线程互不共享. 线程不共享区域 每个线程的数据区域包括

  • JVM进阶教程之字段访问优化浅析

    前言 在实际中,Java程序中的对象或许 本身就是逃逸 的,或许因为 方法内联不够彻底 而被即时编译器 当成是逃逸 的,这两种情况都将 导致即时编译器 无法进行标量替换 ,这时,针对对象字段访问的优化显得更为重要. static int bar(Foo o, int x) { o.a = x; return o.a; } 对象o是传入参数, 不属于逃逸分析的范围 (JVM中的逃逸分析针对的是 新建对象 ) 该方法会将所传入的int型参数x的值存储至实例字段Foo.a中,然后再读取并返回同一字段的

  • 详解JVM 运行时内存使用情况监控

    java 语言, 开发者不能直接控制程序运行内存, 对象的创建都是由类加载器一步步解析, 执行与生成与内存区域中的; 并且jvm有自己的垃圾回收器对内存区域管理, 回收; 但是我们已经可以通过一些工具来在程序运行时查看对应的jvm内存使用情况, 帮助更好的分析与优化我们的代码; 注: 查看系统里java进程信息 // 查看当前机器上所有运行的java进程名称与pid(进程编号) jps -l // 显示指定的jvm进程所有的属性设置和配置参数 jinfo pid 1 . jmap : 内存占用情

  • java JVM原理与常识知识点

    JVM是Java Virtual Machine(Java虚拟机)的缩写,JVM是一种用于计算设备的规范,它是一个虚构出来的计算机,是通过在实际的计算机上仿真模拟各种计算机功能来实现的.Java虚拟机包括一套字节码指令集.一组寄存器.一个栈.一个垃圾回收堆和一个存储方法域. JVM屏蔽了与具体操作系统平台相关的信息,使Java程序只需生成在Java虚拟机上运行的目标代码(字节码),就可以在多种平台上不加修改地运行.JVM在执行字节码时,实际上最终还是把字节码解释成具体平台上的机器指令执行. 1.

  • 浅析JVM逃逸的原理及分析

    我们都知道Java中的对象默认都是分配到堆上,在调用栈中,只保存了对象的指针.当对象不再使用后,需要依靠GC来遍历引用树并回收内存.如果堆中对象数量太多,回收对象还有整理内存,都会会带来时间上的消耗,GC表示压力很大,然后影响性能.所以,在我们日常开发中,内存,时间都是相当的宝贵,该如何优化堆栈开销,是一个比较重要的问题. 在这里,我以逃逸分析角度聊聊JVM优化的那些事儿. 为什么"逃逸" 在计算机语言编译器优化原理中,逃逸分析是指分析指针动态范围的方法,它同编译器优化原理的指针分析和

  • JVM如何处理异常深入详解

    前言 无论你是使用何种编程语言,在日常的开发过程中,都会不可避免的要处理异常.今天本文将尝试讲解一些JVM如何处理异常问题,希望能够讲清楚这个内部的机制,如果对大家有所启发和帮助,则甚好. 当异常不仅仅是异常 我们在标题中提到了异常,然而这里指的异常并不是单纯的Exception,而是更为宽泛的Throwable.只是我们工作中习以为常的将它们(错误地)这样称谓. 关于Exception和Throwable的关系简单描述一下 Exception属于Throwable的子类,Throwable的另

随机推荐