应避免使用 simpledateformat.parse() 处理时间戳，正确做法是用 new date(long) 构造再 format()；需显式设置时区防止偏移；因其线程不安全，推荐每次 new、threadlocal 封装或升级到 java 8 的 datetimeformatter。
SimpleDateFormat.parse() 报 ParseException 怎么办
时间戳是长整型（long），而 SimpleDateFormat.parse() 只接受字符串，直接传数字会编译报错；更常见的是误把毫秒时间戳当秒传入，再用 parse() 去“解析”，结果抛出 ParseException——它根本不是干这个的。
正确做法是先用 new Date(long) 构造日期对象，再交给 SimpleDateFormat.format() 转成字符串。别碰 parse()，除非你真在处理形如 "2024-03-15 14:23:00" 的字符串输入。
-
SimpleDateFormat不处理时间戳，只负责字符串 ↔Date的双向转换 - 时间戳 → 字符串：先
new Date(timestamp)，再format() - 字符串 → 时间戳：先
parse()得Date，再调getTime()
时区错乱、比实际时间快8小时的原因
默认情况下，SimpleDateFormat 使用 JVM 启动时的本地时区（比如东八区），但如果你的原始时间戳来自 UTC 服务（如数据库、API 返回的 Unix 时间戳），没显式设时区就会差出整块偏移量。
解决方式不是靠“猜”或改系统时区，而是明确指定：
- 用
simpleDateFormat.setTimeZone(TimeZone.getTimeZone("UTC"))统一按 UTC 解析/格式化 - 若要输出为北京时间，用
"GMT+8"或"Asia/Shanghai"（后者更稳妥，能自动处理夏令时） - 避免依赖
SimpleDateFormat的默认行为，每次创建后立刻设时区
SimpleDateFormat 是线程不安全的，多线程下怎么用
多个线程共用同一个 SimpleDateFormat 实例，会出现格式错乱、解析失败甚至返回 null——这不是偶发 bug，是设计如此。内部缓存了 Calendar 和中间状态，没法并发。
有三种实际可用方案，按推荐顺序：
- 每次用都 new 一个：
new SimpleDateFormat("yyyy-MM-dd HH:mm:ss")（小流量、低频调用够用） - 用
ThreadLocal<simpledateformat></simpledateformat>包一层，保证线程独占实例 - 升级到 Java 8+，改用
DateTimeFormatter+Instant/ZonedDateTime（真正不可变、线程安全）
别试图加锁包装 SimpleDateFormat，性能差且容易漏锁。
Java 8 以后还该用 SimpleDateFormat 吗
不该。从 Java 8 开始，SimpleDateFormat 就被标记为 legacy，官方明确建议迁移到 java.time 包。它的核心问题不只是线程安全，还有设计反直觉（比如月份从 0 开始）、时区支持弱、无法处理纳秒精度等。
对应迁移很简单：
- 时间戳 → 字符串：
Instant.ofEpochMilli(timestamp).atZone(ZoneId.of("Asia/Shanghai")).format(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss")) - 字符串 → 时间戳：
LocalDateTime.parse(str, DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss")).atZone(ZoneId.systemDefault()).toInstant().toEpochMilli() -
DateTimeFormatter是 immutable、线程安全的，可复用全局实例
老项目里如果还有大量 SimpleDateFormat，优先在新逻辑中用 java.time，旧代码不必强改，但别再新增。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
