A loop like the following will show duplicate ID's returned by the toString() method of java.rmi.server.UID: for (int i = 1; i <=20; ++i) { System.out.println(new UID().toString()); } Within the first few lines, you'll see an ID that appears twice in two consecutive lines. I believe the problem is due to this line at the end of the constructor: count = uidCounter++; Any time the clock advances, count and uidCounter are set to Short.MIN_VALUE. The next iteration, the else branch is taken, and count will stay at Short.MIN_VALUE, since a postfix operator is used on uidCounter (see line above). All subsequent iterations, count and uidCounter will continue to increment, until the clock ticks again, at which point the duplication reocccurs. If I change the line above to the following, it seems to fix the problem: count = ++uidCounter; By the way, shouldn't the whole constructor be synchronized? Seems like there's potential for what's going on in the if branch to conflict with what's going on in the else branch (if you had 2 threads at each branch at the same time), but the if is not synchronized and the else is synchronized, so one can clobber the other.
The bug is confirmed. The general notes on the thread safety are not confirmed: after fixing the bug, I wrote a simple test with 20 threads and the duplicate UIDs are not returned. The bug will be fixed soon.
Created attachment 11692 [details] The fix This patch fixes the reported wrong behavior.
The fixing patch is commited.
Audrius, David is correct that the code is not thread safe. At the very least "last" should be made volatile, but it would be better (easier) to make the whole if/else construct synchronized.
Created attachment 11697 [details] Second fix This patch synchronizes on the whole constructor body. It must be applied subsequently after the first patch.
Created attachment 11698 [details] The test case, showing, that the UID's are now really unique (obtaining the 4000 UID's in 20 threads)
I think, this time really OK. The proving test case is uploaded.