2

I'm unit testing a class for thread safety. I'm calling its methods from different threads, to make sure all of them receive the same result (in a nutshell). This is how I decide how many threads to use:

int threads = Runtime.getRuntime().availableProcessors() * 4;

Is it a good practice? How many should I use? The more the better?

yegor256
  • 102,010
  • 123
  • 446
  • 597
  • 1
    To be clear: I assume efficiency is NOT the main issue for this question, is it correct? (it seems that answers focus on this aspect, though it doesn't seem to be your intent) – amit Aug 28 '12 at 13:14
  • Maybe take a look at a previous question: http://stackoverflow.com/questions/12159/how-should-i-unit-test-threaded-code – Seb Rose Aug 28 '12 at 13:20
  • There is no guarantee you will find a multi-threading bug using a unit test. If the test fails you have found a problem, if it passes, it may be that the test happened to work. I would try different options to see what you believe is the most likely to fail. – Peter Lawrey Aug 28 '12 at 13:26

3 Answers3

6

I generally run 3 sets of tests:

  • one thread to check correct behaviour in single threaded environment
  • number of processors + 1 (or whatever the typical application setting is)
  • many threads (say 1000) to increase context switching and contention

And for the multi threaded tests, I try to maximize interleaving, typically by synchronizing the beginning of the tasks with a CountDownLatch, so that all threads start their tasks more or less at the same time.

I also try to avoid additional synchronization during the tests (for example by using a thread safe structure to store some results) as it might "re-sycnchronize" the tested code artificially - to be assessed on a case by case basis.

JCiP, chapter 12, is a good source of inspiration for efficient multithreading testing (i.e. gives many hints to provoke concurrency bugs).

And finally, as noted by @PeterLawrey, you can't guarantee that your code is thread safe with testing, you can only try to increase your chance of finding concurrency bugs.

assylias
  • 321,522
  • 82
  • 660
  • 783
0

It depends on how much IO has been performed by threads. For CPU-intensive tasks 1 thread per 1 core is good, but if you're waiting for IO tasks, like database read/write operations, file operations - it is safe to increase the number to 2 or more threads per core. Just measure performance and you will get the best value for your test :)

jdevelop
  • 12,176
  • 10
  • 56
  • 112
0

Threading issues usually arise rarely, so the thought is, the more you stress it the more you will bring out race conditions, contention issues, etc.

So 4 * #processors probably isn't going to give you very meaningful results. In fact it may even give you a false sense of everything is working.

You should estimate how many threads will actually ever run at the same time in production and then go above and beyond that number by a significant margin.

Blaine Mucklow
  • 592
  • 7
  • 18