Provoking a race condition in Java

I got to write a unit test which provokes a race condition so I can test if I probably fixed the problem later on. The problem is that the race condition only occurs very rarely, maybe because my computer has only two cores.

The code is something like the following:

class MyDateTime {
  String getColonTime() {
    // datetime is some kind of lazy caching variable declared somewhere(does not matter)
    if (datetime == null) {
      initDateTime(); //Uses lazy to initlialize variable, takes some time
    }
    // Colon time stores hh:mm as string
    if (datetime.colonTime == null) {
      StringBuilder sb = new StringBuilder();
      //Now do some steps to build the hh:mm string
      //...
      //set colon time
      datetime.colonTime = sb.toString();
    }
  return datetime.colonTime;
  }
}

Explanation: initDateTime assigns a new instance to dateTime, therefor, datetime.colonTime is null afterwards (as we want to initialize it lazy, as I stated before). Now if Thread A enters the method and then the scheduler stops it just before it can run initDateTime(). Thread B now runst getColonTime(), sees that datetime is still null and initialzes it. datetime.colonTime is null so the second if block is executed and datetime.colonTime gets the value of the StringBuilder. If then the scheduler stops the thread between this line and the return statement and resumes thread A, the following happens: As A was stopped just before initDateTime is called, A now calls initDateTime(), which will kind of reset the datetime object, setting datetime.colonTime to null again. Thread A then will enter the second if block, but the scheduler will interrupt A before datetime.colonTime = 开发者_如何学运维sb.toString(); is called. As a conclusion, dateTime.colonTime is still null. Now the scheduler resumes B and the method returns null.

I tried to provoke the race condition by having a number of threads calling getColonTime() to a single (final) instance of MyDateTime, but it only fails in some extreeemly rare cases :( Any hints how to write a JUnit "test"?

As you mention, race conditions are exceedingly difficult to reproduce consistently. However, the law of averages is on your side. If you create a test that you expect to fail maybe one in a hundred times, and then make it happen a thousand times, you'll probably catch the error fairly consistently in your old code. So, in keeping with TDD principles, you should start with the code the way it was before, come up with a test iterates enough times to fail consistently against the old code, then change to your new code and make sure it doesn't fail.

You could look at Thread Weaver, or there may be other frameworks for testing multi-threaded code. I have not used it, but the Users' Guide looks as if it is designed for exactly this kind of testing.

I know this post is quite old but I'm facing a similar situation. What I tend to do is to favour the race condition with sleeps.

In your case, I would do something like

    class MyDateTime {
        String getColonTime() throws InterruptedException{
           if (datetime == null) {
              Thread.sleep(new Random().nextInt(100); //Wait  to enhance the chances that multiple threads enter here and reset colonTime.
              initDateTime(); 
           }
           Thread.sleep(new Random().nextInt(100); //Wait  to enhance the chances that colonTime stays null for a while.
           if (datetime.colonTime == null) {
              StringBuilder sb = new StringBuilder();
              datetime.colonTime = sb.toString();
           }
           Thread.sleep(new Random().nextInt(100); //Wait to favour reset of colonTime by another thread in the meantime.
           return datetime.colonTime;
        }
    }

But clearly this becomes messy quite rapidly. I wish there was some way to force the scheduler to explore all the paths given some "break points".

As the post is a bit old, I was wondering whether you found good ways to test race conditions in Java. Any piece of advice to share ?

Thank you