I have the following while loop:
while (keepRunning) {
if (!once) {
// Run a test method every 30th second
// Run the new calculations from the database
new CalculatorDriver().run();
// Wait in the while loop for 1 second before looping again
TimeUnit.SECONDS.sleep(1);
}
}
This while loop will loop every second through the code, but now I want to run a method called: getNewCalculations() every 30th second of a minute, so for example, the method needs to run at:
18:26:30
18:27:30
18:28:30
I already found a way to run a method every x seconds:
Timer timer = new Timer();
timer.schedule(new Task(), 60 * 1000);
But I also need to start it at a specific point. In C# someone tried this to run a script every 30th and every 0th second: https://stackoverflow.com/a/53846390/10673107.
I could just add an if where the second can't be equal to 0, but I was wondering if there was a better way to do this.
How can I run it only in the 30th second?
Set an initial delay by calculating the number of seconds to wait until the next 30th second is due to arrive. If the current moment is :10, wait 20 seconds. If the current moment is :56, wait 34 seconds.
The Duration class may help with that, along with ZonedDateTime class.
If you read the Javadoc for Timer/TimerTask you will learn those classes were supplanted years ago by the Executors framework that arrived in Java 5.
Use a ScheduledExecutorService to schedule a task to run after an initial delay specified by you. After the initial delay, specify a repeating period of one minute.
Your task will then be repeating on the 30th second mark of every minute. Know that this scheduling is approximate. The host OS, the JVM’s internal scheduler, and garbage-collection all impact when the task actually runs. So each run may vary.
Or, if you want to protect against any politician-imposed anomalies on your region’s time-keeping, schedule only a one-time scheduled task rather than repeating task. Pass to that task a reference to the ScheduledExecutorService object. The task can then schedule its own next run after running the initial-delay calculation again.
Be sure to eventually shutdown your executor service. Otherwise its backing pool of threads may continue to run indefinitely even after your app ends, like a zombie 🧟♂️.
Be aware that any exception or error bubbling up to the scheduled executor service will silently halt any further scheduling.
All of these topics have been addressed many times already on Stack Overflow. Search to learn more.
Related
I have a Timer class that I want to schedule to run for 30 minutes and for it to execute every hour from Saturday at 12AM to Sunday at midnight.
How would I go about doing this?
Thanks.
The java.util.Timer class does not have the functionality to do this using repeated tasks:
You cannot configure a Timer to >>stop<< running repeated tasks at a given time
The execution model for repeated tasks is "fixed-delay execution"; i.e. a new task is scheduled based on the end-point of the previous task. That results in time slippage ... if tasks take a long time.
The simple solution is:
create a single Timer object
use schedule(TimerTask task, Date time) in a loop to schedule 48 separate tasks, starting on each hour in the range that you require.
According to the javadoc, Timer is scalable and should be able to cope with lots of scheduled tasks efficiently.
The above does not deal with the requirement that each task runs for 30 minutes. It is not clear what that actually means, but if you want the task to run for no more than 30 minutes, then you need to implement a "watch dog" that interrupts the thread running the task when its time is up. The task needs to be implemented to check for and/or handle thread interrupts appropriately.
You could have a loop run and in the loop just sleep for an hour or however long you wanted. Would something like this work?
for(int i = 0; i < 24; i++) {
// do whatever you want to do
try {
// Sleep for an hour
Thread.sleep(6000000);
catch(InterruptedException e) {
e.printStackTrace();
}
}
I might have misunderstood the question... but if that's what you wanted.. then... yay?
I have been going through some of the SO questions about doing something after a specific interval of time (like printing hello world every five seconds).
I saw different ways that we can do it in a java program. my question is how java does this internally.
Once we run a java program, the main function starts executing in a thread. But this thread can be sent to Runnable state anytime(pause the execution). So if I had stated the print statement in the main function, how does java keep track of time now. what if the java program was not resumed for the next five seconds?
One way this could work is if we meant "every 5 seconds in the time period which the java program is running" . Is that how the JVM does this?
Assume that I have a single processor.
Ok, lets trace the calls. If we are using ScheduledThreadPoolExecutor we can find that it uses DelayedWorkQueue internally:
super(corePoolSize, Integer.MAX_VALUE, 0, TimeUnit.NANOSECONDS,
new DelayedWorkQueue());
To await next tasks DelayedWorkQueue uses Condition available = lock.newCondition():
available.awaitNanos(delay);
Ok, lets take a look at awaitNanos implementation in AbstractQueuedSynchronizer:
LockSupport.parkNanos(this, nanosTimeout);
And the LockSUpport:
unsafe.park(false, nanos);
This is native method which uses operating systems's scheduler to delay thread execution.
I have started timer with fixed rate. When user change system Time at that time task is executed continuously.It doesn't consider about the period time. How to manage this.
timer.scheduleAtFixedRate(task, delay, period);
Note : Now system time is current time.Period is 30 seconds. Now user change system time into after 10 mins from current time.At that time timer task not consider about the period. Within a second it execute the task 20 times.
When I use
timer.schedule(task, delay, period);
instead of
timer.scheduleAtFixedRate(task, delay, period);
task working normally. If I change system time to 10 mins past time from now task doesn't executed...
How to solve this ? :(
Have a look at this Stack Overflow answer; long story short, using scheduleAtFixedRate will queue up the tasks you have scheduled and fire them relative to the system time that the task was first queued; if anything should delay these tasks from firing, they will play 'catch up' and fire as fast as they can. So in your example of how changing the system time to +10 minutes made the event fire 20 times make since given that your period is 30 seconds (1m/2 = 30s, 10m*2 = 20 events).
Using the schedule function has similar issues, except it does not play 'catch up'; if you had a timer set to fire off every 30 seconds, then change the system time to +10 minutes only 10 seconds after the timer has started, your first event will trigger, then continue to wait the 30 second delay and fire again (unless you change the system clock again).
If you want something that is independent of system time you'll need monotonic clock values. To my knowledge the Java API does not directly contain any monotonic timers (for numerous reasons), but that doesn't stop you from implementing one yourself (albeit at the cost of possible wasted execution time in custom timer class code). Here's a Stack Overflow question regarding this, as well as a Google Group discussion post on it.
If you're really hard pressed for using a monotonic timer you could potentially use the POSIX API's and do some Java->C JNI work.
I hope that can help (at least point in a solid direction).
ScheduledExecutorService seems to have the problem that if it can't get a free thread the periodic task will happen with delay. Unfortunately for me, the periodic task it's assigned to really does need to happen fairly on schedule. At present it's scheduled for once per minute but sometimes due to the application being busy with other things (I assume this is why) it fails to make it within five minutes, and five minutes happens to be the "major production bugs" threshold.
How to force this via prioritizing or otherwise controlling the thread balancer?
If your ScheduledExecutorService is used for other tasks or if your task sometimes takes more than 1 minute to run, you can simply increase the number of threads available in your ScheduledExecutorService. So if one task has not finished running, the executor will still be able to run a new one.
ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(10);
(I picked 10 randomly - if you run your task every minute and it can run for up to 5 minutes, that leaves you some margin for error)
I am working on a Java program and using Timer objects to run tasks every few minutes or hours. This works fine in normal operations, but I am running into a problem with "Sleep mode" on Mac (maybe on other OSes, but I haven't tried yet).
Consider this code sample:
//Setup the timer to fire the ping worker (every 3 minutes)
_PingTimer.scheduleAtFixedRate(new TimerTask(){
public void run(){
Program.PingThread = new PingWorker(Settings.Username, Settings.UserHash, true, true);
Program.PingThread.CheckOpenPort = true;
Program.SwingExecutor.execute(Program.PingThread);
}
}, 0, 180000);
In normal operation this would fire every 3 minutes with enough accuracy (I'm not concerned about the exact second or anything). The problem with this is after sleeping the computer for a few hours or so it seems to just BLAST the system with backlogged timer requests.
It seems to be running all of the missed timer hits during sleep at once trying to make up for lost time.
Is there a way i can prevent this? I tried using synchronized and some other thread techniques, but this only ensures that they aren't all running at the same time. They still continue to run one after another until the backlog is passed.
Thanks for any help you can provide!
Have you looked at the API? It clearly states the following:
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).
This is one reason why you should consider using a ScheduledExecutorService. This link may also prove useful.
Use schedule instead of scheduleAtFixedRate.