United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4692504 : TimeZone.getDefault() has too much synchronization

Details
Type:
Bug
Submit Date:
2002-05-28
Status:
Resolved
Updated Date:
2003-09-09
Project Name:
JDK
Resolved Date:
2003-09-09
Component:
core-libs
OS:
generic,windows_2000
Sub-Component:
java.util:i18n
CPU:
x86,generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.3.1,5.0
Fixed Versions:
5.0 (tiger)

Related Reports
Backport:
Duplicate:
Relates:
Relates:
Relates:

Sub Tasks

Description

Name: nt126004			Date: 05/28/2002


FULL PRODUCT VERSION :
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03)
Java HotSpot(TM) Client VM (build 1.3.1_03-b03, mixed mode)

FULL OPERATING SYSTEM VERSION :

Microsoft Windows 2000 [Version 5.00.2195]

A DESCRIPTION OF THE PROBLEM :
TimeZone.getDefault() is a static synchronzied method.  In
it the code checks to see if the default time zone has been
initialized and if not initializes it.  Once an initialized
default is available it is cloned and returned to the
caller.  However the call to clone() need not be
synchronized and causes uneeded contention.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.  Write a multithreaded application which uses
TimeZone.getDefault() (which many Date operations use).
Get a profiler which can show you how much time you spend
blocked trying to get the lock on TimeZone.class.
2.
3.

This bug can be reproduced always.

CUSTOMER WORKAROUND :
Cache TimeZone.getDefault yourself in user code.
Unfortunately this isn't always possible because in some
cases the caller is also JDK or third party code.
(Review ID: 146743) 
======================================================================

                                    

Comments
EVALUATION

The current synchronization is required to avoid possible race conditions due to having the setDefault method. However, there should be a way to work around this problem in the Date class.
###@###.### 2002-06-26


Closing this bug report as "not a bug".
###@###.### 2002-08-05


Reopened this bug for providing a workaround fix for Tiger.
###@###.### 2003-04-10


Calendar instances no longer use a clone of the default TimeZone object until Calendar.getTimeZone is called. Date now always uses a reference to the default TimeZone object. test/java/util/Calendar/CalendarTest.java runs 47% faster after the change.
###@###.### 2003-08-28
                                     
2003-08-28
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
tiger

FIXED IN:
tiger

INTEGRATED IN:
tiger
tiger-b19


                                     
2004-06-14



Hardware and Software, Engineered to Work Together