SimpleDateFormat非线程安全，因内部Calendar状态并发修改导致解析错误；应使用static final ThreadLocal封装，或升级为线程安全的DateTimeFormatter。
SimpleDateFormat 本身不是线程安全的，多个线程共用同一个实例时，可能因内部 Calendar 状态被并发修改而出现解析错误、格式错乱甚至抛出异常。用 ThreadLocal 包装是常见且有效的解决方案——每个线程独享一个 SimpleDateFormat 实例，彻底规避竞争。
为什么不能直接共享 SimpleDateFormat 实例
SimpleDateFormat 的 parse() 和 format() 方法会修改其内部的 Calendar 字段（如 calendar.setTime()、calendar.add()），这些操作非原子、无同步保护。即使只读调用 format()，底层仍会调用 calendar.clear() → calendar.set() → calendar.getTime()，中间状态可能被其他线程打断。
用 ThreadLocal 封装的标准写法
推荐使用 static final ThreadLocal<SimpleDateFormat>，并在 get() 时初始化实例，避免重复构造开销：
private static final ThreadLocal<SimpleDateFormat> DATE_FORMAT = ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"));
使用时直接调用：
- 格式化：DATE_FORMAT.get().format(new Date())
- 解析：DATE_FORMAT.get().parse("2026-07-13 22:54:00")
- 每次 get() 返回的是当前线程专属的实例，无需手动 remove()
注意 setLenient 和 TimeZone 的一致性
ThreadLocal 实例默认继承父线程的 lenient 和 timezone 设置，但若业务需要统一行为（比如严格解析、固定时区），应在初始化时显式设置：
- DATE_FORMAT.get().setLenient(false); // 防止 "2026-02-30" 被转成 2026-03-02
- DATE_FORMAT.get().setTimeZone(TimeZone.getTimeZone("GMT+8")); // 避免系统默认时区干扰
建议把这些设置写在 withInitial 的 lambda 里，确保每个线程实例初始化即生效。
替代方案：Java 8+ 推荐用 DateTimeFormatter
DateTimeFormatter 是不可变、线程安全的，无需 ThreadLocal：
- DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss");
- LocalDateTime.parse("2026-07-13 22:54:00", formatter)
- formatter.format(LocalDateTime.now())
如果项目已升级到 Java 8 或更高版本，优先迁移，更简洁、更安全、语义更清晰。
