如何在执行一定次数后停止计划重复执行的 Runnable
情况
我有一个可运行的。我有一个类,它使用带有 scheduleWithFixedDelay。
目标
我想更改此类以安排 Runnable 无限期地进行固定延迟执行,或直到它运行一定次数,具体取决于某个参数传递给构造函数。
如果可能的话,我想使用相同的 Runnable,因为它在概念上是应该“运行”的相同事物。
可能的方法
方法#1
有两个 Runnable,一个在多次执行后取消计划(它会记录计数),另一个则不会:
public class MyClass{
private ScheduledExecutorService scheduler = Executors.newSingleThreadScheduledExecutor();
public enum Mode{
INDEFINITE, FIXED_NO_OF_TIMES
}
public MyClass(Mode mode){
if(mode == Mode.INDEFINITE){
scheduler.scheduleWithFixedDelay(new DoSomethingTask(), 0, 100, TimeUnit.MILLISECONDS);
}else if(mode == Mode.FIXED_NO_OF_TIMES){
scheduler.scheduleWithFixedDelay(new DoSomethingNTimesTask(), 0, 100, TimeUnit.MILLISECONDS);
}
}
private class DoSomethingTask implements Runnable{
@Override
public void run(){
doSomething();
}
}
private class DoSomethingNTimesTask implements Runnable{
private int count = 0;
@Override
public void run(){
doSomething();
count++;
if(count > 42){
// Cancel the scheduling.
// Can you do this inside the run method, presumably using
// the Future returned by the schedule method? Is it a good idea?
}
}
}
private void doSomething(){
// do something
}
}
我宁愿只使用一个 Runnable 来执行 doSomething 方法。将调度与 Runnable 联系起来感觉是错误的。您对此有何看法?
方法#2
使用单个 Runnable 来执行我们想要定期运行的代码。有一个单独的预定可运行对象,用于检查第一个可运行对象已运行多少次,并在达到一定数量时取消。这可能不准确,因为它是异步的。感觉有点麻烦。您对此有何看法?
方法 #3
扩展 ScheduledExecutorService 并添加方法“scheduleWithFixedDelayNTimes”。也许这样的类已经存在了?目前,我正在使用 Executors.newSingleThreadScheduledExecutor(); 来获取 ScheduledExecutorService 实例。我可能必须实现类似的功能来实例化扩展的 ScheduledExecutorService。这可能很棘手。您对此有何看法?
无调度程序方法 [编辑]
我无法使用调度程序。我可以改为:
for(int i = 0; i < numTimesToRun; i++){
doSomething();
Thread.sleep(delay);
}
并在某个线程中运行它。你对此有何看法?您仍然可以使用 runnable 并直接调用 run 方法。
欢迎任何建议。我正在寻找一场辩论,以找到实现我的目标的“最佳实践”方式。
Situation
I have a Runnable. I have a class that schedules this Runnable for execution using a ScheduledExecutorService with scheduleWithFixedDelay.
Goal
I want to alter this class to schedule the Runnable for fixed delay execution either indefinitely, or until it has been run a certain number of times, depending on some parameter that is passed in to the constructor.
If possible, I would like to use the same Runnable, as it is conceptually the same thing that should be "run".
Possible approaches
Approach #1
Have two Runnables, one that cancels the schedule after a number of executions (which it keeps a count of) and one that doesn't:
public class MyClass{
private ScheduledExecutorService scheduler = Executors.newSingleThreadScheduledExecutor();
public enum Mode{
INDEFINITE, FIXED_NO_OF_TIMES
}
public MyClass(Mode mode){
if(mode == Mode.INDEFINITE){
scheduler.scheduleWithFixedDelay(new DoSomethingTask(), 0, 100, TimeUnit.MILLISECONDS);
}else if(mode == Mode.FIXED_NO_OF_TIMES){
scheduler.scheduleWithFixedDelay(new DoSomethingNTimesTask(), 0, 100, TimeUnit.MILLISECONDS);
}
}
private class DoSomethingTask implements Runnable{
@Override
public void run(){
doSomething();
}
}
private class DoSomethingNTimesTask implements Runnable{
private int count = 0;
@Override
public void run(){
doSomething();
count++;
if(count > 42){
// Cancel the scheduling.
// Can you do this inside the run method, presumably using
// the Future returned by the schedule method? Is it a good idea?
}
}
}
private void doSomething(){
// do something
}
}
I would rather just have one Runnable for the execution of the doSomething method. Tying the scheduling to the Runnable feels wrong. What do you think about this?
Approach #2
Have a single Runnable for the execution of the code that we want to run periodically. Have a separate scheduled runnable that checks how many times the first Runnable has run and cancels when it gets to a certain amount. This may not be accurate, as it would be asynchronous. It feels a bit cumbersome. What do you think about this?
Approach #3
Extend ScheduledExecutorService and add a method "scheduleWithFixedDelayNTimes". Perhaps such a class already exists? Currently, I'm using Executors.newSingleThreadScheduledExecutor();
to get my ScheduledExecutorService instance. I would presumably have to implement similar functionality to instantiate the extended ScheduledExecutorService. This could be tricky. What do you think about this?
No scheduler approach [Edit]
I could not use a scheduler. I could instead have something like:
for(int i = 0; i < numTimesToRun; i++){
doSomething();
Thread.sleep(delay);
}
And run that in some thread. What do you think of that? You could potentially still use the runnable and call the run method directly.
Any suggestions welcome. I'm looking for a debate to find the "best practice" way of achieving my goal.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(7)
您可以在 Future 上使用 cancel() 方法。来自 scheduleAtFixedRate
这里是一些示例代码将 Runnable 包装在另一个 Runnable 中,跟踪原始运行的次数,并在运行 N 次后取消。
You can use the cancel() method on Future. From the javadocs of scheduleAtFixedRate
Here is some example code that wraps a Runnable in another that tracks the number of times the original was run, and cancels after running N times.
引用自 API 描述 (
ScheduledExecutorService.scheduleWithFixedDelay
):因此,最简单的事情就是“只是抛出异常”(尽管这被认为是不好的做法):
Quoted from the API description (
ScheduledExecutorService.scheduleWithFixedDelay
):So, the easiest thing would be to "just throw an exception" (even though this is considered bad practice):
到目前为止,sbridges 解决方案似乎是最干净的解决方案,除了您提到的之外,它将处理执行次数的责任留给了 Runnable 本身。它不应该关心这个,相反,重复应该是处理调度的类的参数。为了实现这一目标,我建议采用以下设计,为
Runnables
引入一个新的执行器类。该类提供了两种用于调度任务的公共方法,它们是标准的 Runnables,具有有限或无限重复。如果需要,可以传递相同的 Runnable 来进行有限和无限调度(这对于扩展 Runnable 类以提供有限重复的所有建议解决方案都是不可能的)。取消有限重复的处理完全封装在调度程序类中:公平地说,管理重复的逻辑仍然是 a
Runnable
,但它是 < code>Runnable 完全位于 MaxNScheduler 内部,而为调度传递的Runnable
任务不必关心调度的性质。此外,如果需要,可以通过在每次执行 RunnableWrapper.run 时提供一些回调,轻松地将这个问题转移到调度程序中。这会使代码稍微复杂化,并且需要保留一些 RunnableWrapper 映射和相应的重复,这就是为什么我选择将计数器保留在 RunnableWrapper 类中。设置 self 时,我还在包装器上添加了一些同步。从理论上讲,这是需要的,当执行完成时, self 可能尚未被分配(这是一个相当理论的场景,但只可能重复 1 次)。
取消会被优雅地处理,不会抛出 InterruptedException,并且如果在执行取消之前安排了另一轮,则 RunnableWrapper 不会调用底层的 Runnable< /代码>。
So far sbridges solution seems to be the cleanest one, except for what you mentioned, that it leaves the responsibility of handling the number of executions to the
Runnable
itself. It should not be concerned with this, instead the repetitions should be a parameter of the class handling the scheduling. To achieve this, I would suggest the following design, that introduces a new executor class forRunnables
. The class provides two public methods for scheduling tasks, which are standardRunnables
, with finite or infinite repetition. The sameRunnable
can be passed for finite and infinite scheduling, if desired (which is not possible with all proposed solutions that extend theRunnable
class to provide finite repetitions). The handling of canceling finite repetitions is completely encapsulated in the scheduler class:To be fair, the logic of managing the repetitions is still with a
Runnable
, but it'a aRunnable
completely internal to theMaxNScheduler
, whereas theRunnable
task passed for scheduling has to not concern itself with the nature of the scheduling. Also this concern could be easily moved out into the scheduler if desired, by providing some callback every timeRunnableWrapper.run
was executed. This would complicate the code slightly and would introduce the need of keeping some map ofRunnableWrapper
s and the corresponding repetitions, which is why I opted for keeping the counters in theRunnableWrapper
class.I also added some synchronization on the wrapper when setting the self. This is needed as theoretically, when the executions finish, self might not have been assigned yet (a quite theoretical scenario, but for only 1 repetition possible).
The cancelling is handled gracefully, without throwing an
InterruptedException
and in case before the cancel is executed, another round is scheduled, theRunnableWrapper
will not call the underlyingRunnable
.这是我的建议(我相信它可以处理问题中提到的所有情况):
此外,它允许外部方停止
submit()
Future 中的所有内容> 方法。用法:
Here is my suggestion (I believe it handles all cases mentioned in the question):
In addition, it allows an external party to stop everything from the
Future
returned by thesubmit()
method.Usage:
对于轮询直到某个超时的用例,我们可以使用
Future.get()
采用更简单的解决方案。For use cases like polling until a certain timeout, we can approach with a simpler solution using
Future.get()
.你的第一种方法似乎没问题。您可以通过将
mode
对象传递给其构造函数(或传递 -1 作为其必须运行的最大次数)来组合两种类型的可运行对象,并使用此模式来确定是否必须取消可运行对象or not :您必须将计划的未来传递给您的任务才能使其自行取消,否则您可能会引发异常。
Your first approach seems OK. You could combine both types of runnables by passing the
mode
object to its constructor (or pass -1 as the max number of times it must run), and use this mode to determine if the runnable must be canceled or not :You'll have to pass the scheduled future to your task in order for it to cancel itself, or you might throw an exception.
我一直在寻找完全相同的功能并选择了 org.springframework.scheduling.Trigger。
以下是完整测试的工作示例(抱歉,如果代码过多)
应用程序上下文.xml
JAVA
I've been looking for exact same functionality and chose
org.springframework.scheduling.Trigger
.Below is full-test working example (sorry if too much flood in code)
applicationContext.xml
JAVA