多线程下的异常捕获

推荐博文 https://www.cnblogs.com/noteless/p/10354733.html

这篇博文已经很详细了，超赞，没什么能补充的

对于最后提出的一个问题：

对于未检查异常，你也可以进行try catch，但是代码始终包裹在try中，真的好吗？

情景：在run方法中是不能够抛出异常的，如果是已检查的异常，那么必须进行try catch。对于未检查的异常，如果没有进行处理，一旦抛出线程将会宕掉，而且在主线程中并不能捕获到这个异常，所以一种方案是也加上try catch。但是我们很多时候，无法正确预估错误发生的大概位置，只能用try尽可能多的包裹代码，有时甚至将整个run方法内容全部包裹。

回到问题，try包裹代码量的多少会有什么影响吗，为什么很多资料都说try中代码越少越好

1. 定位问题效率，try的范围越大，出错后，就越难定位具体出错的模块了

2. try中的代码在某个位置出错后，try块中剩余的代码都不会被执行，这在某些情况下是不符合预期的，我们可能希望某处出错被捕捉后，剩余的代码能够继续执行。

3. 代码执行的效率，try块范围的大小对代码执行效率几乎没有影响，说“几乎”是因为，try catch对性能还是有一定的影响，那就是try块会阻止java的优化（例如重排序）。当然重排序是需要一定的条件触发。一般而言，只要try块范围越小，对java的优化机制的影响是就越小。所以保证try块范围尽量只覆盖抛出异常的地方，就可以使得异常对java优化的机制的影响最小化。
 

以上结论的来源 参考博文 https://blog.csdn.net/lylwo317/article/details/51869893

 

引申另外两个问题

1. 使用线程池创建线程，如何为每一个线程设置异常处理器

在实践中我们常常使用线程池来管理线程任务。通常提交任务的方式有两种（除了定时任务外）execute，submit（有future返回值）。

如果希望线程在执行出现异常的时候，使用方法2的方式来捕获异常，就需要实现自己的ThreadFactory，为每一个Thread对象都设置异常处理器uncaughtExceptionHandler。但是这种方法只有在以execute提交任务的时候才有效。

对于submit提交的任务，会有一个future返回值，可以通过future的get方法获得最终线程的执行结果或者异常。

2. 使用线程池创建线程，如何对线程分组

针对这两个问题，我打算记在线程池学习的相关博文中