I know that I must use this instead of java.util.Timer because of various reasons. So, to study this I was looking at the docs and I have a few questions:
How does scheduleWithFixedDelay() work ? My understanding is this: It first executes a task after a given delay. Once the task is done, it waits for the specified time and then executes the task again.
What happens when I submit a task to scheduleAtFixedRate() that takes a lot more time to execute than the specified delay ? Like I want the task to execute every 5 seconds but it takes 10 seconds to complete. My understanding is that the task will be held in a queue and will be executed once a core thread is available
Here is my understanding of how scheduleWithFixedDelay() and scheduleAtFixedRate() differ: scheduleWithFixedDelay() waits for the task to finish executing, waits for the specified time and then fires the task again where as scheduleAtFixedRate will just keep firing the task without caring if it has completed or not. Correct?
Correct.
Not quite. If a fixed-rate task takes longer than its period, it will run again immediately upon completion, but the next run is not waiting for a thread. See below.
A fixed-rate task does care whether its previous run has completed, just like a fixed-delay task. Per the documentation, "If any execution of this task takes longer than its period, then subsequent executions may start late, but will not concurrently execute."
Think of it this way:
For a fixed-delay task, you specify a period which will be the exact amount of time between runs. The actual duration of the task has no effect on the delay.
For a fixed-rate task, you specify a period which will be the maximum amount of time between runs. If the actual duration of the task is longer than the period, the rate is reduced, and there is effectively no delay.
Related
Question about ScheduledExecutorService.shceduleAtFixedRate - I schedule taskA to run every 500 millis, which blocks for 1000 millis. Now subsequent executions aren't gonna wait the extra 500 millis, but rather commence immediately after the previous one.
taskA acquires an intrinsic lock, which is also (attempted) acquired by a different thread. Since intrinsic locks have no fairness guarantees this thread is running a risk of starvation, so here's my question: Is there a good/clean way to avoid this risk? E.g. schedule the task to run every 1500 millis (doesn't sound very waterproof)? Or do we expect the lock acquisition to exhibit a kind of "amortized fairness"?
Yes, you can use scheduleWithFixedDelay:
Creates and executes a periodic action that becomes enabled first after the given initial delay, and subsequently with the given delay between the termination of one execution and the commencement of the next. If any execution of the task encounters an exception, subsequent executions are suppressed. Otherwise, the task will only terminate via cancellation or termination of the executor.
So the delay you give is the time between end of last end start of next - ie no overlap between runs.
I was trying some codes to implement a scheduled task and came up with these codes .
import java.util.*;
class Task extends TimerTask {
int count = 1;
// run is a abstract method that defines task performed at scheduled time.
public void run() {
System.out.println(count+" : Mahendra Singh");
count++;
}
}
class TaskScheduling {
public static void main(String[] args) {
Timer timer = new Timer();
// Schedule to run after every 3 second(3000 millisecond)
timer.schedule( new Task(), 3000);
}
}
My output :
1 : Mahendra Singh
I expected the compiler to print a series of Mahendra Singh at periodic interval of 3 s but despite waiting for around 15 minutes, I get only one output...How do I solve this out?
Advantage of ScheduledExecutorService over Timer
I wish to offer you an alternative to Timer using - ScheduledThreadPoolExecutor, an implementation of the ScheduledExecutorService interface. It has some advantages over the Timer class, according to "Java in Concurrency":
A Timer creates only a single thread for executing timer tasks. If a
timer task takes too long to run, the timing accuracy of other
TimerTask can suffer. If a recurring TimerTask is scheduled to run
every 10 ms and another Timer-Task takes 40 ms to run, the recurring
task either (depending on whether it was scheduled at fixed rate or
fixed delay) gets called four times in rapid succession after the
long-running task completes, or "misses" four invocations completely.
Scheduled thread pools address this limitation by letting you provide
multiple threads for executing deferred and periodic tasks.
Another problem with Timer is that it behaves poorly if a TimerTask throws an unchecked exception. Also, called "thread leakage"
The Timer thread doesn't catch the exception, so an unchecked
exception thrown from a TimerTask terminates the timer thread. Timer
also doesn't resurrect the thread in this situation; instead, it
erroneously assumes the entire Timer was cancelled. In this case,
TimerTasks that are already scheduled but not yet executed are never
run, and new tasks cannot be scheduled.
And another recommendation if you need to build your own scheduling service, you may still be able to take advantage of the library by using a DelayQueue, a BlockingQueue implementation that provides the scheduling functionality of ScheduledThreadPoolExecutor. A DelayQueue manages a collection of Delayed objects. A Delayed has a delay time associated with it: DelayQueue lets you take an element only if its delay has expired. Objects are returned from a DelayQueue ordered by the time associated with their delay.
Use timer.scheduleAtFixedRate
public void scheduleAtFixedRate(TimerTask task,
long delay,
long period)
Schedules the specified task for repeated fixed-rate execution, beginning after the specified delay. Subsequent executions take place at approximately regular intervals, separated by the specified period.
In fixed-rate execution, each execution is scheduled relative to the scheduled execution time of the initial execution. If an execution is delayed for any reason (such as garbage collection or other background activity), two or more executions will occur in rapid succession to "catch up." In the long run, the frequency of execution will be exactly the reciprocal of the specified period (assuming the system clock underlying Object.wait(long) is accurate).
Fixed-rate execution is appropriate for recurring activities that are sensitive to absolute time, such as ringing a chime every hour on the hour, or running scheduled maintenance every day at a particular time. It is also appropriate for recurring activities where the total time to perform a fixed number of executions is important, such as a countdown timer that ticks once every second for ten seconds. Finally, fixed-rate execution is appropriate for scheduling multiple repeating timer tasks that must remain synchronized with respect to one another.
Parameters:
task - task to be scheduled.
delay - delay in milliseconds before task is to be executed.
period - time in milliseconds between successive task executions.
Throws:
IllegalArgumentException - if delay is negative, or delay + System.currentTimeMillis() is negative.
IllegalStateException - if task was already scheduled or cancelled, timer was cancelled, or timer thread terminated.
public void schedule(TimerTask task,long delay)
Schedules the specified task for execution after the specified delay.
you want:
public void schedule(TimerTask task, long delay, long period)
Schedules the specified task for repeated fixed-delay execution, beginning after the specified delay. Subsequent executions take place at approximately regular intervals separated by the specified period.
timer.scheduleAtFixedRate( new Task(), 1000,3000);
I have a question regarding the scheduleAtFixedRate() method on ScheduledExecutorService in Java 6.
[edit: the Javadoc for 1.6 is more complete than that for 1.5. See comment below]
Given that:
the ScheduledExecutorService is constructed with N = 1 thread in the pool
the fixed-rate is a period of T seconds
no initial delay
What happens in this case (times are not meant to be absolute, in the real-time sense):
at time T, the service kicks off a Runnable task, "task1"
at time 2T, task1 has not yet completed, and service is scheduled to fire
Is the service guaranteed to do any of the following?
(a) at 2T, kick off a Runnable task, "task2" (recall N = 1)
(b) block until task1 is finished
(c) skip this time and try again at 3T
(d) behavior is undefined
Or something else? Does the answer change if N > 1 ?
The answer is
(b) block until task1 is finished
and that is regardless of number of threads of the executor (task2 might even be not submitted).
The doc says:
If any execution of this task takes longer than its period, then subsequent executions may start late, but will not concurrently execute.
(BTW, since there's no intial delay, "task1" will kickoff right away as doc`ed:
executions will commence after initialDelay
).
From the documentation that you linked...
If any execution of this task takes longer than its period, then subsequent executions may start late, but will not concurrently execute.
I have a task that needs to be executed on a schedule. (It basically polls a database looking for a change and then executes code depending on the result). The problem is that I need the polled task to happen even when it is already executing.
So far I have tried using a Timer/TimerTask combo with the scheduleAtFixedRate() method and the ScheduledThreadPoolExecutor/Thread combo with the scheduleAtFixedRate() method.
Both wait for the current scheduled task to complete before running the next. I need to be able to schedule a task to run every 5 seconds and have it run even if the last execution of the task has not yet completed.
Any ideas?
How about using one Timer as the "kick-off" timer, but then a separate thread pool for execution: when the timer ticks, you submit the task to the thread pool for immediate execution. (You may want to tweak the thread pool to have some maximum number of tasks running simultaneously.)
I am having this problem, I have
private ScheduledExecutorService executor =
Executors.newSingleThreadScheduledExecutor();
and task which is created every 50 millliseconds:
executor.scheduleAtFixedRate(myTask, 0, 50, TimeUnit.MILLISECONDS);
myTask sometimes take a while to complete (like 2-3 seconds or so), but newSingleThreadScheduledExecutor guarantees that next scheduled myTask will wait until the current one completes.
However, I get this error from time to time:
execute: java.util.concurrent.RejectedExecutionException
What should I do? Thanks
Consider what the executor is doing. It is running a single task every 50 milliseconds, as per your instructions. Assuming this task takes less than 50 milliseconds to run, then everything is fine. However, every so often it takes 2-3 seconds to run. When this happens, the executor still tries to execute every 50 milliseconds, but because it only has a single thread, it can't, and rejects those executions that are being triggered while your long-running task is still going. This causes the exception you see.
You have two choices to fix this (assuming you want to stick with a single thread):
Use scheduleWithFixedDelay rather than scheduleAtFixedRate. If you read the javadoc carefully, you'll see that scheduleWithFixedDelay will wait 50 milliseconds between the finishing of one task and the start of the next, so it will never "overlap", even if one of them takes a long time. In contrast, scheduleAtFixedRate will try to execute every 50 milliseconds, regardless of how long each one takes.
Change the way that the executor handles failures to execute. The default is to log an exception, but you can tell it to ignore it, for example. Take a look at the subclasses of of java.util.concurrent.RejectedExecutionHandler, for example DiscardPolicy, which just silently drops the task that can't be run. You can use these by directly constructing ScheduledThreadPoolExecutor and passing in the handler to the constructor, rather than using the Executors factory class.
I suspect option (1) is what you want.
This exception will be thrown when either:
You have shutdown the Executor
The Executor's bounds for its work queue or maximum threads have been exceeded.
I assume the latter is happening. When you execute your task and it takes a long time then subsequent scheduled tasks can not be run because there are not enough threads available in the pool.
Either:
Use use a larger pool size or use cachedThreadPool
Change the rejection policy to for example use ThreadPoolExecutor.CallerRunsPolicy
Create a separate Executor for running the long run tasks and run these from your scheduled task. In actual fact you can do this using the same Executor instance providing that you increase the pool size.
See also ThreadPoolExecutor javadoc
With Java 7 both of them will wait till the first execution is ready and then start the next!
check here:
http://download.java.net/jdk7/archive/b123/docs/api/java/util/concurrent/ScheduledThreadPoolExecutor.html
or here:
http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ScheduledThreadPoolExecutor.html