ThreadLocal不直接存储数组副本，而是为每个线程独立new数组实现隔离；若共享同一数组引用则失去线程安全，正确做法是通过withInitial(() -> new int[1024])按需创建线程专属实例。
在 Java 中，ThreadLocal 本身不直接“存储数组副本”，而是为每个线程提供独立的变量实例。若想让每个线程持有自己私有的数组（如 int[]、byte[] 或自定义对象数组），关键在于：**在 ThreadLocal 的 initialValue() 或 Supplier 中按需创建新数组，而非共享或复用外部数组**。
为什么不能直接存“副本”？
ThreadLocal 存的是引用——如果你把同一个数组对象塞进去（比如 threadLocal.set(sharedArray)），所有线程仍操作同一块内存，完全起不到隔离作用。真正的“私有副本”必须是每个线程各自 new 出来的全新数组。
正确做法：延迟初始化 + 按需创建数组
推荐使用 ThreadLocal.withInitial() 配合 lambda 创建线程专属数组。例如：
// 每个线程独享一个长度为 1024 的 int 数组
立即学习“Java免费学习笔记（深入）”；
private static final ThreadLocal
// 使用时直接取，无需同步
int[] buf = INT_BUFFER.get();
buf[0] = 42;
// … 后续读写均在线程本地内存，无竞争
进阶技巧：复用数组避免频繁分配
频繁 new 数组会增加 GC 压力。可在 ThreadLocal 中缓存已分配的数组，配合重置逻辑复用：
- 在
get()后手动清空数组内容（如Arrays.fill(buf, 0)），适合固定大小、内容可覆盖的场景 - 或封装成工具类，提供
acquire()/release()接口，在线程退出前清理（需配合remove()防止内存泄漏） - 注意：不要在
ThreadLocal中存大数组且长期不remove()，尤其在线程池环境下易引发 OOM
典型适用场景
- JSON 解析/序列化中的临时字符缓冲区（如 Jackson 的
ThreadLocal<char></char>） - 加密算法中线程私有的工作数组（如 AES 的 S-box 临时存储）
- 高频数值计算中避免重复申请 double[]，如 FFT 中间结果暂存
- 日志格式化时的 StringBuilder 或 byte[] 缓冲（Log4j2 内部就大量使用）
不复杂但容易忽略：真正隔离靠的是“每线程一份 new”，不是“ThreadLocal 这个容器”。只要确保每次 get 到的数组是本线程专属新建的，就自然规避了锁和 CAS 开销。
