Rules for good java.util.Timer use

6

Many people have probably used Timer for some quick one-off timer tasks where using a whole library like Quartz don’t make sense.

One thing to be aware of is that Timer’s constructor will start and spawn a thread. This is a recipe for trouble if you use Timer too casually.

Two good rules of thumb for the use of Timer are:

  1. Always start your Timer as a daemon thread. By default, new Timer() and other constructors use a non-daemon thread which means that the Timer will stick around forever and prevent shutdown. That may be what you expect, but I doubt it.
  2. Always name your Timer. That name is attached to the Timer background thread. That way, if you do something dumb, and look at a thread dump, it will be exceedingly obvious when you’ve started 500 FooBarCleanupThreads.

Comments

6 Responses to “Rules for good java.util.Timer use”
  1. Sean Blakey says:

    Better still, don’t use Timer. It runs with a single Timer thread, so overlapping executions will be delayed. Even worse, is an exception is thrown, the underlying thread breaks.

    Use java.util.concurrent.ScheduledExecutor instead.

  2. Patrick Wright says:

    I just set up a cleanup process using the ScheduledExecutorService from java.util.concurrent–I like this better than the old Timer. What do you think? When would you use Timer (outside of being stuck on an old JDK).

    Cheers
    Patrick

  3. Holger Hoffstätte says:

    Agree with Sean – the best way to use Timer is “not”. Unfortunately STPE has its own problems, e.g. fact that the fixed number of threads needs to be determined up front, and that timed event threads are also by themselves worker threads. There is a good intention for this (no unbounded load peaks when too many events fire at once), but usually it is much better to delegate to a real Executor and e.g. coalesce timer overruns for a given task by using a custom TimedRunnable wrapper. Timer cannot be extended easily at all.
    I should probably blog about this ;)

  4. +1 for ScheduledExecutor simply for the exception handling.

    Be aware of the slight differences though… on my platform we observed that a 1 second Timer would post events every 1000 to 1020 ms, while ScheduledExecutor posts every 990-1010 ms. You can imagine what happened when a poor programmer tried to convert the milliseconds to seconds using an integer… 990 / 1000 == 0, dontcha know.

  5. robert says:

    Great tips…

    I don’t know if this is the right forum to ask questions,
    but, I am taking a simulation course and I was asked to simulate a parking lot, would it be better to use the timer to trigger each event (which is a random time) of the car (arrival, wait for a ticket, parked time, wait for cashier) or to use ScheduledExecutorService, taking into consideration that the maximum number of cars is 1000.

    Thanks in advanced,

  6. Timer has limited scheduler functionality compared to quartz scheduler.

    Your tips are good for beginners. In real time,

    How do we create a timer as daemon thread.