java线程出现异常,线程中的异常如何处理

　　00-1010线程异常处理机制概述线程池异常处理概述场景其他

　　00-1010启动一个Java程序，本质上就是运行一个Java类的main方法。我们编写一个无限循环程序，运行它，然后运行JVM来观察。

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

　　在单线程场景中，如果代码运行到某个位置时抛出异常，您将看到控制台打印出异常的堆栈信息。但是，在多线程场景中，子线程中的异常可能无法及时打印出异常信息。

　　我曾经在工作中遇到过，使用CompletableFuture.runAsync异步处理耗时任务时，任务处理过程中出现异常。但是，日志中没有关于异常的信息。时间久了，回顾了线程中的异常处理机制，加深了对线程工作原理的理解，特此记录。

　　00-1010我们知道，Java程序的运行是通过javac将Java源代码编译成类字节码文件，然后通过JVM加载解析类文件，再从主类的main方法开始执行。当一个线程在运行的进程中抛出未捕获异常时，JVM会调用thread对象上的dispatchUncaughtException方法来处理异常。

　　//privatevoid调度程序uncaughtexception(throwable e){ getuncaughtexceptionhandler()。thread类中的uncaughtexception (this，e)；}源码简单易懂。首先，获取一个UncaughtExceptionHandler异常处理程序，然后通过调用该异常处理程序的uncaughtException方法来处理该异常。(在下文中，缩写ueh用于表示UncaughtExceptionHandler)

　　ueh是什么？实际上，它是一个定义在Thread内部的接口，用于异常处理。

　　@FunctionalInterface公共接口UncaughtExceptionHandler { /** *当给定线程由于*给定的未捕获异常而终止时调用的方法。* Java虚拟机将忽略此方法引发的任何异常。* @ param t the Thread * @ param e the exception */void uncaughtException(Thread t，Throwable e)；}我们来看看Thread对象中的getUncaughtExceptionHandler方法。

　　public UncaughtExceptionHandler getUncaughtExceptionHandler(){ return UncaughtExceptionHandler！=null？uncaughtExceptionHandler :组；}首先检查当前线程对象是否有自定义的ueh对象，如果有则处理异常，否则由当前线程对象所属的线程组处理异常。当我们点击源代码的时候，很容易发现ThreadGroup类本身实现了Thread.uncaughtException处理程序接口，也就是说ThreadGroup本身就是一个异常处理程序。

　　公共课堂

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

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

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

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

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

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

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

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

小结

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

　　对某一个Thread对象，调用其setUncaughtExceptionHandler方法，设置一个ueh对象。注意这个ueh对象只对这个线程起作用调用静态方法Thread.setDefaultUncaughtExceptionHandler()设置一个全局默认的ueh对象。这样设置的ueh对象会对所有线程起作用当然，由于ThreadGroup本身可以充当ueh，所以其实还可以实现一个ThreadGroup子类，重写其uncaughtException方法进行异常处理。

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

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

线程池场景下的异常处理

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

　　executesubmit其中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方法进行处理，根据上面的分析，最终异常堆栈会被打印到控制台。

　　多扯几句别的。

　　上面跟源码时，注意到Worker是ThreadPoolExecutor的一个内部类，也就是说，每个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和Worker体系的理解和认识。

　　它们之间有一种嵌套依赖的关系。每个Worker里持有一个Thread对象，这个Thread对象又是以这个Worker对象作为Runnable，而Worker又是ThreadPoolExecutor的内部类，这意味着每个Worker对象都会隐式的持有其所属的ThreadPoolExecutor对象的引用。每个Worker的run方法， 都跑在子线程中，但是这些Worker跑在子线程中时，能够对ThreadPoolExecutor对象的属性进行访问和修改（每个Worker的run方法都是调用的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方法实际做了这几件事

　　将提交的Runnable，包装成FutureTask调用execute方法提交这个FutureTask（实际还是通过execute提交的任务）将FutureTask作为返回值，返回给主线程的调用者关键就在于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; } }

　　于是我们看下FutureTask的run方法（因为最终是将包装后的FutureTask提交给线程池执行，所以最终会执行FutureTask的run方法）

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

　　那么，为什么要这样处理呢？

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

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

　　所以，通过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); // 异常会通过这一句被抛出来 }

小结

其他

　　比如：

　　使用ScheduledThreadPoolExecutor实现延迟任务或者定时任务（周期任务），分析过程也是类似。这里给个简单结论，当调用scheduleAtFixedRate方法执行一个周期任务时（任务会被包装成FutureTask（实际是ScheduledFutureTask，是FutureTask的子类）），若周期任务中出现异常，异常会被生吞，异常信息不会被打印，线程不会被回收，但是周期任务执行这一次后就不会继续执行了。ScheduledThreadPoolExecutor继承了ThreadPoolExecutor，所以其也是复用了ThreadPoolExecutor的那一套逻辑。使用CompletableFuture的runAsync提交任务，底层是通过ForkJoinPool线程池进行执行，任务会被包装成AsyncRun，且会返回一个CompletableFuture给主线程。当任务出现异常时，处理方式和ThreadPoolExecutor的submit类似，异常堆栈不会被打印。只有在CompletableFuture上调用get方法尝试获取结果时，异常才会被打印。到此这篇关于Java线程的异常处理机制详情的文章就介绍到这了,更多相关Java线程异常处理内容请搜索盛行IT以前的文章或继续浏览下面的相关文章希望大家以后多多支持盛行IT！

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。