SimpleDateFormat

[Robert Gagliardo]

Since SimpleDateFormat and DateFormat are not thread safe what is the faster way to be thread safe?
Create a new instance for each thread
-or-
place a synchronized block around the static shared DateFormat
?

[Michael Morris]

Hi Robert,

Create a new instance for each thread
-or-
place a synchronized block around the static shared DateFormat

I'm not exactly sure what you're getting at here or maybe I just don't understand your design. If you create a new instance (of DateFormat?) for each thread then obviously every instance is safe provided that no other thread is allowed to access (modify) that instance, but can your design give up identity of a single object which is the whole point of thread-safety? Of course if the DataFormat object is declared static then there can only be one (class) instance so you must synchronize on methods that will access it if you don't want it corrupted.
I don't advise using synchronized blocks on objects other than "this" because they are prone to deadlock. You're better off synchronizing methods instead because you're going to take a perfomance hit either way and probably can't justify using blocks instead of whole methods.
Hope this helps
Michael Morris
SCJP

[Robert Gagliardo]

I have a utility class that has several static SimpleDateFormats. Methods within the class parse/format on them.
I could synchronize the methods, but because the methods are static, won't that make the whole class synchronized?
-or-
I could just write a simple method that returns new instances of SimpleDateFormats based on a given format parameter.

[Michael Morris]

Hi Robert,
Regardless of whether the data you're trying to protect is static or not, when you synchronize, you lock the whole object. All objects have a monitor which you can think of as a door with a single key on the doormat. When a thread wants to access a synchronized method on that object, it grabs the key and locks the door from the inside preventing all other threads from entering. Whatever thread has the key keeps it until it finishes all synchronized methods while it has the key or calls wait() on the object and enters the objects pool of waiting threads where it is ineligible for scheduling. If it calls wait() it remains inactive until another thread calls either notify() or notifyAll() on the same object and is lucky enough to be arbitrarily chosen to once again receive the object lock.
Now if performance is truly an issue, and your desgin can tolerate creating new instances on the fly (I'm assuming private access on the protected data and no publicly available means to get to that data) then that is probably what you want to do.
Hope this helps
Michael Morris
SCJP

[Robert Gagliardo]

Michael, thanks for your responses