UnaryOperator 本身无状态且无线程隔离能力，需结合 ThreadLocal 实现线程私有数据隔离；正确做法是将 ThreadLocal 声明为 static final 或类成员，避免在 apply() 中新建，以防内存泄漏和失效。
Java 中 UnaryOperator 本身是无状态的函数式接口，不自带线程隔离能力；要实现线程私有数据隔离，需主动结合 ThreadLocal 封装逻辑，而非在 UnaryOperator 内部“直接使用”它。
ThreadLocal 需要被持有，不能仅在 apply() 中临时创建
ThreadLocal 的作用是为每个线程提供独立副本，必须作为外部变量（如静态字段、实例字段或闭包捕获的局部变量）存在，才能复用其隔离能力。若每次在 apply() 中 new 一个 ThreadLocal，就失去了意义——每个调用都新建，无法共享本线程内的一致状态。
- ✅ 正确：声明为
static final ThreadLocal<T>或类成员，确保生命周期覆盖多次apply()调用 - ❌ 错误：在
apply()方法体内写new ThreadLocal<>()—— 这样只对本次调用有效，且未清理，易内存泄漏
把 ThreadLocal 作为上下文载体，封装进 UnaryOperator
常见做法是将 ThreadLocal 的 get/set 逻辑隐藏在 UnaryOperator 实现中，让操作看起来“无感”，但实际依赖线程本地值。例如：需要对字符串做带计数前缀的转换，每线程独立计数：
static final ThreadLocal<Integer> counter = ThreadLocal.withInitial(() -> 0);
UnaryOperator<String> prefixedByThreadCount = s -> {
int count = counter.get();
counter.set(count + 1);
return "[" + count + "]" + s;
};
这样每个线程调用该 operator 时，看到的是自己线程的计数器，互不干扰。
立即学习“Java免费学习笔记（深入）”；
注意 cleanup 和初始值设计
ThreadLocal 不会自动清理，尤其在线程复用场景（如线程池）下，残留值可能影响后续任务：
- 推荐使用
withInitial()设置默认值，避免 null 判断 - 若状态较重（如缓存对象），应在适当时机调用
remove()—— 可在 operator 执行后手动清理，或配合try-finally保障 - 不要依赖线程结束自动回收：线程池中的线程长期存活，
ThreadLocal值会持续占用内存
替代思路：用闭包捕获 ThreadLocal 实例
如果不想用 static 字段，也可通过工厂方法返回绑定特定 ThreadLocal 的 operator：
public static UnaryOperator<String> createCounterPrefixer() {
ThreadLocal<Integer> localCount = ThreadLocal.withInitial(() -> 0);
return s -> {
int n = localCount.get();
localCount.set(n + 1);
return "(" + n + ") " + s;
};
}
注意：这种方式每次调用工厂都会新建 ThreadLocal，适用于短期、单次使用的场景（如单元测试）；生产环境高频复用建议用 static 持有。
