Menu
The question regards Java's SimpleDateFormat class. I've read in the documentation that
Date formats are not synchronized. It is recommended to create separate format instances for each thread. If multiple threads access a format concurrently, it must be synchronized externally.
Obviously, I've read that after being hit in the most obscure way by it.
Does anybody know why would it be necessary to have state information in class members accessed by the "format" method for example?
Is it a speed optimization of some sort? I couldn't come up with a valid reason.
885
The SimpleDateFormat class mutates its internal state for formatting and parsing dates. That's why it results in these issues when multiple threads use the same instance of SimpleDateFormat concurrently.
No, the SimpleDateFormat class is not thread-safe. If you want to share an instance of it between threads, you must synchronize access within each thread. A better alternative is the DateTimeFormatter class. It was introduced in Java 8.
Class SimpleDateFormat. SimpleDateFormat is a concrete class for formatting and parsing dates in a locale-sensitive manner. It allows for formatting (date -> text), parsing (text -> date), and normalization. SimpleDateFormat allows you to start by choosing any user-defined patterns for date-time formatting.
Explanation: SimpleDateFormat is not thread safe.
Your answer pretty much lies here:
/* * (C) Copyright Taligent, Inc. 1996 - All Rights Reserved
Prior to 1.4 hotspot writing multi-threaded code in Java was primarily a homework assignment for graduate students. The language had been around 10 years before the serious arrival of web-application servers and rise of the container-driven highly concurrent systems that most of us (non-android anyway) spend the vast majority of our time working in.
In 1996, Garbage Collection was a very slow and painful process that generally made your UI pause and look locked up while it happened, like wise creating new objects was considered very expensive (creating contiguous memory space when you're fighting with Windows 95 for a share of 4MB of physical memory with no L2 CPU cache takes some time.....).
So in an environment where multi-threading is extremely rare, and memory is at a premium (your average user is probably still on a 486 or Pentium 1 with 8MB or even 4MB of system memory....) it makes perfect sense to re-use a single instance of Calendar as much as possible, Calendar itself being something of a clunky beast.
We can scoff today at what a horrible practice it is for a class like that to be stateful, but it can also be easily defended as the right choice at the time.
Defending Sun's obsession with 100% backward compatibility and never updating it is another matter of course!
138
It looks like it is done for the performance reason. I see no other explanations for it.
There is a good summary on how it works here: Why is Java's SimpleDateFormat not thread-safe?
36
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
