How expensive is Thread.sleep() in Java?

Question

I'm writing some code and wondering if its bad design to throttle a loop by calling Thread.sleep(10) at the beginning of each iteration. My other option is calling Thread.sleep fewer times at longer intervals but that is not optimal to what I'm coding. Does anyone know if I should be concerned with the overhead of resuming/pausing a Java thread at very rapid intervals when using Thread.sleep() , is there another alternative I should be looking at? - Duncan Krebs

Here is my use case in more detail:

I have a back testing data feed that iterates through a large List of Quote objects and I want to throttle the speed at which the quotes are consumed so I can speed up or slow down time in my back test. For starters I don't see another option other than Thread.sleep(), if that is the case then I can either Sleep after each Quote is consumed for a very small time or batch consume a collection and then sleep before consuming the next batch. The rest of the framework I have for understanding the tick data operates best if I can throttle this consumption thread 1 quote at a time, hope this makes sense!

Answer 1

You shouldn't speed up or slow down your loop for testing - instead design the loop to explicitly synchronize with your test code (eg through a CountDownLatch or a Condition). Test code that relies on speed of execution of the code under test is inherently flaky and you will see problems.

Answer 2

Does anyone know if I should be concerned with the overhead of resuming/pausing a Java thread at very rapid intervals when using Thread.sleep(),

Possibly. Sleeping gives up the CPU and there is no guarentee it will wake promptly. It might take 11 or 15 ms in rare cases. After waking up, you CPU will run slower for about 200 micro-seconds while the CPU cache warms up again.

is there another alternative I should be looking at?

Don't sleep ever. It costs more but your code won't slow down.

For starters I don't see another option other than Thread.sleep(),

There is LockSUpport.park(nanos) which has more precision.

hope this makes sense!

I would sleep by the length of time between quote updates as it occurred originally. I would put an upper limit on this like 10 to 100 ms depending on your use case. If you want to be precise, you can busy wait for the delay you need.

Answer 3

Sounds like you may have multiple producers and multiple consumers, each on its own thread. If so you may throttle down the number of them thru config injection. This way you may always have 1 producer, 1 consumer. If your producer is created within test code then you should have no problems throttling it and by doing so you throttle the whole system. You can use Thread.sleep or sync primitives.

However if the goal of your testing is actually to figure out what consumer does with data then what I do is actually exposing the method that does work so that I can call it directly and only once with predefined data. If this method is in some sort of endless loop then in normal scenario it presumably will wait for data to come after it's done with processing. But in test mode only useful part of the loop will be run. The biggest downside is exposing a method that you may not want to expose otherwise.

// Method used by Thread class.
private void foo() {
  while(true) {
    // Blocking wait for data.
    data = getData();
    // Processing
    doStuff(data);
  }
}

public void doStuff(Data data) {
  // do useful thing here.
}