Resolving SimpleDateFormat Thread Safety Issues with ThreadLocal in Java

Java developers are familiar with SimpleDateFormat , a class used for parsing and formatting dates, but many overlook that it is not thread‑safe because it internally holds a mutable Calendar object whose state is modified without atomicity.

A multithreaded demo is provided where several threads concurrently use a shared SimpleDateFormat instance, producing incorrect or inconsistent output, thereby confirming the thread‑safety issue.

The article outlines three common ways to avoid the problem: (1) instantiate a new SimpleDateFormat for each use, which eliminates contention but incurs object‑creation overhead; (2) synchronize access to a shared instance, which guarantees correctness at the cost of performance; and (3) employ ThreadLocal to give each thread its own formatter, which is both efficient and safe.

The ThreadLocal solution is explained in detail: each thread maintains a private ThreadLocalMap that stores the formatter, ensuring isolation of state. Sample code shows a ThreadLocal<SimpleDateFormat> variable, its get() method, and usage within threads, followed by execution results that demonstrate correct formatting without race conditions.

Additional notes discuss the memory‑leak risk of ThreadLocal when used with thread pools: the map’s keys are weak references, but values remain strongly referenced by the thread, so if the thread lives longer than needed, the stored formatter may not be reclaimed. The article advises calling ThreadLocal.remove() or relying on the internal cleanup mechanism to prevent leaks.