直接继承InheritableThreadLocal无法实现写时复制，因其childValue()仅在子线程创建时调用一次且不拦截set()；需用InheritableThreadLocal透传父线程快照、ThreadLocal管理本地值，并在set()首次调用时深拷贝快照完成按需复制。
为什么直接继承 InheritableThreadLocal 无法实现写时复制
因为 InheritableThreadLocal 的 childValue 方法只在子线程创建时调用一次，传入的是父线程当时的 get() 返回值——它不拦截后续的 set()，也不感知“写”动作。所谓“写时复制”，本质是：子线程首次 set() 时，才把父线程当前值深拷贝一份作为初始值；之后所有操作都只影响本地副本。这必须拦截 set()，而原生类没提供钩子。
如何用自定义子类 + ThreadLocal 委托实现写时复制语义
核心思路是：不直接继承 InheritableThreadLocal，而是用一个普通 ThreadLocal 存储实际值，并在 set() 时检查是否为首次写入（即当前线程未初始化且存在父线程副本）。此时才触发“按需复制”。需要额外维护一个 ThreadLocal<boolean></boolean> 标记是否已初始化，或更稳妥地用 ThreadLocal<atomicboolean></atomicboolean> 避免 null 问题。
-
get()：若当前线程未设置过值，且父线程有值（通过InheritableThreadLocal透传一个快照引用），则触发一次懒复制并缓存 -
set()：先判断是否首次写入；若是，从父线程快照深拷贝；否则直接写入本地ThreadLocal - 父线程值快照不能直接存对象引用，必须在子线程创建时就做一次浅/深拷贝（取决于上下文对象是否可变），否则仍会共享引用
- 推荐用
InheritableThreadLocal<object></object>仅透传序列化后的字节数组或不可变快照（如Map.copyOf()、ImmutableList.of()），避免透传可变容器
关键陷阱：父子线程值不是实时同步的，且“写时”时机容易误判
所谓“写时”，是指子线程第一次调用 set() 的时刻，不是第一次 get()。如果子线程只读不写，它始终看到的是父线程创建它那一刻的快照，哪怕父线程后来改了值——这是设计使然，不是 bug。但很多人误以为子线程能“自动感知”父线程后续变更。
- 若依赖实时性，应改用消息/事件机制，而非 ThreadLocal 类方案
-
childValue()中返回的快照必须是防御性拷贝，例如：return new HashMap(parentMap)，而非return parentMap - 注意线程池场景：线程复用会导致“父线程快照”残留，应在任务执行前显式清理或重置该快照
InheritableThreadLocal - GC 友好性：快照对象若较大，应考虑弱引用或软引用缓存策略，避免长期持有无用上下文
一个最小可行示例（Java）
public class CopyOnWriteContext<T extends Cloneable> {
private final InheritableThreadLocal<T> snapshotHolder = new InheritableThreadLocal<>() {
@Override
protected T childValue(T parentValue) {
if (parentValue == null) return null;
try {
return (T) parentValue.getClass().getMethod("clone").invoke(parentValue);
} catch (Exception e) {
throw new IllegalStateException("Failed to clone parent context", e);
}
}
};
private final ThreadLocal<T> localValue = ThreadLocal.withInitial(() -> null);
<pre class='brush:java;toolbar:false;'>public T get() {
T val = localValue.get();
if (val == null) {
T snapshot = snapshotHolder.get();
if (snapshot != null) {
localValue.set(snapshot); // 首次 get 也触发复制（等价于 lazy set）
return snapshot;
}
}
return val;
}
public void set(T value) {
// 真正的写时复制：仅当之前未 set 过，才用快照覆盖
if (localValue.get() == null) {
T snapshot = snapshotHolder.get();
localValue.set(snapshot != null ? deepCopy(snapshot) : value);
} else {
localValue.set(value);
}
}
private T deepCopy(T src) { /* 实际项目中替换为 JSON 序列化或手动 copy */ }}
这个模式绕过了 InheritableThreadLocal 的固有限制，把“继承”和“复制”解耦：前者只负责传递快照，后者由业务逻辑控制何时真正落地。真正的难点不在代码，而在厘清“谁在什么时候拥有哪份副本”的生命周期边界——尤其在线程池+异步链路中，稍不注意就会复用旧快照或漏清理。
