ThreadLocal & Thread Confinement

ThreadLocal combined with thread pools causes data leaks (next task sees the previous task's value) and memory leaks (values never garbage collected), so you must always call threadLocal.remove() in a finally block.

SimpleDateFormat is not thread-safe because it writes to a shared mutable Calendar field internally; fix it with ThreadLocal<SimpleDateFormat> or, better, use the immutable DateTimeFormatter from java.time.

InheritableThreadLocal copies the parent's value to a child at thread creation, but in a pool the parent is the pool creator and workers are reused, so the inherited value is stale and leaks context between tasks: propagate context explicitly instead.

Data that one thread alone can touch needs no lock: confine it to the stack or to a ThreadLocal and the race condition cannot exist.

Never let `this` leave the constructor: publish the object only after it is fully built, using a static factory or a separate init step.

For a thread-safe Singleton, prefer the Bill Pugh holder idiom for lazy loading or the enum for the simplest bulletproof version.