JDK-4692504 : TimeZone.getDefault() has too much synchronization
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 1.3.1,5.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_2000
  • CPU: generic,x86
  • Submitted: 2002-05-28
  • Updated: 2003-09-09
  • Resolved: 2003-09-09
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2_18Fixed
Related Reports
Duplicate :  
JDK-4845983 - TimeZone.getDefault() is too slow, hurt overall performance, especially on SMP
Relates :  
JDK-5079972 - (tz) Eliminate synchronization from TimeZone.getDefault
Relates :  
JDK-5073554 - java.util.Date is a performance bottleneck
Relates :  
JDK-4936432 - GregorianCalendar should support shared TimeZone
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
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger INTEGRATED IN: tiger tiger-b19
14-06-2004
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
28-08-2003