LocalDate 和 LocalTime 通过不可变性实现线程安全，所有字段为 final 且无 set 方法，每次操作返回新实例；误用如共享可变引用或 static 赋值会破坏安全性，正确做法是局部使用、避免状态共享。
Java 8 的 LocalDate 和 LocalTime 本身是线程安全的，关键不在“会不会出错”，而在于“怎么用才不破坏这个安全性”。它们靠不可变性（immutability）实现线程安全——创建后不能改，每次操作都返回新对象，自然不存在并发修改问题。
理解“不可变”才是核心
这两个类所有字段都是 final，没有提供任何 setXXX() 方法。比如：
LocalDate today = LocalDate.now();-
LocalDate tomorrow = today.plusDays(1);——today没变，tomorrow是全新实例 - 就算十个线程同时对同一个
today调用plusDays(1)，结果也互不影响
线程安全≠可以随便共享引用
安全的前提是：你没把它当“可变容器”误用。常见误用包括：
- 把
LocalDate声明为static变量并反复赋值（如public static LocalDate CURRENT_DAY = ...），这破坏了不可变语义 - 在多线程中用同一个变量反复接收不同计算结果（
date = date.plusDays(1)看似链式，实则每次覆盖引用，若该变量被多线程共用，逻辑就乱了） - 混淆
LocalDateTime.now()的时区依赖——它默认用系统时区，若多台机器时区不一致，结果就不一致，但这不是线程安全问题，而是设计一致性问题
正确用法：轻量、局部、无状态
最佳实践是让实例生命周期短、作用域小：
立即学习“Java免费学习笔记（深入）”；
- 方法内临时创建：如 Web 接口里直接用
LocalDate.now()或LocalTime.now() - 作为参数或返回值传递，不保存为成员变量（除非明确是只读配置，如“业务截止日”）
- 需要跨时区处理时，改用
ZonedDateTime或统一转成Instant，避免依赖本地时钟 - 解析字符串必须用
DateTimeFormatter显式指定格式，不要依赖默认；格式器本身也是不可变、线程安全的，可复用
和旧 API 对比着看更清楚
Date 类的问题不是“不能并发”，而是它的方法（如 setTime()、setYear()）会直接改内部状态，多个线程一调就冲突。而 LocalDate 根本没有这种入口——你连“改”的机会都没有，自然安枕无忧。
所以掌握线程安全性，本质是养成“只创建、不修改、不共享可变状态”的习惯。它不像加锁那样需要刻意保护，而像用 String 一样自然可靠。
