-
Ensuring the order of execution for tasks
This post was originally published as part of the Java Advent series. If you like it, please spread the word by sharing, tweeting, FB, G+ and so on! Want to write for the Java Advent blog? We are looking for contributors to fill all 24 slot and would love to have your contribution! Contact Attila…
-
Helper for testing multi-threaded programs in Java
This post was originally published on the Transylvania JUG blog. Testing multi-threaded code is hard. The main problem is that you invoke your assertions either too soon (and they fail for no good reason) or too late (in which case the test runs for a long time, frustrating you). A possible solution is to declare…
-
Java Date objects can mutate, even when read
Ran into this problem a couple of months ago, when we saw some strange dates in production. So I dug into the Java library sources (thank you Sun for providing those!) and found that Date objects aren’t always “normalized”. Rather, sometimes a “denormalized” value is stored which is later (lazily) normalized. The normalized value isn’t…
-
Don’t Yield to pressure?
or: does Thread.yield have its place in todays Java programs? I was profiling a rather old legacy codebase (since the first rule of performance optimization is “profile it” with the close second of “have clear goals in mind” – but that’s an other post) and – after optimizing the first few hotspots, Thread.yield appeared at…
-
Hidden Java concurrency bugs
Question: how can the following line of Java code throw the exception shown below? priv.addAll(common); Exception in thread "Thread-1" java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(Native Method) at java.util.ArrayList.toArray(Unknown Source) at java.util.ArrayList.addAll(Unknown Source) at TestConcurrentList$ConsumeThread.run(TestConcurrentList.java:34) Answer: because of bad synchronization. The scenario is the following: one thread is continuously modifying the list “common” while the second thread tries to…