Java Timer VS Executorservice

Java Timer vs ExecutorService?

According to Java Concurrency in Practice:

• Timer can be sensitive to changes in the system clock, ScheduledThreadPoolExecutor isn't.
• Timer has only one execution thread, so long-running task can delay other tasks. ScheduledThreadPoolExecutor can be configured with any number of threads. Furthermore, you have full control over created threads, if you want (by providing ThreadFactory).
• Runtime exceptions thrown in TimerTask kill that one thread, thus making Timer dead :-( ... i.e. scheduled tasks will not run anymore. ScheduledThreadExecutor not only catches runtime exceptions, but it lets you handle them if you want (by overriding afterExecute method from ThreadPoolExecutor). Task which threw exception will be canceled, but other tasks will continue to run.

If you can use ScheduledThreadExecutor instead of Timer, do so.

One more thing... while ScheduledThreadExecutor isn't available in Java 1.4 library, there is a Backport of JSR 166 (java.util.concurrent) to Java 1.2, 1.3, 1.4, which has the ScheduledThreadExecutor class.

Difference between TimerTask and Executors.newScheduledThreadPool(1)

The biggest difference is that the Timer will schedule all of its tasks on a single background thread. The ExecutorService, on the other hand, will create new threads (if necessary) to run the tasks (up to the size of the pool you specify, at which point tasks will be queued.)

ExecutorService vs Swing Timer

Well the Swing Timer at least runs on the EDT so you do not have to wrap everything with calls to invokeLater. It also ties nicely in with Swing as it uses Actions, ActionListeners and other Swing related classes.

I'd stick with Swing Timer for Swing related tasks and use the new concurrent package for things that does not involve updating the GUI.

Have a look at Using Timers in Swing Applications as it might contain more information to swing (sorry) the decision.

Running ExecutorService inside scheduled method

How it is spread over CPU cores depends also of how the operating system is busy, but let's say nothing else happen, each CPU core is able to execute one thread. If there are more active threads than CPU cores, the operating system is responsible for dispatching CPU time among the threads.

On your example, one thread will execute the @Scheduled method, which is quite fast because it does not do much, just submit a new action to the executor service.

Then the executor service, which has up to 20 threads, will execute the action on the first available thread among the 20.

So the answer is yes, the actions will be done in parallel.

You can try by scheduling very often your method, let's say every second:

@Scheduled(cron = "* * * ? * *")

Then do something longer than 1 second in your action (else the action will finish before the next schedule). You will see actions doing the job in parallel.

By the way, why not to use a ScheduledExecutorService ? Or configure spring to use several threads ?

TimerTask vs Timer vs Thread?

A Timer is used to run a task (i.e: TimerTask) on an interval, after a delay, or a combination of the two. In your case, you can use something like this:

   java.util.Timer timer = new java.util.Timer();
    timer.schedule(new TimerTask() {
        public void run() {
//            do task
        }
    }, 0, 1000);  //updates every second

Note that in order to update a Swing component in a thread other than the Swing thread, you'll need to use a SwingWorker (see Swing Concurrency Tutorial), or user a Swing Timer instead. The code below is using a Swing timer to update the label with a new date every second:

javax.swing.Timer timer1 = new javax.swing.Timer(0, new ActionListener() {

        @Override
        public void actionPerformed(ActionEvent e) {
            label.setText(new Date());
        }
    });

    timer1.setRepeats(true);
    timer1.setDelay(1000);

I haven't tested this, so you may need to tweak it a little to work for you.

---

Related Topics