SimpleDateFormat非线程安全，因其内部Calendar和ParsePosition等状态可变且共享；多线程共用会导致解析错乱、异常或错误结果；推荐使用ThreadLocal隔离或直接采用线程安全的DateTimeFormatter。
SimpleDateFormat 不是线程安全的，根本原因在于它内部持有可变的 Calendar 实例和解析位置（ParsePosition）等共享状态。当多个线程共用同一个实例调用 parse() 或 format() 时，彼此会互相覆盖中间状态，导致解析错乱、格式化异常，甚至抛出 ParseException、NumberFormatException 或返回错误日期——这类问题往往静默发生，极难复现和排查。
为什么共享 SimpleDateFormat 很危险
一个典型的静态声明：private static final SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");
看似节省对象创建开销，实则埋下隐患。比如线程 A 正在执行 sdf.parse("2026-05-01")，刚调完 calendar.clear() 还没设值，线程 B 就插入执行并重置了同一 Calendar；A 继续执行时拿到的是 B 的中间结果，最终可能得到 “2026-01-01” 或其他错误时间。
ThreadLocal 是轻量可靠的隔离方案
它为每个线程提供独立副本，避免竞争，无需锁，性能好，且语义清晰。推荐用 ThreadLocal.withInitial() 延迟初始化：
- 声明为
static final，只初始化一次 ThreadLocal 容器本身 - 每个线程首次调用
get()时才创建专属的SimpleDateFormat实例 - 无需手动
remove()（线程池场景下建议在 finally 块中 remove，防止内存泄漏）
示例：
private static final ThreadLocal<SimpleDateFormat> DATE_FORMATTER =<br> ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"));
public static String format(Date date) {<br> return DATE_FORMATTER.get().format(date);<br>}
比 ThreadLocal 更优的选择：DateTimeFormatter
Java 8 引入的 java.time.format.DateTimeFormatter 是不可变、无状态、天然线程安全的。它不依赖 Calendar，所有方法都是纯函数式操作：
- 直接复用同一个实例，无需 ThreadLocal 封装
- 性能优于 SimpleDateFormat + ThreadLocal 组合
- 支持更丰富的 ISO 和自定义模式，例如
DateTimeFormatter.ofPattern("uuuu-MM-dd")
迁移成本低：只需将 Date → LocalDateTime / ZonedDateTime 转换，再调用 format() 或 parse() 即可。
其他可行但不推荐的方案
局部变量法虽安全，但高频调用会频繁创建对象，增加 GC 压力；synchronized 锁会串行化执行，严重拖慢高并发吞吐；Lock 同理，还引入额外复杂度。这些方案仅适用于低频、临时或遗留系统无法升级的场景。
