ThreadLocal.withInitial()是静态工厂方法，本质是接收Supplier接口实现惰性初始化：每个线程首次调用get()时才执行一次supplier.get()生成初始值，不支持传入上下文参数，也不在声明时执行。
ThreadLocal.withInitial() 的本质是 Supplier 函数式接口
ThreadLocal.withInitial() 并不是构造器重载，而是静态工厂方法，它接收一个 Supplier<T>，用于在线程首次调用 get() 时惰性生成初始值。这意味着：它不会在声明时执行初始化逻辑，而是在每个线程第一次 get() 时才调用一次该 Supplier。
常见错误是传入有副作用的 lambda 却误以为“每线程只执行一次”很安全——其实只要该 Supplier 抛异常，get() 就会直接失败，且后续再调用仍会重试（除非手动 set）。
- 必须确保 Supplier 不抛受检异常；若需处理异常，应在 lambda 内捕获并转为默认值或运行时异常
- 不能依赖外部可变状态（如共享 counter）来生成初始值，否则线程安全无法保证
- 返回 null 是合法的，但若业务逻辑不允许 null，应在 Supplier 内做兜底（如 new ArrayList<>()）
正确写法示例：避免常见陷阱
下面这段代码看似合理，实则危险：
ThreadLocal<SimpleDateFormat> sdf = ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd"));
问题在于 SimpleDateFormat 非线程安全，且每次 get() 都新建实例——浪费对象、GC 压力大，但更关键的是：如果想复用格式化逻辑（比如加时区、设 lenient），这种写法无法统一配置。
立即学习“Java免费学习笔记（深入）”；
推荐写法是封装初始化逻辑，确保可读且可控：
ThreadLocal<DateTimeFormatter> formatter = ThreadLocal.withInitial(() ->
DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss").withZone(ZoneId.systemDefault())
);
- 用
DateTimeFormatter替代SimpleDateFormat（不可变、线程安全、推荐替代方案） - 初始化逻辑内联清晰，不依赖外部变量
- 若需更复杂初始化（如从配置加载），应提取为私有 static 方法，避免 lambda 过长
和传统 new ThreadLocal<>(){ initialValue() } 的区别
老式匿名内部类写法：
ThreadLocal<List<String>> listHolder = new ThreadLocal<>() {
@Override
protected List<String> initialValue() {
return new ArrayList<>();
}
};
与 withInitial() 行为一致，但有三点实际差异：
- 字节码更重：匿名类会生成额外 .class 文件；
withInitial()编译后只是函数式接口实例 - 无法序列化：匿名类持对外部 this 的隐式引用，容易导致
NotSerializableException；withInitial()的 lambda 若不捕获实例变量，则天然可序列化 - IDE 支持更好：
withInitial()能被 Lombok 的@Cleanup或静态分析工具识别初始值来源
什么时候不该用 withInitial()？
当初始值需要“按线程上下文动态计算”时，withInitial() 就不够用了。例如：根据当前 MDC 中的 traceId 初始化日志上下文对象，或读取当前 SecurityContext 构造认证信息。
此时必须用 new ThreadLocal<>() { initialValue() } 或干脆放弃自动初始化，在 get() 后判空手动构建：
if (context.get() == null) {
context.set(buildFromMdc());
}
因为 withInitial() 的 Supplier 没有参数，拿不到当前线程的任何上下文信息——这是设计使然，不是 bug。
真正容易被忽略的是：一旦用了 withInitial()，就放弃了对“首次 get 时机”的细粒度控制。如果初始化成本高（如打开文件、查数据库），又希望延迟到真正需要时才触发，那没问题；但如果初始化逻辑依赖尚未就绪的线程局部状态，就得绕开它。
