java旧版date类本身线程安全，问题源于共享的simpledateformat和calendar；解决方法包括threadlocal隔离、局部变量新建、同步块加锁及迁移到java 8+不可变时间api。
Java 旧版 Date 类本身不是线程不安全的“根源”，真正出问题的是它常被配合使用的 SimpleDateFormat 和 Calendar ——它们内部持有可变状态，且未做同步保护。只要多个线程共享同一个实例，就可能相互覆盖时间字段、解析错乱、抛出 NumberFormatException 或返回错误日期（比如全为 1970-01-01 或离谱年份）。解决核心思路是：避免共享可变状态。
用 ThreadLocal 隔离每个线程的格式化器
这是兼容 JDK 6/7 的主流方案，适合无法升级到 Java 8 的老项目：
- 每个线程独享一个
SimpleDateFormat实例，彻底避开竞争 - 必须用
ThreadLocal.withInitial()初始化，确保首次获取即创建，避免 null 风险 - 记得设置时区和宽松模式：
sdf.setTimeZone(TimeZone.getTimeZone("GMT+8"))、sdf.setLenient(false)
把 SimpleDateFormat 声明为方法内局部变量
适用于调用频次不高、性能不敏感的场景：
- 每次 format 或 parse 都新建对象，天然线程安全
- 缺点是频繁创建对象带来 GC 压力，不建议在高频日志、导出等场景使用
- 注意：不要为了“省对象”而把它提升为成员变量或 static 变量
加 synchronized 锁住操作块
最直接但最影响并发性能的方式：
- 对 format / parse 调用加锁，保证同一时刻只有一个线程执行
- 适合低并发、代码改动最小的临时修复
- 锁粒度大，高并发下容易成为瓶颈，不推荐长期使用
迁移到 Java 8+ 的新时间 API（强烈推荐）
这是根本性解法，从设计上杜绝隐患：
-
LocalDateTime、ZonedDateTime等类全部final，字段private final，所有操作如plusDays()、withHour()都返回新对象 -
DateTimeFormatter不可变，可安全定义为static final - 职责分离清晰：时区、格式化、计算不再耦合在一个 Calendar 实例里
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
