线程池执行的用户任务抛出异常会怎样

简介: 线程池执行的用户任务抛出异常会怎样



ThreadPoolExecutor.execute

源码分析

看源码可以知道,ThreadPoolExecutor中的任务都是在runWorker中执行的

通过源码可以看到

  • 1149行执行用户任务
  • 1150~1155处理捕获任务异常,并抛出
  • 抛出异常后会退出,从任务队列中拉取任务的循环
  • 然后执行1167行,worker线程退出的逻辑

看一下线程退出的逻辑

  • 如果是异常退出,参数completedAbruptly为true
  • 如果状态值比STOP小,即线程池没有停止,会重新创建一个worker线程

总结

ThreadPoolExecutor.execute 如果用户任务抛出了异常,在线程池运行的状态下,会重新创建一个worker线程。

这里就可能存在一个风险,即如果用户任务大量的抛出异常,可能会导出线程资源频繁的销毁、创建。

因此,需要用户任务应当主动对异常进行处理,而不是消极的抛给线程池。

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

ThreadPoolExecutor.submit

源码分析

通过 ThreadPoolExecutor.submit 提交的用户任务,会包装成一个FutureTask,返回一个Future对象。因此异常处理的逻辑和ThreadPoolExecutor.execute有些差别

看一个FutureTask.run方法

从源码可以看到,FutureTask执行用户任务,如果异常,不会对外抛出,仅是记录

但是在调用Future.get时,会抛出异常,但此时的线程不是线程池的线程了,而是用户线程,因此对线程池是友好的。

总结

ThreadPoolExecutor.submit 提交的用户任务,会包装成一个FutureTask,FutureTask执行用户任务,如果异常,不会对外抛出,仅是记录,但是在调用Future.get时,会抛出异常。

异常是在用户线程中抛出的,因此不影响线程池中的线程。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

ScheduledThreadPoolExecutor.schedule

源码分析

ScheduledThreadPoolExecutor.schedule会将用户任务包装为ScheduledFutureTaskScheduledFutureTask是FutureTask的子类,看下ScheduledFutureTask的执行逻辑

ScheduledFutureTask是FutureTask的子类,所以有异常时,也不是抛出,而是记录

  • 293行对于非周期性任务,执行一次,如果有异常,不抛出,仅记录
  • 294~296对于周期性任务,执行完本次后,会设置下次执行的时间。如果本次出现异常,ScheduledFutureTask.super.runAndReset()返回结果为false(这个可以从源码看到),此时不会设置下次任务调度的时间了,因此会导致周期性任务失效的现象,并且异常信息不会抛出,也不会打印

总结

ScheduledThreadPoolExecutor.schedule提交的用户任务,如果出现异常,是不会抛出的,也不会打印。

对于非周期性任务和周期性任务,执行异常,都没有办法感知(不抛出、看不到)。

对于周期性任务,任何一次调度时,任务出现异常,都会导致后续无法调度。

因此,在使用这个线程池时,我们应当保证用户任务不会抛出异常到执行线程,避免任务调度失效,和异常排查困难等问题。

思考:ThreadPoolExecutor.execute发生异常时为什么要退出

ThreadPoolExecutor.execute出现用户任务异常时,为什么要退出当前线程,再重新创建一个线程呢?

我思考了半天,觉得原因之一可能是:

ThreadPoolExecutor的可以指定线程工厂,如果我的线程工厂是这样的

ThreadFactory threadFactory = new ThreadFactory() {
    @Override
    public Thread newThread(Runnable r) {
        Thread thread = new Thread(r);
        thread.setUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() {
            @Override
            public void uncaughtException(Thread t, Throwable e) {
                // 处理异常的逻辑
            }
        });
        return thread;
    }
};

即在ThreadFactory创建线程时,指定了对未捕获的异常的处理器。

这种情况下,如果线程池不把发生异常的线程退出,可能会导致异常没有走到用户期望的逻辑上,因此需要将发生异常的线程退出,然后JVM调用UncaughtExceptionHandler



相关文章
|
2月前
线程CPU异常定位分析
【10月更文挑战第3天】 开发过程中会出现一些CPU异常升高的问题,想要定位到具体的位置就需要一系列的分析,记录一些分析手段。
82 0
|
1月前
|
存储 Java 数据库
如何处理线程池关闭时未完成的任务?
总之,处理线程池关闭时未完成的任务需要综合考虑多种因素,并根据实际情况选择合适的处理方式。通过合理的处理,可以最大程度地减少任务丢失和数据不一致等问题,确保系统的稳定运行和业务的顺利开展。
123 64
|
1月前
|
消息中间件 监控 Java
线程池关闭时未完成的任务如何保证数据的一致性?
保证线程池关闭时未完成任务的数据一致性需要综合运用多种方法和机制。通过备份与恢复、事务管理、任务状态记录与恢复、数据同步与协调、错误处理与补偿、监控与预警等手段的结合,以及结合具体业务场景进行分析和制定策略,能够最大程度地确保数据的一致性,保障系统的稳定运行和业务的顺利开展。同时,不断地优化和改进这些方法和机制,也是提高系统性能和可靠性的重要途径。
119 62
|
27天前
|
缓存 监控 Java
Java线程池提交任务流程底层源码与源码解析
【11月更文挑战第30天】嘿,各位技术爱好者们,今天咱们来聊聊Java线程池提交任务的底层源码与源码解析。作为一个资深的Java开发者,我相信你一定对线程池并不陌生。线程池作为并发编程中的一大利器,其重要性不言而喻。今天,我将以对话的方式,带你一步步深入线程池的奥秘,从概述到功能点,再到背景和业务点,最后到底层原理和示例,让你对线程池有一个全新的认识。
54 12
|
2月前
|
监控 Java
在实际应用中选择线程异常捕获方法的考量
【10月更文挑战第15天】选择最适合的线程异常捕获方法需要综合考虑多种因素。没有一种方法是绝对最优的,需要根据具体情况进行权衡和选择。在实际应用中,还需要不断地实践和总结经验,以提高异常处理的效果和程序的稳定性。
30 3
|
2月前
|
监控 Java
捕获线程执行异常的多种方法
【10月更文挑战第15天】捕获线程执行异常的方法多种多样,每种方法都有其特点和适用场景。在实际开发中,需要根据具体情况选择合适的方法或结合多种方法来实现全面有效的线程异常捕获。这有助于提高程序的健壮性和稳定性,减少因线程异常带来的潜在风险。
31 1
|
2月前
|
监控 API
Hook 线程与捕获线程执行异常
【10月更文挑战第11天】Hook 线程和捕获线程执行异常是多线程编程中不可或缺的技术。通过深入理解和掌握这些方法,我们可以提高程序的稳定性和可靠性,更好地应对各种异常情况。同时,在实际应用中要注意平衡性能和准确性,制定合理的异常处理策略,以确保程序的正常运行。
39 1
|
2月前
|
缓存 负载均衡 Java
c++写高性能的任务流线程池(万字详解!)
本文介绍了一种高性能的任务流线程池设计,涵盖多种优化机制。首先介绍了Work Steal机制,通过任务偷窃提高资源利用率。接着讨论了优先级任务,使不同优先级的任务得到合理调度。然后提出了缓存机制,通过环形缓存队列提升程序负载能力。Local Thread机制则通过预先创建线程减少创建和销毁线程的开销。Lock Free机制进一步减少了锁的竞争。容量动态调整机制根据任务负载动态调整线程数量。批量处理机制提高了任务处理效率。此外,还介绍了负载均衡、避免等待、预测优化、减少复制等策略。最后,任务组的设计便于管理和复用多任务。整体设计旨在提升线程池的性能和稳定性。
87 5
|
3月前
|
消息中间件 前端开发 NoSQL
面试官:线程池遇到未处理的异常会崩溃吗?
面试官:线程池遇到未处理的异常会崩溃吗?
86 3
面试官:线程池遇到未处理的异常会崩溃吗?