文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

Java线程的异常处理机制详情

2024-04-02 19:55

关注

前言

启动一个Java程序,本质上是运行某个Java类的main方法。我们写一个死循环程序,跑起来,然后运行jvisualvm进行观察

可以看到这个Java进程中,一共有11个线程,其中10个守护线程,1个用户线程。我们main方法中的代码,就跑在一个名为main的线程中。当Java进程中跑着的所有线程都是守护线程时,JVM就会退出

在单线程的场景下,如果代码运行到某个位置时抛出了异常,会看到控制台打印出异常的堆栈信息。但在多线程的场景下,子线程中发生的异常,不一定就能及时的将异常信息打印出来。

我曾经在工作中遇到过一次,采用CompletableFuture.runAsync异步处理耗时任务时,任务处理过程中出现异常,然而日志中没有任何关于异常的信息。时隔许久,重新温习了线程中的异常处理机制,加深了对线程工作原理的理解,特此记录。

线程的异常处理机制

我们知道,Java程序的运行,是先经由javac将Java源代码编译成class字节码文件,然后由JVM加载并解析class文件,随后从主类的main方法开始执行。当一个线程在运行过程中抛出了未捕获异常时,会由JVM调用这个线程对象上的dispatchUncaughtException方法,进行异常处理。

// Thread类中
private void dispatchUncaughtException(Throwable e) {
        getUncaughtExceptionHandler().uncaughtException(this, e);
}

源码很好理解,先获取一个UncaughtExceptionHandler异常处理器,然后通过调用这个异常处理器的uncaughtException方法来对异常进行处理。(下文用缩写ueh来表示UncaughtExceptionHandler

ueh是个 啥呢?其实就是定义在Thread内部的一个接口,用作异常处理。

    @FunctionalInterface
    public interface UncaughtExceptionHandler {
        
        void uncaughtException(Thread t, Throwable e);
    }

再来看下Thread对象中的getUncaughtExceptionHandler方法

	public UncaughtExceptionHandler getUncaughtExceptionHandler() {
        return uncaughtExceptionHandler != null ?
            uncaughtExceptionHandler : group;
    }

先查看当前这个Thread对象是否有设置自定义的ueh对象,若有,则由其对异常进行处理,否则,由当前Thread对象所属的线程组(ThreadGroup)进行异常处理。我们点开源码,容易发现ThreadGroup类本身实现了Thread.UncaughtExceptionHandler接口,也就是说ThreadGroup本身就是个异常处理器。

public class ThreadGroup implements Thread.UncaughtExceptionHandler {
    private final ThreadGroup parent;
    ....
}

假设我们在main方法中抛出一个异常,若没有对main线程设置自定义的ueh对象,则交由main线程所属的ThreadGroup来处理异常。我们看下ThreadGroup是怎么处理异常的:

    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);
            }
        }
    }

这部分源码也比较简短。首先是查看当前ThreadGroup是否拥有父级的ThreadGroup,若有,则调用父级ThreadGroup进行异常处理。否则,调用静态方法Thread.getDefaultUncaughtExceptionHandler()获取一个默认ueh对象。

默认ueh对象不为空,则由这个默认的ueh对象进行异常处理;否则,当异常不是ThreadDeath时,直接将当前线程的名字,和异常的堆栈信息,通过标准错误输出System.err)打印到控制台。

我们随便运行一个main方法,看一下线程的情况

可以看到,main线程属于一个同样名为mainThreadGroup,而这个mainThreadGroup,其父级ThreadGroup名为system,而这个systemThreadGroup,没有父级了,它就是根ThreadGroup

由此可知,main线程中抛出的未捕获异常,最终会交由名为systemThreadGroup进行异常处理,而由于没有设置默认ueh对象,异常信息会通过System.err输出到控制台。

接下来,我们通过最朴素的方式(new一个Thread),在main线程中创建一个子线程,在子线程中编写能抛出异常的代码,进行观察

    public static void main(String[] args)  {
        Thread thread = new Thread(() -> {
            System.out.println(3 / 0);
        });
        thread.start();
    }

子线程中的异常信息被打印到了控制台。异常处理的流程就是我们上面描述的那样。

小结

所以,正常来说,如果没有对某个线程设置特定的ueh对象;也没有调用静态方法Thread.setDefaultUncaughtExceptionHandler设置全局默认ueh对象。那么,在任意一个线程的运行过程中抛出未捕获异常时,异常信息都会被输出到控制台(当异常是ThreadDeath时则不会进行输出,但通常来说,异常都不是ThreadDeath,不过这个细节要注意下)。

如何设置自定义的ueh对象来进行异常处理?根据上面的分析可知,有2种方式

当然,由于ThreadGroup本身可以充当ueh,所以其实还可以实现一个ThreadGroup子类,重写其uncaughtException方法进行异常处理。

若一个线程没有进行任何设置,当在这个线程内抛出异常后,默认会将线程名称和异常堆栈,通过System.err进行输出。

线程的异常处理机制,用一个流程图表示如下:

线程池场景下的异常处理

在实际的开发中,我们经常会使用线程池来进行多线程的管理和控制,而不是通过new来手动创建Thread对象。

对于Java中的线程池ThreadPoolExecutor,我们知道,通常来说有两种方式,可以向线程池提交任务:

其中execute方法没有返回值,我们通过execute提交的任务,只需要提交该任务给线程池执行,而不需要获取任务的执行结果。而submit方法,会返回一个Future对象,我们通过submit提交的任务,可以通过这个Future对象,拿到任务的执行结果。

我们分别尝试如下代码:

    public static void main(String[] args)  {
        ExecutorService threadPool = Executors.newSingleThreadExecutor();
        threadPool.execute(() -> {
            System.out.println(3 / 0);
        });
    }
    public static void main(String[] args)  {
        ExecutorService threadPool = Executors.newSingleThreadExecutor();
        threadPool.submit(() -> {
            System.out.println(3 / 0);
        });
    }

容易得到如下结果:

通过execute方法提交的任务,异常信息被打印到控制台;通过submit方法提交的任务,没有出现异常信息。

我们稍微跟一下ThreadPoolExecutor的源码,当使用execute方法提交任务时,在runWorker方法中,会执行到下图红框的部分

在上面的代码执行完毕后,由于异常被throw了出来,所以会由JVM捕捉到,并调用当前子线程dispatchUncaughtException方法进行处理,根据上面的分析,最终异常堆栈会被打印到控制台。

多扯几句别的。

上面跟源码时,注意到WorkerThreadPoolExecutor的一个内部类,也就是说,每个Worker都会隐式的持有ThreadPoolExecutor对象的引用(内部类的相关原理请自行补课)。每个Worker在运行时(在不同的子线程中运行)都能够对ThreadPoolExecutor对象(通常来说这个对象是在main线程中被维护)中的属性进行访问和修改。Worker实现了Runnable接口,并且其run方法实际是调用的ThreadPoolExecutor上的runWorker方法。在新建一个Worker时,会创建一个新的Thread对象,并把当前Worker的引用传递给这个Thread对象,随后调用这个Thread对象的start方法,则开始在这个Thread中(子线程中)运行这个Worker

        Worker(Runnable firstTask) {
            setState(-1); // inhibit interrupts until runWorker
            this.firstTask = firstTask;
            this.thread = getThreadFactory().newThread(this);
        }

ThreadPoolExecutor中的addWorker方法

再次跟源码时,加深了对ThreadPoolExecutorWorker体系的理解和认识。

它们之间有一种嵌套依赖的关系。每个Worker里持有一个Thread对象,这个Thread对象又是以这个Worker对象作为Runnable,而Worker又是ThreadPoolExecutor的内部类,这意味着每个Worker对象都会隐式的持有其所属的ThreadPoolExecutor对象的引用。每个Workerrun方法, 都跑在子线程中,但是这些Worker跑在子线程中时,能够对ThreadPoolExecutor对象的属性进行访问和修改(每个Workerrun方法都是调用的runWorker,所以runWorker方法是跑在子线程中的,这个方法中会对线程池的状态进行访问和修改,比如当前子线程运行过程中抛出异常时,会从ThreadPoolExecutor中移除当前Worker,并启一个新的Worker)。而通常来说,ThreadPoolExecutor对象的引用,我们通常是在主线程中进行维护的。

反正就是这中间其实有点骚东西,没那么简单。需要多跟几次源码,多自己打断点进行debug,debug过程中可以通过IDEA的Evaluate Expression功能实时观察当前方法执行时所处的线程环境(Thread.currentThread)。

扯得有点远了,现在回到正题。上面说了调用ThreadPoolExecutor中的execute方法提交任务,子线程中出现异常时,异常会被抛出,打印在控制台,并且当前Worker会被线程池回收,并重启一个新的Worker作为替代。那么,调用submit时,异常为何就没有被打印到控制台呢?

我们看一下源码:

    public Future<?> submit(Runnable task) {
        if (task == null) throw new NullPointerException();
        RunnableFuture<Void> ftask = newTaskFor(task, null);
        execute(ftask);
        return ftask;
    }
    protected <T> RunnableFuture<T> newTaskFor(Runnable runnable, T value) {
        return new FutureTask<T>(runnable, value);
    }

通过调用submit提交的任务,被包装了成了一个FutureTask对象,随后会将这个FutureTask对象,通过execute方法提交给线程池,并返回FutureTask对象给主线程的调用者。

也就是说,submit方法实际做了这几件事

关键就在于FutureTask,我们来看一下

    public FutureTask(Runnable runnable, V result) {
        this.callable = Executors.callable(runnable, result);
        this.state = NEW;       // ensure visibility of callable
    }
    // Executors中
	public static <T> Callable<T> callable(Runnable task, T result) {
        if (task == null)
            throw new NullPointerException();
        return new RunnableAdapter<T>(task, result);
    }
    static final class RunnableAdapter<T> implements Callable<T> {
        final Runnable task;
        final T result;
        RunnableAdapter(Runnable task, T result) {
            this.task = task;
            this.result = result;
        }
        public T call() {
            task.run();
            return result;
        }
    }

通过submit方法传入的Runnable,通过一个适配器RunnableAdapter转化为了Callable对象,并最终包装成为一个FutureTask对象。这个FutureTask,又实现了RunnableFuture接口

于是我们看下FutureTaskrun方法(因为最终是将包装后的FutureTask提交给线程池执行,所以最终会执行FutureTaskrun方法)

    protected void setException(Throwable t) {
        if (UNSAFE.compareAndSwapInt(this, stateOffset, NEW, COMPLETING)) {
            outcome = t;
            UNSAFE.putOrderedInt(this, stateOffset, EXCEPTIONAL); // final state
            finishCompletion();
        }
    }

可以看到,异常信息只是被简单的设置到了FutureTaskoutcome字段上。并没有往外抛,所以这里其实相当于把异常给生吞了catch块中捕捉到异常后,既没有打印异常的堆栈,也没有把异常继续往外throw。所以我们无法在控制台看到异常信息,在实际的项目中,此种场景下的异常信息也不会被输出到日志文件。这一点要特别注意,会加大问题的排查难度。

那么,为什么要这样处理呢?

因为我们通过submit提交任务时,会拿到一个Future对象

    public Future<?> submit(Runnable task) {
        if (task == null) throw new NullPointerException();
        RunnableFuture<Void> ftask = newTaskFor(task, null);
        execute(ftask);
        return ftask;
    }

我们可以在稍后,通过Future对象,来获知任务的执行情况,包括任务是否成功执行完毕,任务执行后返回的结果是什么,执行过程中是否出现异常。

所以,通过submit提交的任务,实际会把任务的各种状态信息,都封装在FutureTask对象中。当最后调用FutureTask对象上的get方法,尝试获取任务执行结果时,才能够看到异常信息被打印出来。

    public V get() throws InterruptedException, ExecutionException {
        int s = state;
        if (s <= COMPLETING)
            s = awaitDone(false, 0L);
        return report(s);
    }
    private V report(int s) throws ExecutionException {
        Object x = outcome;
        if (s == NORMAL)
            return (V)x;
        if (s >= CANCELLED)
            throw new CancellationException();
        throw new ExecutionException((Throwable)x); // 异常会通过这一句被抛出来
    }

小结

其他

其他的线程池场景

比如:

到此这篇关于Java线程的异常处理机制详情的文章就介绍到这了,更多相关Java线程异常处理内容请搜索编程网以前的文章或继续浏览下面的相关文章希望大家以后多多支持编程网!

阅读原文内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯