Java 中使用 SimpleDateFormat 格式化日期方法

本文深入剖析了Java中SimpleDateFormat的典型陷阱与安全实践，重点揭示其非线程安全本质——多线程复用会导致解析错乱、结果不可预测，而常见ParseException往往源于模式与字符串的细微不匹配（如时区缺失、月份越界、yy误读四位年份等）；文章强调必须采用局部变量方式创建并显式设置时区，同时强烈推荐升级至Java 8+的DateTimeFormatter——它不可变、线程安全、API直观且内置时区支持，从根本上规避隐患；即使无法升级，也务必杜绝static共享，因为看似安全的单线程用法，实则埋藏着未来并发场景下的高危雷区。

SimpleDateFormat 不是线程安全的，多线程环境下直接复用同一个实例会导致解析/格式化结果错乱——必须每次新建、局部使用，或加锁，或改用 DateTimeFormatter（推荐）。

为什么 SimpleDateFormat.parse() 会抛出 ParseException？

常见原因是传入字符串与模式不严格匹配，比如：

• 时区缺失但模式含 Z 或 z（如 "yyyy-MM-dd HH:mm:ss Z" 要求输入带 +0800）
• 月份写成 13 却用了 MM（它只接受 01–12）
• 年份用 yy 解析 "2024" 会当成 2020 年（yy 只读两位）
• 默认 lenient 模式开启时看似能解析，但关闭后（setLenient(false)）会立即报错

如何安全地格式化当前时间并输出为 "2024-05-21 14:30:45"？

用局部变量 + 明确模式，避免共享：

SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
sdf.setTimeZone(TimeZone.getTimeZone("GMT+8")); // 如需固定时区
String formatted = sdf.format(new Date());

注意：HH 是 24 小时制，hh 是 12 小时制；mm 是分钟，MM 是月份——大小写敏感，写错就出错。

替换方案：用 DateTimeFormatter 替代 SimpleDateFormat 的理由

DateTimeFormatter 是 Java 8+ 的标准替代，不可变、线程安全、API 更清晰：

• 预定义常量可直接用：DateTimeFormatter.ISO_LOCAL_DATE_TIME
• 自定义模式更直观：DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss")
• 时区支持更自然：LocalDateTime.now().atZone(ZoneId.of("Asia/Shanghai")).format(...)
• 不会因共享导致诡异 bug，也不需要手动同步

旧项目若无法升级到 Java 8，至少把 SimpleDateFormat 声明为方法内局部变量，别塞进 static 字段里。

真正容易被忽略的是：哪怕你只在单线程里用，只要这个 SimpleDateFormat 实例被多个方法共享（比如作为工具类的 static 成员），就可能在将来被无意引入并发场景——隐患藏得深，修复成本高。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。