I've been working under the assumption that neither Date
nor Calendar
are thread-safe, but, during a recent discussion, a co-worker told me Calendar
was thread-safe.
So, I did some research, and came up with nothing. There are plenty people arguing it's thread-safe, and plenty people arguing it's not thread-safe. And, to top it off, the documentation doesn't say anything one way or another, not for Calendar
, nor even for Date
.
So, which is it?
Date and Time APIs in Java 8 are immutable and therefore thread safe.
A [portion of code] is thread-safe if it behaves correctly when accessed from multiple threads, regardless of the scheduling or interleaving of the execution of those threads by the runtime environment, and with no additional synchronization or other coordination on the part of the calling code.
Date are deprecated since Java 1.1, the class itself (and java. util. Calendar , too) are not officially deprecated, just declared as de facto legacy. The support of the old classes is still important for the goal of backwards compatibility with legacy code.
The java.util.calendar class is an abstract class that provides methods for converting between a specific instant in time and a set of calendar fields such as YEAR, MONTH, DAY_OF_MONTH, HOUR, and so on, and for manipulating the calendar fields, such as getting the date of the next week.Following are the important ...
Here is a link to the source code of Calendar and GregorianCalendar in Java 7
If you read the code you will see that none of the instance methods are synchronized, and none of the instance fields are volatile
. You will also see that even the field get
methods can cause a Calendar instance to mutate. And since there is no synchronization performed, different threads may see stale versions of a Calendar object's fields following such a mutating operation.
For the record, the mutation action in the field get methods happens in / during a call to this method:
1555 protected void complete() 1556 { 1557 if (!isTimeSet) 1558 updateTime(); 1559 if (!areFieldsSet || !areAllFieldsSet) { 1560 computeFields(); // fills in unset fields 1561 areAllFieldsSet = areFieldsSet = true; 1562 } 1563 }
In short, the Calendar
class is not thread-safe, and GregorianCalendar
isn't either because it inherits the non-thread-safe fields and methods.
But don't just take my word for it. Do your own analysis of the source code.
And, to top it off, the documentation doesn't say anything one way or another, not for Calendar, nor even for Date.
If the javadocs don't specify the thread-safety of a class, then you should assume that it is not thread-safe. (Especially if the class is mutable by design.)
Documentation from Oracle says nothing about thread-safety: http://docs.oracle.com/javase/7/docs/api/java/util/Calendar.html.
OpenJDK source code (build b147) implements java.util.Calendar
in a non-thread-safe way, for example:
public void setTimeInMillis(long millis) { // skipped time = millis; isTimeSet = true; areFieldsSet = false; computeFields(); areAllFieldsSet = areFieldsSet = true; }
I think that it's safe to assume that the class is not thread safe.
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