2、状态访问模式概述：它到底是什么？
好，我们正式开始聊状态访问模式。在讲这个之前，我想先问你一个问题：你写代码的时候，有没有遇到过那种「一个对象的行为，完全取决于它内部某个状态」的情况？
比如一个订单，它可以是「待支付」、「已支付」、「已发货」、「已完成」。每个状态下，用户能做的操作完全不一样。待支付可以取消，已支付就不能取消了。
大部分人第一反应是：用 if-else 或者 switch-case 呗。没错，我以前也是这么干的。直到有一次我维护一个老项目，一个订单类里塞了十几个状态判断，每个方法开头都是一堆 if (state == XXX) ... 那代码，说实话，我自己写的，三个月后自己都看不懂了。
这时候，状态模式就登场了。但今天我们要聊的，是它的一个变种——状态访问模式。这俩名字很像，但解决的问题完全不同。
2.1 状态模式 vs 状态访问模式：别搞混了
我见过不少开发者，一听到「状态访问模式」就以为是状态模式。其实它们俩，一个管「行为怎么变」，一个管「状态怎么读」。说白了，关注点不一样。
| 对比维度 | 状态模式 | 状态访问模式 |
|---|---|---|
| 核心关注点 | 对象行为随状态改变 | 外部如何安全、高效地读取内部状态 |
| 典型场景 | 工作流、订单状态机 | 监控系统、性能分析器、调试器 |
| 访问方式 | 状态对象封装行为，外部调用统一接口 | 提供快照、查询接口，外部按需拉取 |
| 性能敏感点 | 状态切换开销、多态调用 | 读取频率、数据一致性、锁竞争 |
| 我个人的经验 | 适合业务逻辑复杂的场景 | 适合高频读取、低延迟要求的场景 |
你看，状态模式是「行为多态」，状态访问模式是「数据访问」。一个偏行为，一个偏数据。我在项目中遇到过最典型的混淆案例：有人用状态模式去实现一个监控系统的状态读取，结果每个状态类里都塞满了 getter 方法，状态切换时还要重建对象，性能直接崩了。
2.2 状态访问模式的核心思想
好，那状态访问模式到底想干什么？我总结了一句话：让外部代码在不破坏封装的前提下，高效、安全地获取对象的内部状态快照。
你想想看，一个运行中的系统，它的内部状态是不断变化的。比如一个线程池，有多少活跃线程、队列里排了多少任务、当前是运行还是暂停。外部监控模块需要定期读取这些信息。
如果直接暴露内部字段，封装就破了。如果每个字段都加个 getter，调用方得一个个调，而且每次调用都可能涉及锁，性能堪忧。
状态访问模式的做法是：提供一个统一的访问入口，返回一个状态快照对象。这个快照是不可变的，外部拿到后随便读，不会影响内部状态。
核心三要素：
- 状态源：持有真实状态的对象（比如线程池）
- 快照：不可变的状态副本，一次性打包返回
- 访问接口：统一的查询方法，内部决定如何收集状态
说白了，就是「你要看我的状态？好，我给你拍张照，你拿去看，别打扰我干活。」
2.3 它解决了什么问题？
我归纳了一下，状态访问模式主要解决三个痛点：
- 高频读取下的性能问题：如果外部每秒钟轮询 1000 次状态，每次都要加锁读多个字段，锁竞争会非常严重。状态访问模式通过一次快照，把多次读取合并成一次，大大降低锁粒度。
- 数据一致性问题：外部读取多个相关字段时，可能读到「半新半旧」的状态。比如线程数读到新值，队列长度还是旧值。快照保证了原子性——要么全读到新状态，要么全读到旧状态。
- 接口膨胀问题：如果每个内部字段都暴露一个 getter，接口会变得臃肿。而且每增加一个状态字段，就要加一个方法。状态访问模式用一个 getSnapshot() 就搞定了。
💡 一个小技巧： 我习惯在快照对象里只放「外部真正需要」的字段。别一股脑把所有内部变量都塞进去。有一次我看到有人把临时缓存变量也放进快照里，结果外部依赖了这个临时值，缓存一清，监控就报警了。嗯，这种坑，踩过一次就记住了。
2.4 一张图看懂状态访问模式
下面这张图，是我自己画的结构图。它展示了状态访问模式的核心流程：外部调用方通过统一接口获取快照，状态源内部收集数据，返回不可变快照。
你看，整个流程很清晰。外部调用方不直接碰内部字段，而是通过接口拿快照。状态源内部怎么收集、要不要加锁、要不要做缓存，都是它自己的事。外部只管读快照。
2.5 什么时候该用它？
我个人的判断标准很简单：
- 外部读取频率远高于内部状态变化频率——比如监控系统每 100ms 轮询一次，但状态可能几秒才变一次。这时候快照缓存能省大量开销。
- 需要读取一组关联状态——比如同时读「当前连接数」和「最大连接数」，这两个值必须在同一个时间点采样。
- 状态源内部有复杂的并发控制——比如用了读写锁、CAS、或者无锁数据结构。外部直接读容易破坏内部的一致性。