SimpleDateFormat 被公认为经典的线程不安全类，主要原因在于其内部实现机制在多线程环境下存在严重的设计缺陷。以下是其线程不安全的核心原因及典型表现：
1. 可变内部状态共享
SimpleDateFormat 继承自 DateFormat，内部维护了一个共享的 Calendar 实例（protected Calendar calendar）。该实例在日期解析（parse()）和格式化（format()）过程中会被反复修改状态。例如：
- **
format()方法**：会调用calendar.setTime(date)修改日历对象的时间字段； - **
parse()方法**：同样会操作同一个 Calendar 实例来存储解析结果。
当多线程并发调用这些方法时，不同线程可能同时修改或读取 Calendar 的状态，导致数据混乱。例如：
- 线程A正在格式化日期时，线程B突然修改了 Calendar 的时间，导致线程A输出错误结果；
- 线程C解析日期时，线程D的格式化操作可能覆盖 Calendar 的中间状态，引发
ArrayIndexOutOfBoundsException或NumberFormatException。
2. 竞态条件与数据损坏
由于 SimpleDateFormat 的解析和格式化操作是非原子性的，多线程共享同一实例时可能出现以下典型问题：
- 日期值错误：如年份被重置为1970、分钟溢出为无效值；
- 不一致的输出：同一日期字符串经同一实例解析后，不同线程得到不同的 Date 对象；
- 异常抛出 ：如
ParseException或NumberFormatException，甚至出现无报错但生成错误结果的"静默失败"。
3. 静态修饰符加剧风险
开发者常误以为用 static final修饰 SimpleDateFormat 可保证线程安全，实则相反：
static使实例被所有线程共享，而final仅保证引用不可变，无法阻止内部状态被并发修改；- 示例代码中，多线程共享
static final SimpleDateFormat时，可能输出诸如2113-08-28 17:05:30（明显错误的年份）或00:00:00（时间被重置）的异常结果。
4. 与线程安全类的对比
Java 8 引入的 DateTimeFormatter通过 不可变对象 设计解决了这一问题：
- 所有状态在构造时初始化，无共享可变数据；
- 无需同步或线程隔离即可安全并发使用。
总结
SimpleDateFormat 的线程不安全本质源于其 共享可变状态 的设计，加上开发者对其 static使用的误解，使其成为 Java 并发编程中的经典陷阱。解决方案包括使用 ThreadLocal 隔离实例、同步锁（性能较差）或直接升级到线程安全的 DateTimeFormatter（Java 8+推荐）。