Starting a Java program is essentially running the main method of a Java class. We write an infinite loop program, run it, and then run jvisualvm
to observe
You can see that there are a total of 11 threads in this Java process. Among them, there are 10 daemon threads and 1 user thread. The code in our main method runs in a thread named main
. When all threads running in the Java process are daemon threads, the JVM will exit .
In a single-threaded scenario, if an exception is thrown when the code runs to a certain location, you will see the exception stack information printed out on the console. However, in a multi-threaded scenario, exceptions that occur in sub-threads may not necessarily print out the exception information in a timely manner.
I once encountered it at work. When using CompletableFuture.runAsync
to process time-consuming tasks asynchronously, an exception occurred during task processing, but there was no information about the exception in the log. After a long time, I revisited the exception handling mechanism in threads and deepened my understanding of the working principles of threads. I hereby record it.
We know that to run a Java program, the Java source code is first compiled into a class bytecode file through javac
, and then the JVM Load and parse the class file, and then start execution from the main method of the main class. When a thread throws an uncaught exception during operation, the JVM will call the dispatchUncaughtException
method on the thread object for exception handling.
// Thread类中 private void dispatchUncaughtException(Throwable e) { getUncaughtExceptionHandler().uncaughtException(this, e); }
The source code is easy to understand. First obtain an UncaughtExceptionHandler
exception handler, and then handle the exception by calling the uncaughtException
method of this exception handler. (The abbreviation ueh
is used below to represent UncaughtExceptionHandler
) What is
ueh
? In fact, it is an interface defined inside Thread
, used for exception handling.
@FunctionalInterface public interface UncaughtExceptionHandler { /** * Method invoked when the given thread terminates due to the * given uncaught exception. * <p>Any exception thrown by this method will be ignored by the * Java Virtual Machine. * @param t the thread * @param e the exception */ void uncaughtException(Thread t, Throwable e); }
Let’s take a look at the getUncaughtExceptionHandler
method in the Thread
object
public UncaughtExceptionHandler getUncaughtExceptionHandler() { return uncaughtExceptionHandler != null ? uncaughtExceptionHandler : group; }
First check whether the current Thread
object has settings If there is a custom ueh
object, it will handle the exception. Otherwise, the thread group (ThreadGroup
) to which the current Thread
object belongs will handle the exception. deal with. When we click on the open source code, we can easily find that the ThreadGroup
class itself implements the Thread.UncaughtExceptionHandler
interface, which means ThreadGroup
itself is an exception handler.
public class ThreadGroup implements Thread.UncaughtExceptionHandler { private final ThreadGroup parent; .... }
Suppose we throw an exception in the main
method. If there is no custom ueh
object set for the main
thread, the handover Exceptions are handled by the ThreadGroup
to which the main
thread belongs. Let’s take a look at how ThreadGroup
handles exceptions:
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); } } }
This part of the source code is also relatively short. The first is to check whether the current ThreadGroup
has the parent's ThreadGroup
. If so, call the parent ThreadGroup
for exception handling. Otherwise, call the static method Thread.getDefaultUncaughtExceptionHandler()
to obtain a default ueh
object.
If the default ueh
object is not empty, this default ueh
object will perform exception handling; otherwise, when the exception is not ThreadDeath
, directly print the name of the current thread and the exception stack information through the standard error output (System.err
) to console.
We just run a main
method and take a look at the thread situation
You can see So, the main
thread belongs to a ThreadGroup
also named main
, and the ThreadGroup
of this main
, its The parent ThreadGroup
is named system
, and the ThreadGroup
of this system
has no parent, it is the root ThreadGroup
.
It can be seen that the uncaught exception thrown in the main
thread will eventually be handed over to the ThreadGroup
named system
for exception handling , and since the ueh object of the default
is not set, the exception information will be output to the console through System.err
.
Next, we create a sub-thread in the main
thread in the simplest way (new
a Thread
), and in the sub-thread Write code that can throw exceptions in the thread and observe it
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种方式
对某一个Thread
对象,调用其setUncaughtExceptionHandler
方法,设置一个ueh
对象。注意这个ueh
对象只对这个线程起作用
调用静态方法Thread.setDefaultUncaughtExceptionHandler()
设置一个全局默认的ueh
对象。这样设置的ueh
对象会对所有线程起作用
当然,由于ThreadGroup
本身可以充当ueh
,所以其实还可以实现一个ThreadGroup
子类,重写其uncaughtException
方法进行异常处理。
若一个线程没有进行任何设置,当在这个线程内抛出异常后,默认会将线程名称和异常堆栈,通过System.err
进行输出。
在实际的开发中,我们经常会使用线程池来进行多线程的管理和控制,而不是通过new
来手动创建Thread
对象。
对于Java中的线程池ThreadPoolExecutor
,我们知道,通常来说有两种方式,可以向线程池提交任务:
execute
submit
其中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
中的addWorker
方法
再次跟源码时,加深了对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
提交的任务,被包装了成了一个FutureTask
对象,随后会将这个FutureTask
对象,通过execute
方法提交给线程池,并返回FutureTask
对象给主线程的调用者。
也就是说,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; } }
通过submit
方法传入的Runnable
,通过一个适配器RunnableAdapter
转化为了Callable
对象,并最终包装成为一个FutureTask
对象。这个FutureTask
,又实现了Runnable
和Future
接口
于是我们看下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(); } }
可以看到,异常信息只是被简单的设置到了FutureTask
的outcome
字段上。并没有往外抛,所以这里其实相当于把异常给生吞了,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); // 异常会通过这一句被抛出来 }
通过ThreadPoolExecutor
的execute
方法提交的任务,出现异常后,异常会在子线程中被抛出,并被JVM捕获,并调用子线程的dispatchUncaughtException
方法,进行异常处理,若子线程没有任何特殊设置,则异常堆栈会被输出到System.err
,即异常会被打印到控制台上。并且会从线程池中移除当前Worker
,并另启一个新的Worker
作为替代。
通过ThreadPoolExecutor
的submit
方法提交的任务,任务会先被包装成FutureTask
对象,出现异常后,异常会被生吞,并暂存到FutureTask
对象中,作为任务执行结果的一部分。异常信息不会被打印,该子线程也不会被线程池移除(因为异常在子线程中被吞了,没有抛出来)。在调用FutureTask
上的get
方法时(此时一般是在主线程中了),异常才会被抛出,触发主线程的异常处理,并输出到System.err
其他的线程池场景
比如:
使用ScheduledThreadPoolExecutor
实现延迟任务或者定时任务(周期任务),分析过程也是类似。这里给个简单结论,当调用scheduleAtFixedRate
方法执行一个周期任务时(任务会被包装成FutureTask
(实际是ScheduledFutureTask
,是FutureTask
的子类)),若周期任务中出现异常,异常会被生吞,异常信息不会被打印,线程不会被回收,但是周期任务执行这一次后就不会继续执行了。ScheduledThreadPoolExecutor
继承了ThreadPoolExecutor
,所以其也是复用了ThreadPoolExecutor
的那一套逻辑。
使用CompletableFuture
的runAsync
提交任务,底层是通过ForkJoinPool
线程池进行执行,任务会被包装成AsyncRun
,且会返回一个CompletableFuture
给主线程。当任务出现异常时,处理方式和ThreadPoolExecutor
的submit
类似,异常堆栈不会被打印。只有在CompletableFuture
上调用get
方法尝试获取结果时,异常才会被打印。
The above is the detailed content of What is the exception handling mechanism in Java threads?. For more information, please follow other related articles on the PHP Chinese website!