Comments on Java Code Geeks: Java Best Practices – DateFormat in a Multithreadi...

You have implemented a simple multi thread testing...

2011-07-06T09:02:58.200+03:00

You have implemented a simple multi thread testing framework of our own.

hi, which tool you used to generate performance re...

2011-07-06T06:50:59.074+03:00

hi, which tool you used to generate performance report? thanks a lot~~

Problems go deeper than Formatters (Date, Number, ...

2011-05-17T08:13:30.099+03:00

Problems go deeper than Formatters (Date, Number, etc) in Java. Actually, Date objects can mutate when read (!) as demonstrated here: http://hype-free.blogspot.com/2011/01/java-date-objects-can-mutate-even-when.html, which is completely unexpected and undocumented, so my recommendation is to use something like JodaTime.

Thanks for this nice explanation and the advantage...

2011-02-05T12:55:52.728+02:00

Thanks for this nice explanation and the advantage of ThreadLocal!

Hello developmentech, My point was to show an eff...

2010-10-05T09:45:08.823+03:00

Hello developmentech,

My point was to show an efficient way to properly utilize DateFormat in a multithreading environment. You definitelly NEED to access DateFormat instances in a synchronized manner if you intend to use them by multiple threads (when parsing also). We designate typical exceptions thrown when parsing to create a date and viceversa.

Lastly if you are not convinced that parse needs to be synchronized you just have to implement a simple case schenario and test it for yourself. You will be amazed of how easy it is to experience errorneous results.

BRs

I really have to ask why. In the examples, the onl...

2010-10-05T01:57:59.743+03:00

I really have to ask why. In the examples, the only method being called (ultimately) on the date format object is parse. So, what class state on the date format object does parse change? I would be surprised if it changed any. The reason for the comment in the API for SimpleDateFormat not being synchronized is for the methods that DO change the state of the SimpleDateFormat object. But parse is not one of them.
So, if your example was to show your prowess in using and explaining ThreadLocal, good job! You did that. But, if your point was to show that we NEEDED to use ThreadLocal when we are going to be parsing dates with a DateFormat, then I think you may have missed the mark because I am not convinced that parse needs to be synchronized.

I had a look at org.apache.commons.lang.time.FastD...

2010-07-31T14:07:42.708+03:00

I had a look at org.apache.commons.lang.time.FastDateFormat's source code and it seems that all methods returning a DateFormat instance are synchronized. Although it uses some kind of internal caching it clearly can't scale as well as the ThreadLocal approach since all threads need to wait until they acquire a monitor lock..

Does anyone know if org.joda.time.format.DateTimeFormatter in Joda Time is thread safe? Nothing relevant seems to be mentioned in the class's documentation.

I wrote a ConcurrentDateFormat class which impleme...

2010-07-25T21:08:31.677+03:00

I wrote a ConcurrentDateFormat class which implements DateFormat, it stores a cloned instance of a passed in DateFormat as a template, so its initialValue() just returns a clone of the stored template. This approach combines the best of ThreadLocal and cloning, and is completely transparent.

Hi! :) I was just testint this stuff the other we...

2010-07-16T20:07:19.415+03:00

Hi! :)

I was just testint this stuff the other week, and I really think this is a dangerous subject many developers do not pay attention to.

But I just found out a really nice way of doing it. Instead of synchronizing one instances, there are two better solutions, in my opinion:

If you have lots of formatting, you should use a Flyweight pattern solution. In short, use a cache of instances.

But that is not so simple and in most cases is like too much trouble. So comes the trick. =)
Just create a static constant and use it as template by CLONING IT. ;)

My testings showed that cloning a DateFormat, TextFormat and any other similiar is 20 times faster than creating a new one, if my memory does not fail me. =)

Yes, just do
DATE_FORMAT.clone().format(new Date());

Maybe someday I post this test on my blog... :P

You don't need to override all methods on Thre...

2010-07-13T23:29:25.701+03:00

You don't need to override all methods on ThreadLocal - just initialValue:

private ThreadLocal df = new ThreadLocal () {
@Override
protected DateFormat initialValue() {
return new SimpleDateFormat("yyyy MM dd");
}
};

On my project we wrapped this inside a ThreadsafeSimpleDateFormat which took a
DateFormat as constructor argument, cloned it (for safety) and stored as "seed". The initialValue() of our innerThreadLocal then returned seed.clone().

ThreadsafeSimpleDateFormat had parse and format methods which delegated to innerThreadLocal.get().

If you're REALLY paranoid, you'll synchronize the call to seed.clone() on seed, since there is no guarantee that the clone() method is thread safe.

Apache commons FastDateFormat is great - except that it doesn't do parsing.

JodaTime is great, but requires you to use JodaTime instead of java.util.Date/java.util.Calendar. Great choice, but more intrusive.

Andrei's solution also looks good, but could be implemented slightly more elegant in Java 5 with generics.

One thing you must beware of is Locale.setDefault(). If you don't provide a Locale when constructing your SimpleDateFormat, Locale.getDefault() will be used - whatever that is, at the time initialValue() is called. So if you change this later, it will NOT affect those ThreadLocal's which have already been created, but it will affect those that are created later. Here be dragons.

Cheers! You just gave me a good hint on a task I&#...

2010-07-13T12:34:09.392+03:00

Cheers! You just gave me a good hint on a task I'm working on.

You could also use FastDateFormat in org.apache.co...

2010-07-12T17:20:02.635+03:00

You could also use FastDateFormat in org.apache.commons.lang.time

"FastDateFormat is a fast and thread-safe version of SimpleDateFormat"

Hi Just! Thanks for a clear explanation and perfor...

2010-07-12T15:42:12.147+03:00

Hi Just!
Thanks for a clear explanation and performance results.
One thing to mention: your solution holds all he created DateFormat instances s in memory, never freeing them. I can suggest solution for this problem:
http://asolntsev.blogspot.com/2009/05/threadsafedateformat.html