状态封闭本质是通过单一可变owner线程消除并发访问，而非加锁；它要求所有读写均经该线程上下文，禁止引用逃逸，典型如GUI事件循环、Actor模型、Go的goroutine+channel。
为什么 状态封闭 不是加锁，而是换线程模型
它本质是把“谁来管状态”这个问题，从“多线程抢着管”变成“只让一个线程管”。不是靠同步机制约束并发，而是直接消灭并发访问的可能路径。
- 典型场景：GUI 事件循环（如 Electron 主进程、JavaFX Application Thread）、Actor 模型（Akka、Erlang 进程）、Go 的 goroutine + channel 配合单一 owner
- 关键不在“封闭”二字，而在“单一可变 owner”——所有读写都必须经由该线程的执行上下文，不能有裸指针/引用逃逸到其他线程
- 常见错误：以为把对象
new在主线程就安全了，结果把它的引用传给了子线程并直接调用setState()或修改字段，这已经破环封闭性 - 性能影响：避免了锁竞争和内存屏障开销，但要求状态操作不能阻塞（否则整个封闭线程卡死），所以 IO 或计算密集任务得异步剥离出去
ThreadLocal 是状态封闭吗？不是，它是伪封闭
ThreadLocal 让每个线程有自己副本，看起来“隔离”，但它不满足“单一可变 owner”原则——多个线程各自持有可变状态，彼此独立修改，根本没共享，也谈不上“管理同一份状态”。它解决的是线程间数据隔离，不是状态一致性。
- 误用案例：用
ThreadLocal<map></map>缓存全局配置，却在多个线程里反复put()同一个 key，期望某处能“看到更新”——不可能，各线程副本完全无关 - 真封闭场景下，你不会需要
ThreadLocal；需要它，往往说明你还没把状态归属理清楚 - 兼容性注意：Android 上
ThreadLocal在低版本有内存泄漏风险（未手动remove()导致 Activity 持有）
如何验证一个对象是否真正实现了状态封闭
不能只看创建位置，得追踪所有对它的引用和方法调用路径。核心检查点只有两个：有没有非封闭线程拿到它的引用，有没有非封闭线程调用它的可变方法。
- 静态检查：搜所有
.getXXX()、.setXXX()、字段赋值，确认调用方是否始终在目标线程（比如通过SwingUtilities.invokeLater()包裹） - 动态检查：在关键 setter 加断点，运行时看调用栈是否只来自预期线程（IDE 调试器线程名栏一目了然）
- 容易踩的坑：Lambda 表达式或匿名内部类隐式捕获了封闭对象，又在回调中被其他线程触发（如
CompletableFuture.supplyAsync().thenAccept()里的accept默认走 ForkJoinPool，不是原封闭线程） - 参数差异：
ExecutorService.submit(Runnable)和SwingWorker行为完全不同——前者明确交出控制权，后者仍承诺在 EDT 执行done()
Go 的 channel + 单 goroutine 是最干净的状态封闭实践
它把“状态操作”显式转成“消息投递”，天然强制所有变更经过一个入口点，没有裸共享、没有竞态可能，连 mutex 都省了。
- 示例：一个计数器封装成结构体，只暴露
inc()、get()方法，内部用chan int接收指令，单个 goroutine 循环select处理 - 为什么比 Java 的
synchronized更可靠？因为编译器和 runtime 能静态检查消息流向，而锁依赖程序员手写正确配对，漏掉一处就全盘失效 - 性能提示：channel 有固定内存开销，高吞吐场景下若指令极简单（如纯计数），用
atomic可能更轻量——但这就已不属于状态封闭模式了
