ExecutorService的submit方法使用过程中的坑和源码剖析

最近在项目中集成了LeakCanry 来检测项目中出现内存泄漏，结果发现了EventBus 导致的内存的泄漏，然后引出了ExecitorService 的submit方法会catch掉所有的异常的问题（包含运行时异常）。

1, Java中的异常之RuntimeException

下面的链接是关于Runtime Exception 的描述：

https://www.tutorialspoint.com/how-to-handle-the-runtime-exception-in-java

1.1 运行时异常的概念

运行时异常是Java编程语言的所有的异常的父类；当运行时异常
发生的时候，程序或者应用应该崩溃。跟其他的不是运行时异常不同，运行时异常永远不会被检查。
运行时异常通常显示程序员的错误，而不是程序处理的条件。当一个条件不能发生的时候,运行时的异常也会被使用到。应该注意的是：当让一个程序的内存用完了，一个程序的错误会被抛出而不是显示运行时异常。

1.2 常见的运行时异常

下面是常见的运行时异常：
NullPointerException
ArrayIndexOutOfBoundsException
InvalidArgumentException
IllegalArgumentExeception

1.3 使用ExecutorService 的submit 方法之后导致，运行时的异常被catch 的问题

下面的截图是：

上面LeakCanry 扫描应用得到了关于EventBus没有解注册而导致了内存的泄漏，正常的代码的逻辑肯定是有解绑的操作。现在出现的问题就是为什么下面的解绑的操作没有被调用到：

EventBus.getDefault().unregister(object);

这段代码是在ExecutorService 的submit方法里面调用的，通过推理，我们很容易得到，在这个方法里面在EventBus 解绑之前可能抛出了运行时的异常，从而导致在抛出异常之后的代码未被执行。下面的截图果然验证我的猜想:

结果应用层抛出了IllegalArgumentExeception.那么现在的问题来了，在运行时异常的概念里面我们知道，发生了运行时的异常时，应该程序应该会崩溃才对，为什么这里发生了运行时异常，程序没有崩溃？研究了ExecutorService的源码之后，这个疑问就得到解决了。

2,ExecutorService 方法的源码剖析

首先我们使用Navigate工具栏的Type Hierarchy 工具查看ExecutorService 的继承的关系：

ExecutorService 的submit 方法最后调用的是AbstractExecutorService 的submit方法：

newTaskFor方法返回的是一个FutureTask 对象。

FutureTask被执行的时候，调用的是FutureTask 的run 方法，如下图所示

结果里面的异常被setExecption 方法吸收掉了，并没有抛出来。所以出现了上面的问题。即IllegalArgumentExeception被ExecutorService 的submit方法Catch了。

3,总结

使用ExecutorService 的时候尽量优先使用execute方法替代submit 方法，避免submit方法try catch 掉运行时异常，从而导致内存泄漏等等问题。ExecuteService 使用了execute方法之后，应用就会崩溃，出现下面的界面，我们只需要解决代码的错误即可解决。

后记：最近看了刘未鹏的《暗时间》一书，就下定决定自己加入写博客的行列。书中有一句话说的很好：“写是更好的一种思考的方式。”我们常常把思考挂在嘴边，却从未去反思自己：何为思考？何为更好的思考方式。读了《暗时间》之后我找到了答案：用心写作，至少坚持8年。我想8年之后我再回头看看自己曾写过的文章，会不会有点感悟？当然时间会告诉我答案。用我喜欢的苏东坡的一首诗里面的一句话：“人生到处知何似，应是飞鸿踏雪泥。泥上偶然留指爪，鸿飞那复计东西。”希望在以后的岁月回顾起曾经的自己，像飞鸿在泥上留下指爪一样，给自己留一些东可以思量和回忆的东西。