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)
======================================================================