1

我在我的一个 Android 组件中使用 Java ThreadPoolExecutor。我的问题是：

在对 TPE 执行一些任务后使用 setRejectedExecutionHandler() 设置 RejectedExecutionHandler 是一个好习惯吗？

我的意思是这样做有什么副作用。这是一个好习惯吗？

已编辑

我需要在 Android 中创建一个可供其他项目使用的 ThreadPoolManagementLibrary 项目。现在，我需要在我的组件中公开 TPE 的公共方法。如果我让用户设置 RejectedExecutionHandler 那么会有问题吗？

4

3 回答 3

3

问题应该是“我们应该处理 RejectedExecutionException 吗？”。答案当然是肯定的。不这样做会使发生它的线程崩溃，即提交任务执行的线程，应用程序将继续在未知状态下运行。

第二个问题是“我们应该如何处理这个异常？”。我们应该尽可能干净地停止应用程序。由于其他运行时异常（顺便说一下，还有错误）也是如此，因此一种解决方案是使用 UncaughtExceptionHandler。但是如果我们想以特定的方式处理 RejectedExecutionException，我们可以使用 RejectedExecutionHandler。这可用于在停止应用程序之前进行一些特定的处理（直接或通过抛出将被 UncaughtExceptionHandler 捕获的新 RuntimeException）。

这里的要点是应该处理所有异常和错误。这违背了所谓的“最佳实践”，但这些实践是错误的。对于单线程应用程序，它们曾经是正确的。世界变了。运行时异常或错误将使发生它的线程崩溃，而不是应用程序。所以它必须被处理。

当然，如果您使用的是框架或应用程序服务器，问题可能会有所不同，因为该服务器或框架可能会为您处理未捕获的异常。

于 2014-10-24T13:16:54.410 回答
2

我不这么认为。让我们尝试了解 RejectedExecutionHandler 的作用？

当您向 ThreadPoolExecutor 提交任务时，会发生以下事件序列：

  • 如果有任何空闲的工作线程是空闲的并且可以运行这个任务。
  • 否则，它会尝试将此任务移动到工作队列，如果它是空闲的，工作线程将从那里获取任务。
  • 如果 workerQueue 也已满，那么它会尽可能尝试创建一个新线程（工作线程的数量不小于 maxPoolSize）。
  • 如果上述所有方法都失败，则任务将发送到处理程序，并且默认处理程序会抛出 RejectedExecutionException。

所以基本上，如果您允许用户设置自己的处理程序，那么您就可以让他们自由地以自己的方式处理被拒绝的任务。他们在实施时应该小心。

于 2013-09-06T23:47:49.247 回答
0

我也同意 @user2120553 。@Braj Kishore 提到的所有观点都是正确的，但我想提一下，如果我们声明我们的习惯，RejectedExecutionHandler那么我们肯定会有机会重试执行。

于 2014-12-28T19:23:09.057 回答