[LANG-1355] TimeZone.getTimeZone() in FastDateParser causes resource contention

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 3.6
• Fix Version/s: 3.7
• Component/s: lang.time.*

Environment

Windows

Docs Text

package org.apache.commons.lang3.time;

import java.util.TimeZone;
import java.util.concurrent.ConcurrentMap;
import java.util.concurrent.ConcurrentHashMap;

/**
 * <p>TimeZoneCache is a thread-safe cache and retriever for TimeZone objects.</p>
 *
 * <p>To obtain a TimeZone, use {@link TimeZoneCache.getTimeZone(String tid). If no instance
 * if found in the cache, an instance will be created by calling TimeZone.getTimeZone().
 * Otherwise, the instance with the matching tid will be obtained from TimeZone.getTimeZone(),
 * stored in the cache and returned.</p>
 *
 * <p>TimeZone.getTimeZone() is a synchronized static method, which can cause thread
 * contention under high load. If you must use a large number of time formatter or parser
 * objects, this class can be used to avoid repeated construction and synchronization
 * blocking.</p>
 * <code>
 * TimeZone tz = TimeZoneCache.getInstance("UTC");
 * </code>
 *
 * @see FastDateParser, FastDateFormatter
 */
public class TimeZoneCache {
/* A cache of the currently known TimeZones */
private final static ConcurrentMap<String, TimeZone> timeZoneCache = new ConcurrentHashMap<String, TimeZone>(7);

public static TimeZone getTimeZone(String tid) {
TimeZone tz = timeZoneCache.get(tid);
if (tz == null) {
tz = TimeZone.getTimeZone(tid);
timeZoneCache.put(tid, tz);
}
return tz;
}
}

• Assignee: Charles Honton
• Reporter: Keith Boone
• Created: 28/Sep/17 22:32
• Updated: 10/Nov/17 16:41
• Resolved: 10/Oct/17 17:59

Description

Under heavy load we are seeing contention in FastDateParser.parse() on calls to TimeZone.getTimeZone(). TimeZone.getTimeZone() is a synchronized static in the Oracle JVM.

Our proposed solution is to add a class TimeZoneCache containing a single method getTimeZone() which gets the requested time zone from a ConcurrentMap, and if not present, looks it up via TimeZone.getTimeZone() and caches it before returning it.

Then replace calls to TimeZone.getTimeZone() in FastDateParser ( and whereever else) to calls to TimeZoneCache.getTimeZone().

The reason to add a separate class is because it can also be used by other applications which heavily parse or format or do other things where TimeZone is repeatedly needed.

Under extreme load we have seen an 50:1 improvement in calls to FastDateParser.parse(). This saves about a ms/call in our test environment, and reduces contention.

Issue Links

• links to: GitHub Pull Request #296