Develop Reference

Does Java Timer create a new thread?

I created a Timer object scheduled to run every 1 second and the run method takes 20 seconds to complete. The
Timer.schedule method works as expected: it starts the task immediately after the first task is completed in 20 seconds.
But the Timer.scheduleAtFixedRate method also behaves in the same way. This is what is in the documentation:
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.".
I expect that multiple threads will be spun to catch up, but this is not happening.
How can this be explained? What is a good example to demonstrate the difference between these methods?

Java documentation for the Timer class:
Corresponding to each Timer object is a single background thread that is used to execute all of the timer's tasks, sequentially. Timer tasks should complete quickly. If a timer task takes excessive time to complete, it "hogs" the timer's task execution thread. This can, in turn, delay the execution of subsequent tasks, which may "bunch up" and execute in rapid succession when (and if) the offending task finally completes.
The expectation that additional threads will be created to catch up is incorrect. According to the documentation, Timer tasks should complete quickly. A Timer task should not take 20 seconds to complete. An alternative is the ScheduledThreadPoolExecutor class:
A ThreadPoolExecutor that can additionally schedule commands to run after a given delay, or to execute periodically. This class is preferable to Timer when multiple worker threads are needed, or when the additional flexibility or capabilities of ThreadPoolExecutor (which this class extends) are required.
To answer the second question: The difference is that the schedule method "schedules the specified task for repeated fixed-delay execution" and the
scheduleAtFixedRate method "schedules the specified task for repeated fixed-rate execution". This answer explains this difference well.

yes,Java Timer object can be created to run the associated tasks as a daemon thread.
https://www.geeksforgeeks.org/java-util-timer-class-java/

How to add a timer object to perform every X seconds actions on one thread and every Y sec on the other one?

What is the best approach to make a few threads which perform some action asynchronous on JPanel canvas, and can be controlled form main(...)? What about synchronization techniques?

java.util.Timer works with tasks. Each task has its own scheduling. You can create task per thread and schedule them appropriately. Each task should be able to send signal to its thread (e.g. using notify()).
So, you will achieve this functionality: each task notifies its thread and is scheduled separately. And this system is scalable: timer creates only one own thread, so even if number of your working threads will grow you will have only one additional thread in your system.

Executing some code after a specific amount of time

I need to execute an action after a specific amount of time (for example 30 minutes after the app started up, if the app is still up).
What are my options and will it necessary means there's going to be one thread "lost" waiting for the 30 minutes to pass by?
Ideally, at program startup, I'd like to do something like the following (simplified on purpose) and then don't have to think about it anymore:
doIfStillUp( 30, new Runnable() {
....
});
So how should I go about implementing doIfStillUp(...)?
Should I use a TimerTask? The Executor framework?
Most importantly (it's for understanding purpose): does this mean there's going to be one thread lost idling for basically nothing during 30 minutes?
If there's going to be one thread "doing nothing", is this an issue? What if there are 10 000 threads (I'm being facetious here) "doing nothing"?
Note that I'm trying to understand the "big picture", not to solve a particular problem.

The Executor framework is a reasonable choice.
There's a schedule method that just takes a runnable and a delay time.
schedule(Runnable command,
long delay,
TimeUnit unit)
That's pretty straightforward. There won't necessarily be a thread blocked waiting on your task. You could use a ScheduledThreadPoolExecutor, as linked above that keeps X threads ready to run scheduled tasks.
You can imagine a data structure that holds the time at which a task should be run. A single thread can watch or set up these delays and can potentially watch thousands of them in a single thread. When the first time expires it'll run the task. Potentially using its own thread, potentially using 1 of X in the thread pool. When a new task is added or an existing task is finished it'll wait for the earliest time to arrive and then start the whole process again.

You should use a Timer. Its javadoc answers all your questions.
One thread is used for every timer, but the timer executes several tasks, sequentially. The timer tasks should be very short. If they aren't, consider using several timers.
Of course, the timer thread will be idle if it doesn't have any task to execute. An idle thread doesn't consume anything (or nearly anything), so I wouldn't worry about it. Anyway, you don't have many choices. 10000 threads doing nothing would of course be an issue, but that would mean that you instantiated one timer per task, which is wrong.

You can schedule task on java.util.Timer. For all timer tasks single timer thread will be created by java.util.Timer.

The builtin java timer is the straight away solution: http://download.oracle.com/javase/1,5.0/docs/api/java/util/Timer.html#schedule(java.util.TimerTask, long)

Does ThreadPoolExecutor spawns a new thread if a current thread sleeps

This question is a followup on this one.
Essentially what I am doing is declaring a ThreadPoolExecutor with just one thread. I am overriding the beforeExecute() method to put a sleep so that each of my tasks are executed with some delay among themselves. This is basically to give away the CPU to other threads since my thread is kind of thrashing.
So the expected behavior is:
For each new task in the ThreadPoolExecutor, it calls the before execute function before executing the task and hence it sleeps for say 20s before it executes the task.
However this is what I see:
For each new task submitted:
It executes the task
Calls the beforeExecute method
sleeps for say 20s
RE-EXECUTE the task!
The order of 1. & 2. is not the same all the time.
Here are my questions:
It is appearing that a new thread comes in after/during sleeping and goes ahead and executes my task right away while the actual thread is sleeping.
So does the ThreadPoolExecutor spawn a new thread as soon as an existing thread sleeps [thinking that the thread is terminated]??
I tried to put the keepAliveTime > sleeptime ..so that in case the above assertion is true .. it atleast waits for more than sleep time to spawn a new thread ...[hoping in the mean time the sleeping thread would be awake and the ThreadPoolExecutor would dump the idea of spawning a new thread
Even if it does spawn a new thread and execute my task right away, why would the task be re-executed after the sleeping thread wakes up !! Shouldn't the task be taken out of task Queue before that ??
Am I missing something here ? Any other way to debug this scenario ?
=> An alternative method I was thinking to do the desired task [and not solve the peoblem] was to wrap the runnable with one more runnable and sleep the outer runnable before calling the inner one.

I think what you're looking for is a ScheduledExecutorService
From what I understand of your question, scheduleAtFixedRate(...) should do the deal:
scheduleAtFixedRate(Runnable command, long initialDelay, long period, TimeUnit unit)
Creates and executes a periodic action
that becomes enabled first after the
given initial delay, and subsequently
with the given period; that is
executions will commence after
initialDelay then initialDelay+period,
then initialDelay + 2 * period, and so
on.

No, that is not how it works. The ThreadPoolExecutor knows it has a worker thread, even if that worker is RUNNABLE, WAITING, BLOCKED, or any other state.
The task is removed from the BlockingQueue long before the beforeExecute method is invoked.
You can look at the code for the API yourself and determine what it is doing. Every Java JDK installation includes a "src.zip" file which contains the entire Java Library. If yu haven't already, you can attach this source in eclipse and then while debugging in eclipse diving into a library method will show you source instead of just the class file.

Java thread execution order when using Timer and TimerTask

I'm using Timer as an process interrupt mechanism. The flow of logic is as follows:
T0: create new timer at T0 and schedule a new timer task to execute at T2 (1 second task delay, task is very simple - sets a flag variable)
T1: in the main calling thread, sleep for 5 seconds
T2: in the timer thread, task executes
T5: sleep finishes
T6: cancel timer and any scheduled tasks
The code works perfectly on my Windows and Ubuntu dev environment. But when I run the same code on my SLES 10 build server, logging indicates this execution order:
T0: timer and timer tasks are created to execute at T2
T1: main thread sleeps for 5 seconds
T5: main thread wakes up
T6: timer cancels
T7: task executes
Could anyone offer an explanation as to why this occurs? Thanks very much.

Hm. I'm surprised that you see that much difference (in seconds?), but I guess it is possible that you see different order of execution from machine to machine, jvm to jvm etc. Especially, when the JIT is compiling your code for the first time, I tend to see delay (compared to subsequent execution of same code) in the order of 100-300ms in my code for example, so maybe it's more dramatic in your code?
Not sure what you mean with "process interrupt mechanism". Do you mean that the timer task interrupts some thread?
Anyways, what I can suggest now is to use System.nanoTime() instead. (Although I don't think it will explain anything, Use of System.currentTimeMillis() is discouraged in serious measurements). Addition of -server to your JAVA_OPTS is generally advised so that you see the behavior when the code is optimized by JIT. It is also highly advisable to run your code multiple times and take statistics.
If I were you, I'll do these small things first, then debug using synchronizers like CyclicBarrier, CountdownLatch and see where exactly the delay is coming.
What are the "background noise" (degree of activity) in the SLES? Maybe the OS is very very busy or something?
What is the task's nature? Is it anything network/IO related?

It turned out it was a timestamp issue. Using new Date().getTime instead of System.currentTimeMillis yielded the expected order of execution timestamps.
Thanks for all the good ideas.

You should consider firing an event when the tasks are complete. That ensures execution order.