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

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

1, Java中的异常之RuntimeException

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

1.1 运行时异常的概念

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

1.2 常见的运行时异常

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

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

EventBus.getDefault().unregister(object);

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年之后我再回头看看自己曾写过的文章，会不会有点感悟？当然时间会告诉我答案。用我喜欢的苏东坡的一首诗里面的一句话：“人生到处知何似，应是飞鸿踏雪泥。泥上偶然留指爪，鸿飞那复计东西。”希望在以后的岁月回顾起曾经的自己，像飞鸿在泥上留下指爪一样，给自己留一些东可以思量和回忆的东西。