java中simpledateformat线程不安全，因其内部calendar状态共享且无同步；推荐用datetimeformatter（不可变、线程安全）；次选threadlocal隔离实例；新建对象适用于低频场景；加锁性能差，不推荐。
Java 中 SimpleDateFormat 的线程不安全问题，本质是它内部持有可变的 Calendar 实例，且所有操作都读写这个共享状态，没有同步保护。多线程共用同一个实例时，会出现格式错乱、解析异常（如 NumberFormatException: "20.20.20"）、时间跳变（如变成 1970 年或 2055 年）等现象。彻底解决需从设计层面切断共享状态，而非临时加锁。
优先用 Java 8+ 的 DateTimeFormatter
这是最推荐、最根本的解法。DateTimeFormatter 是不可变（immutable）、无状态、线程安全的，API 更清晰，还支持时区、本地化等高级能力。
- 直接声明为
static final安全使用：private static final DateTimeFormatter FORMATTER = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"); - 格式化：
String s = LocalDateTime.now().format(FORMATTER); - 解析：
LocalDateTime dt = LocalDateTime.parse("2026-10-09 20:40:00", FORMATTER); - 如需 Date 兼容，可用
Instant和Date.from(instant)转换，但建议逐步迁移至 java.time 类型体系
用 ThreadLocal 隔离 SimpleDateFormat 实例
若暂不能升级到 java.time（如维护老项目），ThreadLocal 是兼顾安全与性能的成熟方案——每个线程独享一个 SimpleDateFormat 实例，避免竞争又不频繁创建对象。
- 务必用
withInitial()初始化：private static final ThreadLocal<simpledateformat> SDF = ThreadLocal.withInitial(() -> {<br> SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");<br> sdf.setTimeZone(TimeZone.getTimeZone("GMT+8")); // 必设时区<br> sdf.setLenient(false); // 关闭宽松模式，防误解析<br> return sdf;<br>});</simpledateformat> - 使用时：
SDF.get().format(date)或SDF.get().parse(str) - 注意：用完无需手动 remove，但若在线程池中长期复用线程，建议在业务逻辑末尾调用
SDF.remove()防止内存泄漏
每次使用都新建 SimpleDateFormat
适用于低频、非核心路径（如日志打印、配置加载），实现最简单，但有明显开销。
- 方法内 new：
public String format(Date date) {<br> return new SimpleDateFormat("yyyy-MM-dd").format(date);<br>} - 优点：绝对安全，无共享，无状态管理负担
- 缺点：频繁构造对象增加 GC 压力；pattern 编译（内部正则解析）重复执行，影响性能；不适用于高并发导出、报表等场景
加锁同步（仅作了解，不推荐生产使用）
对共享 SimpleDateFormat 加 synchronized 或 ReentrantLock，能保证安全，但严重牺牲吞吐量，属于“治标不治本”。
- 示例：
synchronized (SDF) { return SDF.format(date); } - 问题：所有线程串行排队，QPS 直线下降；锁粒度大，容易成为瓶颈；无法规避 Calendar 内部状态被污染的风险（尤其 parse + format 混用时）
- 只适合极低并发、临时修复、或已有代码无法重构的兜底手段
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
