Last week I needed to generate (somewhat) high-frequency recurring events in Java for my thesis work. Nothing like real time, just call a method from 10 to 1000 times per second, but I want to able to tune it so it can run at a precise frequency in this interval. Should be easy, right? In theory it is: discover the period of recurrence, do the action, sleep the remaining time until the next occurrence. For example: if I want to generate 500 events per second and my action takes 200µs, then my period is 2ms and I must sleep 1800µs between executions.
So, I need microsecond precision for the sleep. It is widely known that this is impossible in Java 1.4 without some native code. Fortunately, in Java 5 it's pretty easy to get nanosecond precision and this blog entry is very, very informative. Briefly, if you want to measure a time delta with nanosecond precision use System.nanoTime(), if you want to schedule a (possibly recurring) event with the same precision use the ScheduledThreadPoolExecutor class. I ended up using the former for my code.
But now, the weird part. Along with System.nanoTime(), Java 5 introduced the Object.wait(millis, nanos) and Thread.sleep(millis, nanos) methods for high resolution sleeps. Take a look at the source code for the implementation of these methods here (gotta love free software!). See. These methods just round up or down the millisecond argument using the nanosecond argument and call the millisecond only version of the methods. It took me some time and a bit of frustration to notice this. Annoying. You might be wondering: how the heck is ScheduledThreadPoolExecutor implemented then? The answer is another sleep method introduced in Java 5: LockSupport.parkNanos. This one actually works, as it uses a different native implementation.