datetimeformatter 线程安全源于不可变设计，所有字段为final、无共享可变状态，多线程调用format/parse无竞态，可static final复用，零同步开销，行为确定且无需额外防护。
DateTimeFormatter 的线程安全不是“加了锁”或“靠运气”，而是从设计根源上杜绝了并发冲突——它根本不持有任何可变状态。
不可变性是安全的底层基础
DateTimeFormatter 所有字段都是 final，构造完成后完全不可修改。无论是模式字符串、时区、语言环境还是解析规则，一旦创建就固定不变。多个线程同时调用它的 format() 或 parse() 方法，实际只是读取同一份只读数据，不存在“谁改了谁的状态”问题。
- 可以放心定义为
static final，全局复用，零同步开销 - 无需担心方法调用间状态残留（比如 SimpleDateFormat 中
calendar.clear()和set()之间的竞态） - 没有内部 Calendar 实例，也就没有跨操作的中间非法状态（如 “2023-00-00”）
无共享状态，天然免同步
SimpleDateFormat 的线程不安全，本质是多个线程争抢修改同一个 Calendar 对象；而 DateTimeFormatter 每次格式化或解析，都基于传入的不可变时间对象（如 LocalDateTime）独立计算，全程不写任何共享变量。
- 不需要
synchronized块，也不依赖ThreadLocal封装 - 在线程池中长期复用无内存泄漏风险（对比 ThreadLocal
必须手动 remove()） - 高并发场景下吞吐量稳定，不会因锁竞争导致性能陡降
行为确定，结果可预期
由于无状态+不可变，DateTimeFormatter 在任意线程、任意时刻的行为完全一致：相同输入永远产生相同输出，不会因其他线程刚执行过某次解析而影响本次格式化结果。
- 避免了 SimpleDateFormat 常见的诡异错误：解析出错、格式化乱码、甚至抛
NullPointerException - 调试和排查问题更直接——不用怀疑是不是“被别的线程污染了”
- 单元测试无需模拟多线程环境也能验证逻辑正确性
与旧 API 的兼容成本低但收益明确
迁移到 DateTimeFormatter 不需要重构整个时间模型，只需替换格式化工具类，并注意几处关键差异：
- 模式字母大小写敏感（
yyyy正确，YYYY表示周年度，易出错） - 解析默认严格（多余空格或字符直接报错），需宽松时可用
DateTimeFormatterBuilder显式配置 - 若需与旧 Date 交互，通过
Instant桥接（如localDateTime.atZone(ZoneId.systemDefault()).toInstant()）
本质上，DateTimeFormatter 把“线程安全”变成了默认属性，而不是开发者必须主动防御的问题。这不是功能增强，而是范式升级——从“怎么让它不出错”，变成“它本来就不会错”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
