Java 并发编程——线程池的异常处理机制

最新推荐文章于 2025-09-10 13:53:07 发布
原创 最新推荐文章于 2025-09-10 13:53:07 发布 · 1.6k 阅读 · 6 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#多线程

部署运行你感兴趣的模型镜像

一、前言

1.1 文章起因

这篇文章的起因来源于一个 BUG，这个 BUG 和上篇文章《Java SynchronizedSet 线程不安全之坑》 有点关系。简单来说，就是在线程池中执行任务，任务本身未做异常处理，导致出现异常后任务停止。

出错的原因来自对 Collections.synchronizedSet(new HashSet<>()) 的线程不安全访问，抛出了 ConcurrentModificationException。

问题的关键是在事后查询线上日志时并没有发现相关异常记录，导致问题的排查变得困难。所幸最后找到了问题，同时也发现了默认情况下线程中的异常是不会被记录到日志中的，也算是踩了个坑吧，这就是这篇文章的由来。

1.2 问题复现

写个简单的 Case 复现一下，首先日志框架这里使用 log4j2：

<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.12.1</version>
</dependency>

在 resources 目录下创建 log4j2.xml 配置文件，将日志信息输出到文件中：

<?xml version="1.0" encoding="UTF-8"?>
<configuration status="ON">
    <appenders>
        <Console name="Console" target="SYSTEM_OUT">
            <PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n"/>
        </Console>
        <RollingFile name="RollingFile" fileName="target/logs/app.log"
                     filePattern="target/logs/$${date:yyyy-MM}/app-%d{MM-dd-yyyy}-%i.log.gz">
            <PatternLayout pattern="%d{yyyy.MM.dd 'at' HH:mm:ss z} %-5level %class{36} %L %M - %msg%xEx%n"/>
            <SizeBasedTriggeringPolicy size="10 MB" />
        </RollingFile>
    </appenders>
    <loggers>
        <root level="DEBUG">
            <appender-ref ref="Console"/>
            <appender-ref ref="RollingFile"/>
        </root>
    </loggers>
</configuration>

编写示例程序，创建一个线程池执行任务，业务逻辑为除零操作：

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;

import java.util.concurrent.LinkedBlockingQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;

public class ThreadPoolLogTest {
    private static final long KEEP_ALIVE_TIME = 60L;
    private static Logger log = LogManager.getLogger(ThreadPoolLogTest.class);

    public static void main(String[] args) {
        ThreadPoolExecutor executor = poolExecutor(1, 1);
        log.info("开始提交任务");
        executor.execute(ThreadPoolLogTest::doSomeThing);
        log.info("提交任务完成");
    }

    private static void doSomeThing() {
        int value = 10 / 0;
    }

    public static ThreadPoolExecutor poolExecutor(int core, int max) {
        return new ThreadPoolExecutor(core, max, KEEP_ALIVE_TIME, TimeUnit.SECONDS,
                new LinkedBlockingQueue<>(), new ThreadPoolExecutor.AbortPolicy());
    }
}

运行程序，查看控制台输出及日志输出。我们发现，在控制台中正确输出了异常栈，但是在日志中却没有记录下异常栈。

二、原生处理机制

我们知道，对线程池提交任务有两种方式，一种是 execute 方式，另一种是 submit 方式，这两种方式我都会分别介绍它们的处理方式。

由于咱们上面的例子使用的是 execute 方式，就先说说这种方式吧。

2.1 execute 方式

如下图所示，ThreadPoolExecutor 通过 getThreadFactory().newThread(this) 方式创建了一个任务，其底层执行的为 Thread 类。

ThreadPoolExecutor#addWorker

查看 Thread 类的源码，发现了两个十分特别的方法，结合上面的 JavaDoc 注释：

  • setUncaughtExceptionHandler()：一个线程可以通过该方法来设置有未捕获的异常时程序的处理机制。如果没有设置，则 ThreadGroup 会作为默认的处理机制。

  • dispatchUncaughtException(): 当出现未捕获异常时调用该方法，该方法仅被 JVM 所调用。

接着我们看下 dispatchUncaughtException() 中的 uncaughtException() 方法，发现其属于 UncaughtExceptionHandler 接口，查看该接口实现类。目前只有一个实现类，就是 ThreadGroup。

Thread#dispatchUncaughtException

现在有点思路了，梳理下：

  1. Case 中的除零异常未做异常处理，因此当执行到该处时，JVM 会调用 dispatchUncaughtException()方法。
  2. 默认情况下，ThreadGroup 会作为默认的处理机制，即会调用 ThreadGroup#uncaughtException() 方法。

让我们看看 ThreadGroup 的 uncaughtException() 方法是如何处理的。

ThreadGroup#uncaughtException

方法比较简单：

  1. 首先判断是否存在 parent，parent 在构造时会被传入，默认是当前线程的 ThreadGroup。如果存在话调用 parent 的 uncaughtException() 方法。
  2. 判断当前线程是否有设置 defaultUncaughtExceptionHandler，如果有，调用它的 uncaughtException() 方法。
  3. 最后，只要异常不是 ThreadDeath 子类，直接使用 System.err 输出。

OK 了，问题找到了。如果这里直接走了最后的逻辑，那么 System.err 是只会输出在控制台和 tomcat 的 catalina.out 中，不会输出在日志中的。打上断点验证下。

Debug Verify

Thread.getDefaultUncaughtExceptionHandler() 为 null，除零异常不属于 ThreadDeath，因此执行 System.err 的逻辑，大功告成。

2.2 submit 方式

以上这些都是针对线程池的 execute() 而言，如果咱使用的是 submit() 呢，修改 Case 如下：

public class ThreadPoolLogTest {
    private static final long KEEP_ALIVE_TIME = 60L;
    private static Logger log = LogManager.getLogger(ThreadPoolLogTest.class);

    public static void main(String[] args) throws ExecutionException, InterruptedException {
        ThreadPoolExecutor executor = poolExecutor(1, 1);
        log.info("开始提交任务");
        Future<Result> task = executor.submit(ThreadPoolLogTest::doSomeThing);
        log.info("提交任务完成");

        // 临时注释
//        while (!task.isDone()) {
//            TimeUnit.MILLISECONDS.sleep(100);
//        }
//        log.info("任务执行结果：{}", task.get().ok);
    }

    private static Result doSomeThing() {
        int value = 10 / 0;
        return new Result(true);
    }

    public static ThreadPoolExecutor poolExecutor(int core, int max) {
        return new ThreadPoolExecutor(core, max, KEEP_ALIVE_TIME, TimeUnit.SECONDS,
                new LinkedBlockingQueue<>(), new ThreadPoolExecutor.AbortPolicy());
    }

    static class Result {
        boolean ok;

        Result(boolean ok) { this.ok = ok; }

        @Override
        public String toString() { return "Result{" + "ok=" + ok + '}'; }
    }
}

ThreadPoolExecutor#submit

运行程序，发现这次不仅日志没有异常栈，连控制台也没了，继续开始看源码。

submit

我们发现 submit 方法最后底层真正干活的是 FutureTask，同时任务的 state 被置为 1（NEW）。接着看 FutureTask 类的 run() 方法是如何处理的。

FutureTask#run

run() 方法中关于异常处理的部分：

  1. 将 FutureTask 包装的返回置为了 null
  2. 将 ran 置为了 false
  3. 调用 setException() 方法

在 setException() 方法中：

  1. 将异常保存给了 outcome
  2. state 被置为了 3（EXCEPTIONAL）

至此就结束了，说明 submit() 方式的异常信息并不是在 run() 方法中抛出的，因此只能去看获取执行结果的 get() 方法。

FutureTask#get

由于之前 state 被设置为了 3（EXCEPTIONAL），因此 get() 方法中直接走 report() 方法，report() 方法中首先将 ountcome 取出赋给局部变量 x，对于 s == 3 的处理是直接将异常 x 包装成 ExecutionException 抛出。

至此，完成源码查看，梳理下思路：

  1. 线程池调用 submit() 方法底层是由 FutureTask 来执行的。
  2. FutureTask 的 run() 方法在抛出异常时，调用 setException() 方法将异常保存下来。
  3. 主线程通过调用 FutureTask 的 get() 方法，当执行出现异常时，被抛出。

最后恢复本节 Case main() 方法最后一行的注释，重新运行程序，得到和 execute() 方式一样的结果。

三、自定义处理机制

本章将开始介绍如何解决异常栈不输出到日志文件中的问题，提出以下四种解决方式：

  1. 手动 catch：适用 execute() 方式、submit() 方式
  2. 自定义 ThreadPoolExecutor：适用 execute() 方式
  3. 自定义 ThreadGroup：适用 execute() 方式
  4. 设置 UncaughtExceptionHandler：适用 execute() 方式

之所以后面三种不适用于 submit() 方式，是因为 sumbit() 方式只有在主线程 get() 时候才会抛出异常，因此直接在主线程手动 catch get() 方法即可，不需要自定义 ThreadPoolExecutor。而自定义 ThreadGroup 和设置 UncaughtExceptionHandler这两种，是跟 Thread 类强绑定的，与 submit() 无关。

3.1 手动 Catch

手动 Catch 是最简单的方法，直接在会抛出异常的地方手动 catch 即可。唯一麻烦的地方就是要在每个任务的地方都写一遍。

（1）对于 sumbit() 方式，修改 doSimeThing() ：

private static Result doSomeThing() {
    try {
        int value = 10 / 0;
    } catch (Exception e) {
        log.error("doSomeThing execute Exception: ", e);
        return new Result(false);
    }
    return new Result(true);
}

运行结果如下：

sumbit catch

（2）对于 execute() 方式，修改 doSimeThing() ：

private static void doSomeThing() {
    try {
        int value = 10 / 0;
    } catch (Exception e) {
        log.error("doSomeThing execute Exception: ", e);
    }
}

运行结果如下：

execute catch

3.2 自定义 ThreadPoolExecutor

首先咱们先抽取一个 utils 方法，用于打印异常栈，后面都会用到：

public class ThreadUtils {
    public static String stackTrace(StackTraceElement[] stackTrace) {
        if (stackTrace != null && stackTrace.length > 0) {
            StringBuilder logs = new StringBuilder(512);
            for (StackTraceElement e : stackTrace) {
                logs.append(java.text.MessageFormat.format("{0}: {1}(): {2}" , e.getClassName(), e.getMethodName(),
                        e.getLineNumber())).append("\n");
            }
            return logs.toString();
        }
        return "";
    }
}

自定义 ThreadPoolExecutor，并重写 afterExecute() 方法，该方法在任务执行完毕后会被调用，我们可以在其中处理我们的异常。

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;

import java.util.concurrent.*;

public class CustomThreadPoolExecutor extends ThreadPoolExecutor {
    private static Logger log = LogManager.getLogger(CustomThreadPoolExecutor.class);

    public CustomThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit,
                                    BlockingQueue<Runnable> workQueue, RejectedExecutionHandler handler) {
        super(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue, handler);
    }

    @Override
    protected void afterExecute(Runnable r, Throwable e) {
        super.afterExecute(r, e);
        log.error("CustomThreadPoolExecutor execute Exception: {}",
                ThreadUtils.stackTrace(e.getStackTrace()));
    }
}

重新调整下我们的 Case，把线程池的创建替换成我们自定义的线程池：

public class ThreadPoolLogTest {
    private static final long KEEP_ALIVE_TIME = 60L;
    private static Logger log = LogManager.getLogger(ThreadPoolLogTest.class);

    public static void main(String[] args) {
        ThreadPoolExecutor executor = poolExecutor(1, 1);
        log.info("开始提交任务");
        executor.execute(ThreadPoolLogTest::doSomeThing);
        log.info("提交任务完成");
    }

    private static void doSomeThing() {
        int value = 10 / 0;
    }

    public static CustomThreadPoolExecutor poolExecutor(int core, int max) {
        return new CustomThreadPoolExecutor(core, max, KEEP_ALIVE_TIME, TimeUnit.SECONDS,
                new LinkedBlockingQueue<>(), new ThreadPoolExecutor.AbortPolicy());
    }
}

运行程序：

CustomThreadPoolExecutor

之所以控制台会输出两遍异常栈，是因为第一遍是我们自定义线程池输出的，且它会被记录到日志中。第二遍是 super.afterExecute(r, e) 导致的，这一遍只会输出在控制台。

3.3 自定义 ThreadGroup

除了可以自定义线程池，也可以自定义 ThreadGroup，这样就不会调用默认的 ThreadGroup，走 System.err 的逻辑了。

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;

public class CustomThreadGroup extends ThreadGroup {
    private static Logger log = LogManager.getLogger(CustomThreadGroup.class);

    public CustomThreadGroup(String name) {
        super(name);
    }

    @Override
    public void uncaughtException(Thread t, Throwable e) {
        super.uncaughtException(t, e);
        log.error("CustomThreadPoolExecutor execute Exception: {}",
                ThreadUtils.stackTrace(e.getStackTrace()));
    }
}

重新调整下我们的 Case，线程池的创建时传入我们自定义的 ThreadGroup：

public class ThreadPoolLogTest {
    private static final long KEEP_ALIVE_TIME = 60L;
    private static Logger log = LogManager.getLogger(ThreadPoolLogTest.class);

    public static void main(String[] args) {
        ThreadPoolExecutor executor = poolExecutor(1, 1);
        log.info("开始提交任务");
        executor.execute(ThreadPoolLogTest::doSomeThing);
        log.info("提交任务完成");
    }

    private static void doSomeThing() {
        int value = 10 / 0;
    }

    public static ThreadPoolExecutor poolExecutor(int core, int max) {
        return new ThreadPoolExecutor(core, max, KEEP_ALIVE_TIME, TimeUnit.SECONDS,
                new LinkedBlockingQueue<>(), r -> new Thread(new CustomThreadGroup("CustomThreadGroup"), r),
                new ThreadPoolExecutor.AbortPolicy());
    }
}

运行程序：

CustomThreadGroup

3.4 设置 UncaughtExceptionHandler

最后一种，手动设置 UncaughtExceptionHandler。重新调整下我们的 Case，线程池的创建时传入我们自定义的 UncaughtExceptionHandler：

public class ThreadPoolLogTest {
    private static final long KEEP_ALIVE_TIME = 60L;
    private static Logger log = LogManager.getLogger(ThreadPoolLogTest.class);

    public static void main(String[] args) {
        ThreadPoolExecutor executor = poolExecutor(1, 1);
        log.info("开始提交任务");
        executor.execute(ThreadPoolLogTest::doSomeThing);
        log.info("提交任务完成");
    }

    private static void doSomeThing() {
        int value = 10 / 0;
    }

    public static ThreadPoolExecutor poolExecutor(int core, int max) {
        return new ThreadPoolExecutor(core, max, KEEP_ALIVE_TIME, TimeUnit.SECONDS,
                new LinkedBlockingQueue<>(), r -> {
                    Thread thread = new Thread(r);
                    thread.setUncaughtExceptionHandler((t, e) ->
                            log.error("CustomThreadPoolExecutor execute Exception: {}",
                                    ThreadUtils.stackTrace(e.getStackTrace())));
                    return thread;
                }, new ThreadPoolExecutor.AbortPolicy());
    }
}

运行程序：

与自定义 ThreadPoolExecutor、自定义 ThreadGroup 不同的是，这种方式不会打印两遍错误栈。

四、ScheduledThreadPoolExecutor

ScheduledThreadPoolExecutor 是另一种常用的线程池，常用了执行延迟任务或定时任务。常用的方法为 scheduleXXX 系列。那在这个线程池中异常是如何处理的呢？

ScheduledThreadPoolExecutor 底层使用 ScheduledFutureTask 来执行任务，而 ScheduledFutureTask 是 FutureTask 的子类。

在使用 schedule() 方法时，我们可以通过这两个方法返回的 Future 来获得执行结果，这和 ThreadPoolExecutor 的 submit() 的处理方式是一致的。但是对于 scheduleWithFixedDelay() 和 scheduleAtFixedRate() 这两个方法，执行的是定时任务，返回的 Future 只会用来取消任务，而不是得到结果。因此对于这两个方法来说，需要采用 ThreadPoolExecutor 的 execute() 的处理方式。

五、总结

5.1 ThreadPoolExecutor

  1. sumbit() 方式底层使用 FutureTask 执行任务，如果业务抛出异常，只有在调用 Future#get() 时才会被抛出。

  2. execute() 方法底层使用 Thread 执行任务，如果业务抛出异常，默认采用 Sysstem.err 进行输出，只会打印在控制台和 tomcat 的 catalina.out 文件，不会输出到日志中。

  3. sumbit() 方法处理异常，既可以在业务中进行手动 catch，也可以在调用 Future#get() 时手动 catch。

  4. execute() 方法处理异常：

    • 业务中手动 catch，每个业务地方都要写，最稳妥。

    • 自定义 ThreadPoolExecutor 或者自定义 ThreadGroup，控制台会打印两遍日志。

    • 设置 UncaughtExceptionHandler，控制台只打印一遍日志。

5.2 ScheduledThreadPoolExecutor

  1. schedule() 方法采用和 ThreadPoolExecutor 的 sumbit() 方法一样处理异常。
  2. scheduleWithFixedDelay() 和 scheduleAtFixedRate() 方法采用和 ThreadPoolExecutor 的 execute() 方法一样处理异常。

5.3 程序的健壮性

最后在想谈谈健壮性这个问题，不论是自定义 ThreadPoolExecutor，或是自定义 ThreadGroup，或是设置 UncaughtExceptionHandler。到了这个地步说明线程执行已经出现了错误，此时整个任务已经挂掉了。

举个例子，例如你使用线程池进行一批数据计算，其中有一项数据出了问题。如果忽略出错的那一项数据是可接受的话，那么让整个任务都挂掉是不合适的。因此你应该在业务中手动 catch，来避免整个任务挂掉。

再举个例子，如果某个任务对正确性要求十分的高，如果出错整个系统都没有运行的必要了，那么就可以使用其他的几种处理方式。

可能例子举得不是十分恰当，但我想说明的是，技术最终要服务于业务，具体该使用哪种方式应该与你的业务场景有关。

您可能感兴趣的与本文相关的镜像

Llama Factory

Llama Factory

模型微调
LLama-Factory

LLaMA Factory 是一个简单易用且高效的大型语言模型（Large Language Model）训练与微调平台。通过 LLaMA Factory，可以在无需编写任何代码的前提下，在本地完成上百种预训练模型的微调

线程池的异常处理
Top5软件工程硕士，先后在京东、字节从事多年Java后端开发、实时和离线大数据开发
12-25 1465
java线程池会捕获任务抛出的异常和错误，但不做任何处理好的程序设计应该考虑到对于类异常的处理处理线程池中的异常有两种思路：  1）提交到线程池中的任务自己捕获异常并处理，不抛给线程池  2）由线程池统一处理对于execute方法提交的线程，有两种处理方式  1）自定义线程池并实现afterExecute方法  2）给线程池中的每个线程指定一个UncaughtExceptionHandle
并发编程——线程池
一只奋斗的程序羊博客
08-08 690
目录 一、为什么要使用线程池 二、自定义线程池 自定义任务队列 自定义线程池管理器 拒绝策略接口 测试(任务生产者) 总结流程 三、线程池 ThreadPoolExecutor 线程池状态 线程池的工作状态 四、Executors 类 newFixedThreadPool（固定大小的线程池） newCachedThreadPool(带缓冲工厂的线程池) newSingleThreadExecutor(单线程的线程池) ...
解析Java线程池的异常处理机制
weixin_34348111的博客
08-21 323
前言 今天小伙伴遇到个小问题，线程池提交的任务如果没有catch异常，那么会抛到哪里去，之前倒是没研究过，本着实事求是的原则，看了一下代码。 正文 小问题 考虑下面这段代码，有什么区别呢？你可以猜猜会不会有异常打出呢？如果打出来的话是在哪里？: ExecutorService threadPool = Executors....
线程池中线程抛了异常，该如何处理？
最新发布
m0_69632475的博客
09-10 974
在实际开发中，我们常常会用到线程池，但任务一旦提交到线程池之后，如果发生异常之后，怎么处理？怎么获取到异常信息？在了解这个问题之前，可以先看一下 线程池的源码解析，从源码中我们知道了线程池的提交方式：submit和execute的区别，接下来分别使用他们执行带有异常的任务！看结果是怎么样的！运行结果：可以看到：submit不打印异常信息，而execute则会打印异常信息！
Java线程池「异常处理」正确姿势：有病就得治
小姐姐味道
07-11 631
假设我们有一个线程池，由于程序需要，我们向该线程池中提交了好多好多任务，但是 这些任务都没有对异常进行try catch处理，并且运行的时候都抛出了异常 。这会对线程池的运行带来什么影响？ 正确答案是：没有影响。这可不是好事情。 想一下，如果是你开发了一个线程池供开发者使用，你会不会对这种情况做处理？想想也是肯定的，不然你提供给别人使用的东西就是有问题的，欠考虑的。而且java线程池...
线程池异常如何处理？
lucky_love816的博客
05-17 2748
忽的一下，想到了线程池的比较重要的一个参数：ThreadFactory接口，这个接口的作用是按需创建新线程的，使用线程工厂消除了对Thread#Thread(Runnable) new Thread的强依赖，使应用程序能够使用特殊的Thread子类、优先级等。大白话就是让线程池中的线程使用我们自定义的线程，这个自定义可不是我们通过execute()或submit()传进来的自定义线程，而是Worker类中的thread变量，也就是实际运行的线程，我们看一下Worker类的构造方法。
Java线程池异常处理机制
liuerchong的博客
03-30 3308
前言 Thread t = new Thread(() -> System.out.println(1 / 0)); t.start(); 如果我们执行上面这段代码，会在控制台上看到异常输出。通常情况下绝大多数线上应用不会将控制台作为日志输出地址，而是另有日志输出。这种情况下，上面的代码所抛出异常便会丢失。那为了将异常输出到日志中，我们会这样写代码： hread t = new Thread(() -> { try { System.out.println(1 / 0); } cat
java多线程——线程池
oopxiajun博客专栏
11-25 1759
在Java中，线程池是一种用于管理和复用线程的技术，它可以减少创建和销毁线程的开销，提高系统的性能和响应速度。Java标准库提供了包，其中包含了接口及其实现类，用于创建和管理线程池。
Java 异步编程——常用线程池 ThreadPoolExecutor
longool的博客
10-18 1279
默认情况下，只有当线程池中的线程数大于 corePoolSize 时，keepAliveTime 才会起作用，直到线程池中的线程数不大于 corePoolSize，即当线程池中的线程数大于 corePoolSize 时，如果一个线程空闲的时间达到 keepAliveTime，则会终止，直到线程池中的线程数不超过 corePoolSize。【注：每一个线程在获取锁的时候可能都会排队等待，如果在等待时间上，先获取锁的线程的请求一定先被满足，那么这个锁就是公平的。容量为0，不存储任何元素，即没有数据缓存的空间。
【JUC】并发编程重点知识——线程池
gadiaola的博客
06-15 920
Java线程池详解，包括线程池简介、Executors、ThreadPoolExecutor、线程池工作原理和常见的线程池等等。
并发编程——14 线程池参数动态化
念头通达
09-03 947
线程池在业务中的实践、线程池参数动态化（基于 Nacos 配置中心动态调整线程池参数、使用DynamicTp——基于配置中心的轻量级动态可监控线程池）
线程池的异常处理机制
CodeV的博客
11-21 586
一次开发过程中，送审之后向三方OA系统推送代办，其中由于优化的原因使用到线程池中间有一个判断，该不该推送，然后使用el表达式进行判断，但是测试环境中el表达式配置的不标准，导致现象就是没有推送，也没有日志，子线程就像停住了，没啥动静了。
Java 线程池的异常处理机制
weixin_34357928的博客
04-20 138
为什么80%的码农都做不了架构师？>>> ...
java线程/线程池异常处理机制
文若书生的专栏
06-14 2017
JAVA中线程和线程池异常处理问题
线程池中线程抛出了异常，该如何处理?
zy1992As的博客
06-28 2564
通过调用future.get()方法获取线程执行结果时，如果线程抛出异常，get()方法将抛出ExecutionException，其中包装了实际的异常。在执行线程任务的代码块内，使用try-catch语句捕获异常，并在catch块中处理异常。通过使用submit()方法提交任务到线程池，并获取返回的Future对象，可以在后续通过Future对象获取线程执行结果或处理异常。如果使用ThreadPoolExecutor类创建线程池，可以覆盖afterExecute()方法，在该方法中处理线程抛出的异常。
java线程池异常处理
祗要习惯就好的博客
12-17 967
java线程池对子线程异常的处理 废话不多说，直接上代码 1.通过重写线程池的afterExecute()方法，代码如下： static ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(5, 8, 60, TimeUnit.SECONDS, new ArrayBlockingQueue<>(1024)...
线程池异常如何处理你都了解吗？
热门推荐
weixin_45987961的博客
02-04 1万+
大家在开发的过程中是否发现，我们使用线程池的时候很少去处理运行过程中出现的错误，不处理错误这样没关系吗？不处理会不会导致线程池结束？如果需要处理错误我们应该如何进行处理呢？那么今天从以下几个方面来看一下 1.线程池异常 通过代码来演示三种异常线程池的情况。 1.1Runable执行异常(业务异常) 测试代码： public class ThreadPoolExceptionTest { public static void main(String[] args) {
线程池中线程抛了异常如何处理？
qq_1149513559的博客
03-09 1万+
文章目录1. 模拟线程池抛异常2. 如何获取和处理异常方案一：使用 try -catch方案二：使用Thread.setDefaultUncaughtExceptionHandler方法捕获异常方案三：重写afterExecute进行异常处理 1. 模拟线程池抛异常         在实际开发中，我们常常会用到线程池，但任务一旦提交到线程池之后，如果发生异常之后，怎么处理？ 怎么获取到异常信息？在了解这个问题之前，可以先看一下
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值