I would expect data corruption - e.g. if you're parsing two dates at the same time, you could have one call polluted by data from another.

It's easy to imagine how this could happen: parsing often involves maintaining a certain amount of state as to what you've read so far. If two threads are both trampling on the same state, you'll get problems. For example, DateFormat exposes a calendar field of type Calendar, and looking at the code of SimpleDateFormat, some methods call calendar.set(...) and others call calendar.get(...). This is clearly not thread-safe.

I haven't looked into the exact details of why DateFormat isn't thread-safe, but for me it's enough to know that it is unsafe without synchronization - the exact manners of non-safety could even change between releases.

Personally I would use the parsers from Joda Time instead, as they are thread safe - and Joda Time is a much better date and time API to start with :)

If you are using Java 8 then you can use DateTimeFormatter.

A formatter created from a pattern can be used as many times as necessary, it is immutable and is thread-safe.

Code:

LocalDate date = LocalDate.now(); DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd"); String text = date.format(formatter); System.out.println(text); 

Output:

2017-04-17 

Roughly, that you should not define a DateFormat as instance variable of an object accessed by many threads, or static.

Date formats are not synchronized. It is recommended to create separate format instances for each thread.

So, in case your Foo.handleBar(..) is accessed by multiple threads, instead of:

public class Foo { private DateFormat df = new SimpleDateFormat("dd/mm/yyyy"); public void handleBar(Bar bar) { bar.setFormattedDate(df.format(bar.getStringDate()); } } 

you should use:

public class Foo { public void handleBar(Bar bar) { DateFormat df = new SimpleDateFormat("dd/mm/yyyy"); bar.setFormattedDate(df.format(bar.getStringDate()); } } 

Also, in all cases, don't have a static DateFormat

As noted by Jon Skeet, you can have both static and a shared instance variables in case you perform external synchronization (i.e. use synchronized around calls to the DateFormat)

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.

This means suppose you have a object of DateFormat and you are accessing same object from two different threads and you are calling format method upon that object both thread will enter on the same method at the same time on the same object so you can visualize it won't result in proper result

If you have to work with DateFormat any how then you should do something

public synchronized myFormat(){ // call here actual format method } 

• Reference

In the best answer dogbane gave an example of using parse function and what it leads to. Below is a code that let's you check format function.

Notice that if you change the number of executors (concurrent threads) you will get different results. From my experiments:

• Leave newFixedThreadPool set to 5 and the loop will fail every time.
• Set to 1 and the loop will always work (obviously as all tasks are actually run one by one)
• Set to 2 and the loop has only about 6% chance of working.

I'm guessing YMMV depending on your processor.

The format function fails by formatting time from a different thread. This is because internally format function is using calendar object which is set up at the start of the format function. And the calendar object is a property of the SimpleDateFormat class. Sigh...

/** * Test SimpleDateFormat.format (non) thread-safety. * * @throws Exception */ private static void testFormatterSafety() throws Exception { final SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"); final Calendar calendar1 = new GregorianCalendar(2013,1,28,13,24,56); final Calendar calendar2 = new GregorianCalendar(2014,1,28,13,24,56); String expected[] = {"2013-02-28 13:24:56", "2014-02-28 13:24:56"}; Callable<String> task1 = new Callable<String>() { @Override public String call() throws Exception { return "0#" + format.format(calendar1.getTime()); } }; Callable<String> task2 = new Callable<String>() { @Override public String call() throws Exception { return "1#" + format.format(calendar2.getTime()); } }; //pool with X threads // note that using more then CPU-threads will not give you a performance boost ExecutorService exec = Executors.newFixedThreadPool(5); List<Future<String>> results = new ArrayList<>(); //perform some date conversions for (int i = 0; i < 1000; i++) { results.add(exec.submit(task1)); results.add(exec.submit(task2)); } exec.shutdown(); //look at the results for (Future<String> result : results) { String answer = result.get(); String[] split = answer.split("#"); Integer calendarNo = Integer.parseInt(split[0]); String formatted = split[1]; if (!expected[calendarNo].equals(formatted)) { System.out.println("formatted: " + formatted); System.out.println("expected: " + expected[calendarNo]); System.out.println("answer: " + answer); throw new Exception("formatted != expected"); /** } else { System.out.println("OK answer: " + answer); /**/ } } System.out.println("OK: Loop finished"); } 

Data is corrupted. Yesterday I noticed it in my multithread program where I had static DateFormat object and called its format() for values read via JDBC. I had SQL select statement where I read the same date with different names (SELECT date_from, date_from AS date_from1 ...). Such statements were using in 5 threads for various dates in WHERE clasue. Dates looked "normal" but they differed in value -- while all dates were from the same year only month and day changed.

Others answers show you the way to avoid such corruption. I made my DateFormat not static, now it is a member of a class that calls SQL statements. I tested also static version with synchronizing. Both worked well with no difference in performance.

The specifications of Format, NumberFormat, DateFormat, MessageFormat, etc. were not designed to be thread-safe. Also, the parse method calls on Calendar.clone() method and it affects calendar footprints so many threads parsing concurrently will change the cloning of the Calendar instance.

For more, these are bug reports such as this and this, with results of DateFormat thread-safety issue.

If there are multiple threads manipulating/accessing a single DateFormat instance and synchronization not used, it's possible to get scrambled results. That's because multiple non-atomic operations could be changing state or seeing memory inconsistently.

This is my simple code that shows DateFormat is not thread safe.

import java.text.ParseException; import java.text.SimpleDateFormat; import java.util.Date; import java.util.Locale; public class DateTimeChecker { static DateFormat df = new SimpleDateFormat("EEE MMM dd kk:mm:ss z yyyy", Locale.ENGLISH); public static void main(String args[]){ String target1 = "Thu Sep 28 20:29:30 JST 2000"; String target2 = "Thu Sep 28 20:29:30 JST 2001"; String target3 = "Thu Sep 28 20:29:30 JST 2002"; runThread(target1); runThread(target2); runThread(target3); } public static void runThread(String target){ Runnable myRunnable = new Runnable(){ public void run(){ Date result = null; try { result = df.parse(target); } catch (ParseException e) { e.printStackTrace(); System.out.println("Ecxfrt"); } System.out.println(Thread.currentThread().getName() + " " + result); } }; Thread thread = new Thread(myRunnable); thread.start(); } } 

Since all the threads are using the same SimpleDateFormat object, it throws the following exception.

Exception in thread "Thread-0" Exception in thread "Thread-2" Exception in thread "Thread-1" java.lang.NumberFormatException: multiple points at sun.misc.FloatingDecimal.readJavaFormatString(Unknown Source) at sun.misc.FloatingDecimal.parseDouble(Unknown Source) at java.lang.Double.parseDouble(Unknown Source) at java.text.DigitList.getDouble(Unknown Source) at java.text.DecimalFormat.parse(Unknown Source) at java.text.SimpleDateFormat.subParse(Unknown Source) at java.text.SimpleDateFormat.parse(Unknown Source) at java.text.DateFormat.parse(Unknown Source) at DateTimeChecker$1.run(DateTimeChecker.java:24) at java.lang.Thread.run(Unknown Source) java.lang.NumberFormatException: multiple points at sun.misc.FloatingDecimal.readJavaFormatString(Unknown Source) at sun.misc.FloatingDecimal.parseDouble(Unknown Source) at java.lang.Double.parseDouble(Unknown Source) at java.text.DigitList.getDouble(Unknown Source) at java.text.DecimalFormat.parse(Unknown Source) at java.text.SimpleDateFormat.subParse(Unknown Source) at java.text.SimpleDateFormat.parse(Unknown Source) at java.text.DateFormat.parse(Unknown Source) at DateTimeChecker$1.run(DateTimeChecker.java:24) at java.lang.Thread.run(Unknown Source) java.lang.NumberFormatException: multiple points at sun.misc.FloatingDecimal.readJavaFormatString(Unknown Source) at sun.misc.FloatingDecimal.parseDouble(Unknown Source) at java.lang.Double.parseDouble(Unknown Source) at java.text.DigitList.getDouble(Unknown Source) at java.text.DecimalFormat.parse(Unknown Source) at java.text.SimpleDateFormat.subParse(Unknown Source) at java.text.SimpleDateFormat.parse(Unknown Source) at java.text.DateFormat.parse(Unknown Source) at DateTimeChecker$1.run(DateTimeChecker.java:24) at java.lang.Thread.run(Unknown Source) 

But if we pass different objects to different threads, the code runs without errors.

import java.text.ParseException; import java.text.SimpleDateFormat; import java.util.Date; import java.util.Locale; public class DateTimeChecker { static DateFormat df; public static void main(String args[]){ String target1 = "Thu Sep 28 20:29:30 JST 2000"; String target2 = "Thu Sep 28 20:29:30 JST 2001"; String target3 = "Thu Sep 28 20:29:30 JST 2002"; df = new SimpleDateFormat("EEE MMM dd kk:mm:ss z yyyy", Locale.ENGLISH); runThread(target1, df); df = new SimpleDateFormat("EEE MMM dd kk:mm:ss z yyyy", Locale.ENGLISH); runThread(target2, df); df = new SimpleDateFormat("EEE MMM dd kk:mm:ss z yyyy", Locale.ENGLISH); runThread(target3, df); } public static void runThread(String target, DateFormat df){ Runnable myRunnable = new Runnable(){ public void run(){ Date result = null; try { result = df.parse(target); } catch (ParseException e) { e.printStackTrace(); System.out.println("Ecxfrt"); } System.out.println(Thread.currentThread().getName() + " " + result); } }; Thread thread = new Thread(myRunnable); thread.start(); } } 

These are the results.

Thread-0 Thu Sep 28 17:29:30 IST 2000 Thread-2 Sat Sep 28 17:29:30 IST 2002 Thread-1 Fri Sep 28 17:29:30 IST 2001 

This will cause ArrayIndexOutOfBoundsException

Apart from the incorrect result, it will give you a crash from time to time. It depends on the speed your machine; in my laptop, it happens once in 100,000 calls on average:

SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd"); ExecutorService executorService = Executors.newFixedThreadPool(2); Future<?> future1 = executorService.submit(() -> { for (int i = 0; i < 99000; i++) { sdf.format(Date.from(LocalDate.parse("2019-12-31").atStartOfDay().toInstant(UTC))); } }); executorService.submit(() -> { for (int i = 0; i < 99000; i++) { sdf.format(Date.from(LocalDate.parse("2020-04-17").atStartOfDay().toInstant(UTC))); } }); future1.get(); 

the last line sould trigger the postponed executor exception:

java.lang.ArrayIndexOutOfBoundsException: Index 16 out of bounds for length 13 at java.base/sun.util.calendar.BaseCalendar.getCalendarDateFromFixedDate(BaseCalendar.java:453) at java.base/java.util.GregorianCalendar.computeFields(GregorianCalendar.java:2394) at java.base/java.util.GregorianCalendar.computeFields(GregorianCalendar.java:2309) at java.base/java.util.Calendar.complete(Calendar.java:2301) at java.base/java.util.Calendar.get(Calendar.java:1856) at java.base/java.text.SimpleDateFormat.subFormat(SimpleDateFormat.java:1150) at java.base/java.text.SimpleDateFormat.format(SimpleDateFormat.java:997) at java.base/java.text.SimpleDateFormat.format(SimpleDateFormat.java:967) at java.base/java.text.DateFormat.format(DateFormat.java:374)