It would be good to still write a test case which reproduces that bug, to make sure that it is really fixed. For example a tests where many (tens or hundreds?) of threads call the AbstractReferenceCache.get() method concurrently, and the result should be that all of them return exactly the same instance which is non-null. And then that test should be executed hundreds of times - if it fails one time in a million, then the code is broken.
I've found it useful to follow the tips in Clean Code (http:// www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882) and execute all tests in the project multiple times in parallel, on more threads than the CPU has cores. For example in IntelliJ IDEA, I keep the hotkey for running the tests pressed down, until the status bar shows that 20, 50 or 100 processes are running. Then I wait a minute or two until CPU and memory usage returns to normal, and check one-by-one that none of the test runs threw exceptions or deadlocked. Normally in that project it takes 2 seconds to run all the tests once, but when executing 50-100 test runs in parallel, it takes even more than 100 seconds for one test run, so there is lots of thread switching happening. There are also frameworks such as http://www.alphaworks.ibm.com/tech/contest which do bytecode manipulation for forcing thread switches, so that concurrency bugs would become more apparent. I haven't tried using such frameworks, but maybe you should try. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-guice?hl=en -~----------~----~----~----~------~----~------~--~---
