静态内部类更适合作为状态管理器单例基底，因其利用JVM类加载机制实现天然线程安全的延迟初始化，避免DCL中volatile缺失或指令重排导致的未完全构造实例被读取的风险，且无锁性能更优。
为什么静态内部类比双重检查锁更适合作为状态管理器的单例基底
因为状态管理器通常需要延迟初始化（比如依赖 UI 上下文或配置加载完成），但又不能牺牲线程安全。静态内部类利用 JVM 类加载的天然同步机制，在 getInstance() 第一次被调用时才触发内部类初始化，此时 INSTANCE 字段的赋值是原子且不可重排序的，无需 synchronized 或 volatile 修饰——既避免 DCL 中因指令重排导致未完全构造实例就被其他线程读取的风险，也绕开了懒汉式加锁带来的性能抖动。
常见错误现象：NullPointerException 出现在首次调用 getState() 时，本质是 DCL 中漏写了 volatile，或构造函数里提前暴露了 this（如注册监听器）。
- Android 中若在
Application.onCreate()之前就调用StateManager.getInstance()，静态内部类仍安全；而懒汉式可能因类尚未加载而返回 null - Web 端若在
DOMContentLoaded前初始化，静态内部类不会触发构造，但需确保后续首次调用时上下文已就绪 - 该方式无法解决“有状态”问题本身——它只保证单例唯一，不自动隔离多线程对共享字段的修改
私有字段如何设计才能兼顾可变性与线程安全
状态管理器的私有字段不是简单声明 private String token; 就完事。一旦字段可变，就必须明确其访问契约：是只读缓存？还是允许跨线程更新？若允许更新，就得选对同步原语。
典型场景：用户登录态变更需通知多个观察者，同时要防止并发修改导致状态错乱。
- 用
AtomicReference<UserState>替代普通对象引用，compareAndSet()保证状态跃迁原子性 - 基础类型优先用
AtomicInteger、AtomicBoolean，避免无谓锁竞争 - 若状态结构复杂（如嵌套 Map），不要直接暴露可变容器，改用
CopyOnWriteArrayList或不可变包装（如ImmutableMap） - 禁止在 getter 中返回私有可变集合的原始引用，否则外部修改会绕过所有同步逻辑
为什么 ThreadLocal 不适合做全局状态管理器的主干
ThreadLocal 确实能隔离线程间状态，但它和“全局唯一单例”的目标冲突：每个线程拿到的是独立副本，StateManager.getInstance().setToken("abc") 在主线程生效，子线程里读不到。
真实使用中容易踩的坑：
- 误把
ThreadLocal<StateManager>当成单例，结果每个线程都 new 一个新实例，失去状态共享意义 - 在异步回调（如 OkHttp Callback、RxJava Scheduler）中忘记手动传递或继承
ThreadLocal值，导致状态丢失 - Web 容器线程池复用时，未清理
ThreadLocal导致脏数据残留（如上个请求的 userId 泄露到下一个） - 真正适合
ThreadLocal的是上下文快照（如当前请求 traceId），而非需要跨线程协同的状态
销毁与重置逻辑必须显式提供，不能依赖 GC
状态管理器常驻内存，但它的私有字段可能持有 Activity、Context、Callback 等强引用。若不主动清理，Android 上会引发内存泄漏；Web 端则可能持续监听已卸载组件的事件。
关键点：
- 提供
clear()方法清空所有私有字段（包括AtomicReference设为null，CopyOnWriteArrayList调用clear()） - Android 中监听
Activity.onDestroy()或使用WeakReference持有 UI 相关对象 - Web 端在
beforeunload或模块卸载时调用重置，避免跨 Tab 数据污染 - 不要假设单例会被 JVM 自动回收——只要类加载器存活，静态字段就一直存在
最易被忽略的一点：状态管理器的“线程安全”只覆盖实例获取和字段读写，不覆盖业务逻辑层的竞态。比如两个线程同时调用 incrementCounter()，即使 counter 是 AtomicInteger，其后续的“判断是否超限→发通知”这一整段仍是非原子的，必须用额外同步或状态机控制。
