2

I was looking for the usage of ThreadLocal and landed on this popular page When and how should I use a ThreadLocal variable?

The accepted, highest voted answer says

One possible (and common) use is when you have some object that is not thread-safe, but you want to avoid synchronizing access to that object (I'm looking at you, SimpleDateFormat).

And the core part of the code is

 return new SimpleDateFormat("yyyyMMdd HHmm");

which won't change or be affected by conncurrent execution, or would it?

Can you please highlight how this could be a issue? And why would we need a thread safe object here?

In other occurrence, I have come across a similar usage with java.security.MessageDigest;, which is also a puzzler to me. It would be great if anyone could explain the reasons behind this, with some helpful code if possible.

Community
  • 1
  • 1
mtk
  • 11,504
  • 15
  • 67
  • 104
  • 1
    possible duplicate of [SimpleDateFormat thread safety](http://stackoverflow.com/questions/6840803/simpledateformat-thread-safety) – user2864740 May 08 '14 at 07:39
  • SDF is *not* thread-safe because it *modifies shared internal state* (without synchronization guarantees) during actions: ["SimpleDateFormat stores intermediate results in instance fields. So if one instance is used by two threads they can mess each other's results."](http://stackoverflow.com/questions/6840803/simpledateformat-thread-safety). – user2864740 May 08 '14 at 07:39
  • please pick an answer – Hendy Irawan Jul 07 '14 at 10:12

2 Answers2

5

SimpleDateFormat extends DateFormat which has setter methods so one thread could be changing properties of the SimpleDateFormat instance while others could be using it and assuming earlier properties or, even worse, have the properties change in the middle of an execution causing internally inconsistent results.

Andrew Vitkus
  • 797
  • 6
  • 9
  • Even when no threads modify its state, it will still produce wrong results; merely using it from more than one thread breaks it because of how it was implemented – Enno Shioji May 08 '14 at 07:36
  • 1
    It isn't that SDF allows modifications that makes it not thread-safe - it is a fundamental design issue/flaw in *modifying internal state* that makes not thread-safe. – user2864740 May 08 '14 at 07:39
  • @EnnoShioji Interesting. I had assumed that all the necessary data beyond the instance's properties would have been only stored in the methods so at least those would be independent. Who writes code like that? – Andrew Vitkus May 08 '14 at 07:41
  • Yeah, it's pretty bad, but then again lots of old code do – Enno Shioji May 08 '14 at 12:51
4

Well, take the first line in format(Date, StringBuffer, FieldDelegate):

calendar.setTime(date);

calendar there is an instance member, so that's obviously not thread-safe there. Firstly there's a date race (since setTime is not synchronized), but even more glaringly, someone could come through and set the calendar's time to something else part-way through the function (calendar's value is accessed in subFormat, which format calls).

yshavit
  • 39,951
  • 7
  • 75
  • 114