Using a pattern very similar to that described in a recent question, for a multithreaded application, I am getting weird date values (e.g., years like 2025 or 2035, when clearly no such value exists in the source data). It seems that a concurrency issue is occuring.
The source code looks something like
// Various Java DateFormat patterns, e.g. "yyyy-MM-dd".
private static final String[] DATE_PATTERNS = new String[] {...};
private static SimpleDateFormat[] getFormats(final String[] patterns)
{
ThreadLocal<SimpleDateFormat[]> LOCAL_FORMATS = new ThreadLocal<SimpleDateFormat[]>()
{
#Override
protected SimpleDateFormat[] initialValue()
{
List<SimpleDateFormat> formatList = new ArrayList<SimpleDateFormat>();
for (String pattern:patterns)
{
formatList.add(new SimpleDateFormat(pattern));
}
return formatList.toArray(new SimpleDateFormat[formatList.size()]);
}
};
return LOCAL_FORMATS.get(); // Create a thread-local copy
}
private static final SimpleDateFormat[] DATE_FORMATS = getFormats(DATE_PATTERNS);
After its static initialization, the DATE_FORMATS array is accessed by numerous classes, which in turn use the SimpleDateFormat objects of the array for parsing or formatting several date strings.
Can there be any concurrency issue in such a usage scenario, especially given the use of ThreadLocal?
Yes, there can be concurrency issues. Your thread local variable doesn't serve any purpose. It's only used when the class is initialized, to temporarily store an array of date formats that is immediately retrieved and stored in a static constant.
All the threads, after, always use the same instances of date formats concurrently, without getting them from any thread local variable.
The code should rather be:
private static final String[] DATE_PATTERNS = new String[] {...};
private static final ThreadLocal<SimpleDateFormat[]> DATE_FORMATS =
new ThreadLocal<SimpleDateFormat[]>() {
#Override
protected SimpleDateFormat[] initialValue() {
List<SimpleDateFormat> formatList = new ArrayList<SimpleDateFormat>();
for (String pattern : DATE_PATTERNS)
{
formatList.add(new SimpleDateFormat(pattern));
}
return formatList.toArray(new SimpleDateFormat[formatList.size()]);
}
};
public static SimpleDateFormat[] getDateFormats() {
return DATE_FORMATS.get();
}
I would also use an unmodifiable List<SimpleDateFormat> rather than an array, to be safer.
// Various Java DateFormat patterns, e.g. "yyyy-mm-dd".
The format 'yyyy-mm-dd' is likely to give you weird results because 'mm' is minutes and not months. From the javadoc:
M Month in year Month July; Jul; 07
...
m Minute in hour Number 30
Related
I have a private method which takes date in as String type and returns XMLGregorianCalendar object with specific format. This method is being invoked from various other methods within the same class.
The format defined as SimpleDateFormat which is same for every invocation. Below are the 2 versions of the method.
Version 1:
private XMLGregorianCalendar getXmlGregorianCalendar(final String strDt) throws ParseException, DatatypeConfigurationException{
Date date = null;
// local variable dtFormat
DateFormat dtFormat = new SimpleDateFormat("yyyy-MM-dd-hh.mm.ss");
if (strDt != null) {
date = dtFormat.parse(strDt);
GregorianCalendar cal = new GregorianCalendar();
cal.setTime(date);
XMLGregorianCalendar xmlCal = DatatypeFactory.newInstance().newXMLGregorianCalendar(cal);
return xmlCal;
}else {
return DatatypeFactory.newInstance().newXMLGregorianCalendar(new GregorianCalendar());
}
}
Version 2:
// declare date format once, global variable
private DateFormat dtFormat = new SimpleDateFormat("yyyy-MM-dd-hh.mm.ss");
// getter setter for dtFormat
private XMLGregorianCalendar getXmlGregorianCalendar(final String strDt) throws ParseException, DatatypeConfigurationException{
Date date = null;
if (strDt != null) {
date = this.dtFormat.parse(strDt); // of course, getDtFormat() can be used
GregorianCalendar cal = new GregorianCalendar();
cal.setTime(date);
XMLGregorianCalendar xmlCal = DatatypeFactory.newInstance().newXMLGregorianCalendar(cal);
return xmlCal;
}else {
return DatatypeFactory.newInstance().newXMLGregorianCalendar(new GregorianCalendar());
}
}
Version 1 vs Version 2. Which has better performance?
Note: The enclosed class is annotated as #Component and involved in creating response for my web service.
SimpleDateFormat is not thread-safe, so that would be something to consider. Performance has little to do with this question, unless you really don't have any other performance hotspots (which would be surprising).
You can however use a ThreadLocal SimpleDateFormat, but remember that ThreadLocals have their own issues, and it probably doesn't really matter.
If that SimpleDateFormat is a constant, you can make it static final and it would improve your performance just a little bit. But you should be aware of the concept of static fields in classes. static fields are allocated once in memory for all instances of your #Component class. So if this cannot creating a bug in your code, it's better to define it as a constant using static final keywords.
I have a JobClass wherein I am calling another class named as MainClass. The quartz trigger schedule to run the Main class via JobClass every 5 minutes. Now in the main class I have to collect the current date time something like below:-
DateFormat dateFormat = new SimpleDateFormat("yyyy/MM/dd/hh/mm/ss");
Calendar calendar = Calendar.getInstance();
String CurrentDateTime = dateFormat.format(calendar.getTime());
public String[] splitMe = CurrentDateTime.split("/");
public String year = splitMe[0];
public String month = splitMe[1];
public String day = splitMe[2];
public String hour = splitMe[3];
public String minute = splitMe[4];
public String second = splitMe[5];
String FilePrefix = year.concat(month).concat(day).concat("_").concat(hour).concat(minute).concat(second);
String FilePrefix4ControlFile = year.concat(month).concat(day).concat(" ").concat(hour).concat(minute).concat(second);
String EarliestTime = year.concat("-").concat(month).concat("-").concat(String.valueOf(Integer.parseInt(day) - 1));
String LatestTime = year.concat("-").concat(month).concat("-").concat(day);
This way I can get all my date time individual variable to create some strings with different combinations. Every single job runs I need to have a unique set of values however whatever number of times these variables are called within one job run then the values should be same.
Now I tried doing it using Static variables which kind of solved one problem of having same values during 1 run. However as the static variables are created on class initialisation ( main class) then they will always have same value unless the class is reloaded which I don't want to do , indeed not that easily possible in java.
I am sure I am doing some silly mistake, any pointers on this will be helpful.
PS: I just started Java by my own recently.
Thanks guys!
RJay
Synchronization
Date formats are not synchronized. It is recommended to create separate format instances for each thread. If multiple threads access a format concurrently, it must be synchronized externally
The above line is mentioned in the JavaDoc of SimpleDateFormat class.
Does it mean that we should not create the SimpleDateFormat objects as Static.
And If we create it as static, so wherever we are using this object we need to keep it in Synchronised Block.
That's true. You can find already questions concerning this issue on StackOverflow. I use to declare it as ThreadLocal:
private static final ThreadLocal<DateFormat> THREAD_LOCAL_DATEFORMAT = new ThreadLocal<DateFormat>() {
protected DateFormat initialValue() {
return new SimpleDateFormat("yyyyMMdd");
}
};
and in the code:
DateFormat df = THREAD_LOCAL_DATEFORMAT.get();
Yes SimpleDateFormat is not thread safe and it is also recommended when you are parsing date it should access in synchronized manner.
public Date convertStringToDate(String dateString) throws ParseException {
Date result;
synchronized(df) {
result = df.parse(dateString);
}
return result;
}
one other way is on http://code.google.com/p/safe-simple-date-format/downloads/list
Thats correct. FastDateFormat from Apache Commons Lang is a nice threadsafe alternative.
Since version 3.2 it supports also parsing, before 3.2 only formatting.
I have created a custom Converter in JSF 1.2 to convert Date objects. The dates have a very particular format. I have implemented my converter using the core Java SimpleDateFormat class to do the conversion, using the formatter string shown in my code comments below. This all works fine.
My question is about thread safety. The SimpleDateFormat API docs state that it is not thread safe. For that reason I have created a separate instance of the date format object for each instance of my converter object. However, I'm not sure if this is enough. My DateFormat object is stored as a member of the DTGDateConverter.
QUESTION: Will two threads every simultaneously access the same instance of a Converter object in JSF?
If the answer is yes, then my Converter is probably at risk.
/**
* <p>JSF Converter used to convert from java.util.Date to a string.
* The SimpleDateFormat format used is: ddHHmm'Z'MMMyy.</p>
*
* <p>Example: October 31st 2010 at 23:59 formats to 312359ZOCT10</p>
*
* #author JTOUGH
*/
public class DTGDateConverter implements Converter {
private static final Logger logger =
LoggerFactory.getLogger(DTGDateConverter.class);
private static final String EMPTY_STRING = "";
private static final DateFormat DTG_DATE_FORMAT =
MyFormatterUtilities.createDTGInstance();
// The 'format' family of core Java classes are NOT thread-safe.
// Each instance of this class needs its own DateFormat object or
// runs the risk of two request threads accessing it at the same time.
private final DateFormat df = (DateFormat)DTG_DATE_FORMAT.clone();
#Override
public Object getAsObject(
FacesContext context,
UIComponent component,
String stringValue)
throws ConverterException {
Date date = null;
// Prevent ParseException when an empty form field is submitted
// for conversion
if (stringValue == null || stringValue.equals(EMPTY_STRING)) {
date = null;
} else {
try {
date = df.parse(stringValue);
} catch (ParseException e) {
if (logger.isDebugEnabled()) {
logger.debug("Unable to convert string to Date object", e);
}
date = null;
}
}
return date;
}
#Override
public String getAsString(
FacesContext context,
UIComponent component,
Object objectValue)
throws ConverterException {
if (objectValue == null) {
return null;
} else if (!(objectValue instanceof Date)) {
throw new IllegalArgumentException(
"objectValue is not a Date object");
} else {
// Use 'toUpperCase()' to fix mixed case string returned
// from 'MMM' portion of date format
return df.format(objectValue).toUpperCase();
}
}
}
Will two threads every simultaneously access the same instance of a Converter object in JSF?
Depends on how you use the converter. If you use
<h:inputWhatever>
<f:converter converterId="converterId" />
</h:inputWhatever>
then a new instance will be created for every input element in view, which is threadsafe (expect of the very rare edge case that the enduser has two identical views in two browser tabs in the same session and simultaneously issues a postback on the both views).
If you however use
<h:inputWhatever converter="#{applicationBean.converter}" />
then the same instance will be shared across all views of the entire application, which is thus not threadsafe.
You're however cloning a static DataFormat instance everytime you create the converter. That part is already not threadsafe. You may risk that you're cloning an instance while its internal state is been changed because it's been used somewhere else. Also, cloning an existing instance isn't necessarily cheaper than creating a new instance.
I would recommend to just declare it threadlocal (i.e. inside the method block), regardless of how you use the converter. If the expensiveness of creating the DateFormat everytime is a major concern (did you profile it?), then consider replacing it by JodaTime.
Date formats are not synchronized. It
is recommended to create separate
format instances for each thread. If
multiple threads access a format
concurrently, it must be synchronized
externally.
Yes it is not thread safe here.
Put it local to method and create instance per thread
The javadoc for SimpleDateFormat states that SimpleDateFormat is not synchronized.
"Date formats are not synchronized. It
is recommended to create separate
format instances for each thread. If
multiple threads access a format
concurrently, it must be synchronized
externally."
But what is the best approach to using an instance of SimpleDateFormat in a multi threaded environment. Here are a few options I have thought of, I have used options 1 and 2 in the past but I am curious to know if there are any better alternatives or which of these options would offer the best performance and concurrency.
Option 1: Create local instances when required
public String formatDate(Date d) {
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");
return sdf.format(d);
}
Option 2: Create an instance of SimpleDateFormat as a class variable but synchronize access to it.
private SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");
public String formatDate(Date d) {
synchronized(sdf) {
return sdf.format(d);
}
}
Option 3: Create a ThreadLocal to store a different instance of SimpleDateFormat for each thread.
private ThreadLocal<SimpleDateFormat> tl = new ThreadLocal<SimpleDateFormat>();
public String formatDate(Date d) {
SimpleDateFormat sdf = tl.get();
if(sdf == null) {
sdf = new SimpleDateFormat("yyyy-MM-hh");
tl.set(sdf);
}
return sdf.format(d);
}
Creating SimpleDateFormat is expensive. Don't use this unless it's done seldom.
OK if you can live with a bit of blocking. Use if formatDate() is not used much.
Fastest option IF you reuse threads (thread pool). Uses more memory than 2. and has higher startup overhead.
For applications both 2. and 3. are viable options. Which is best for your case depends on your use case. Beware of premature optimization. Only do it if you believe this is an issue.
For libraries that would be used by 3rd party I'd use option 3.
The other option is Commons Lang FastDateFormat but you can only use it for date formatting and not parsing.
Unlike Joda, it can function as a drop-in replacement for formatting.
(Update: Since v3.3.2, FastDateFormat can produce a FastDateParser, which is a drop-in thread-safe replacement for SimpleDateFormat)
If you are using Java 8, you may want to use java.time.format.DateTimeFormatter:
This class is immutable and thread-safe.
e.g.:
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd");
String str = new java.util.Date().toInstant()
.atZone(ZoneId.systemDefault())
.format(formatter);
Commons Lang 3.x now has FastDateParser as well as FastDateFormat. It is thread safe and faster than SimpleDateFormat. It also uses the same format/parse pattern specifications as SimpleDateFormat.
Don't use SimpleDateFormat, use joda-time's DateTimeFormatter instead. It is a bit stricter in the parsing side and so isn't quite a drop in replacement for SimpleDateFormat, but joda-time is much more concurrent friendly in terms of safety and performance.
I would say, create a simple wrapper-class for SimpleDateFormat that synchronizes access to parse() and format() and can be used as a drop-in replacement. More foolproof than your option #2, less cumbersome than your option #3.
Seems like making SimpleDateFormat unsynchronized was a poor design decision on the part of the Java API designers; I doubt anyone expects format() and parse() to need to be synchronized.
Another option is to keep instances in a thread-safe queue:
import java.util.concurrent.ArrayBlockingQueue;
private static final int DATE_FORMAT_QUEUE_LEN = 4;
private static final String DATE_PATTERN = "yyyy-MM-dd HH:mm:ss";
private ArrayBlockingQueue<SimpleDateFormat> dateFormatQueue = new ArrayBlockingQueue<SimpleDateFormat>(DATE_FORMAT_QUEUE_LEN);
// thread-safe date time formatting
public String format(Date date) {
SimpleDateFormat fmt = dateFormatQueue.poll();
if (fmt == null) {
fmt = new SimpleDateFormat(DATE_PATTERN);
}
String text = fmt.format(date);
dateFormatQueue.offer(fmt);
return text;
}
public Date parse(String text) throws ParseException {
SimpleDateFormat fmt = dateFormatQueue.poll();
if (fmt == null) {
fmt = new SimpleDateFormat(DATE_PATTERN);
}
Date date = null;
try {
date = fmt.parse(text);
} finally {
dateFormatQueue.offer(fmt);
}
return date;
}
The size of dateFormatQueue should be something close to the estimated number of threads which can routinely call this function at the same time.
In the worst case where more threads than this number do actually use all the instances concurrently, some SimpleDateFormat instances will be created which cannot be returned to dateFormatQueue because it is full. This will not generate an error, it will just incur the penalty of creating some SimpleDateFormat which are used only once.
I just implemented this with Option 3, but made a few code changes:
ThreadLocal should usually be static
Seems cleaner to override initialValue() rather than test if (get() == null)
You may want to set locale and time zone unless you really want the default settings (defaults are very error prone with Java)
private static final ThreadLocal<SimpleDateFormat> tl = new ThreadLocal<SimpleDateFormat>() {
#Override
protected SimpleDateFormat initialValue() {
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-hh", Locale.US);
sdf.setTimeZone(TimeZone.getTimeZone("America/Los_Angeles"));
return sdf;
}
};
public String formatDate(Date d) {
return tl.get().format(d);
}
Imagine your application has one thread. Why would you synchronize access to SimpleDataFormat variable then?