2

我正在使用支持 ScheduledExecutorService 为调度程序开发 API。基本设计，是你向调度器注册一个 Provider 实例，调度器为每个注册的 Provider 维护 ScheduledFuture。Provider 本质上是一个 Runnable，它知道如何检索触发任务。

我遇到的问题是取消预定的未来时该怎么办。取消 ScheduledFuture 的 API 采用布尔参数，允许中断正在触发的 Provider。我认为在 Provider 被杀死时提醒它以及该参数的值是有意义的，因此它可以进行任何必要的清理。

但是，如果您在取消其 ScheduledFuture 之前警告 Provider 实例它正在被杀死，则 Provider 实例可能会通过阻塞来破坏 API，直到它完成执行，而不管该参数的值如何。

另一方面，如果在该值设置为 true 的情况下调用 cancel 并且 ScheduledFuture 在让 Provider 实例知道它被杀死之前被取消，它可能会失去对其执行任何操作的机会。

注意：由于项目的要求，我不能使用 Quartz。否则我只会使用它。请不要回复告诉我使用替代框架，因为我的问题是关于 API 设计的。

有任何想法吗？

4

3 回答 3

4

从技术上讲，这不是 SPI 而不是 API 吗？我认为我们可以期待更多的实施者，所以我会通知他们关闭。作为对冲，我还会确保默认情况下通知不执行任何操作。如果您使用侦听器，请不要自动为此事件注册提供程序。如果您总是调用某个方法，请提供一个对该调用不执行任何操作的抽象基类。

这是我期待更多 SPI 实施者的理由：

如果我想安排一个任务，我会使用 ScheduledExecutor API。作为一名应用程序程序员，我有一个我想要满足的用例，并且我尽量不关心它是如何完成的内部工作原理。因此，我认为 API 通常应该非常防御性地编码。

Provider 显然是一个 SPI。类名“Provider”是一个很大的提示。它确切地知道如何使用它，并且都是关于低级细节的。我正在专门实现它，因为默认实现没有做我想要的。我想要最大程度的灵活性，即使我付出了更多的努力。不应期望应用程序程序员编写一个。不过，他们可能会选择一种实现而不是另一种。

于 2012-05-28T14:27:57.123 回答
0

也许我在这里有误解，但你不是想太多了吗？

如果您想取消将来要运行的任务，因此提供者还没有开始执行工作，为什么需要清理任何东西？

于 2012-05-26T16:26:34.930 回答
0

我强烈推荐使用Quartz-Scheduler而不是自己编写这种服务。它支持取消计划的作业（以及许多其他事情）。

于 2012-05-26T16:38:17.263 回答