优化之道
道可道，非常道
概念
读
解析 %ca_xx% 变量或使用 handler.getRandom(xx, "xx") 等之类获取属性值的行为，统称为 读
写
为实体添加属性源或更新属性源等之类改变数据的行为，统称为 写
后台线程
了解
本插件实体属性管理系统采用 “单写者 + 多读者” 的并发模型，通过 后台专用线程串行处理写请求，规避多线程竞争；
所有状态变更以 不可变快照 形式进行，借助 CAS原子操作 安全替换全局引用，实现 无锁更新；
同时，将复杂的属性值计算结果 预缓存为可读视图，使高频读取操作（如战斗判定、UI 显示）达到 零同步开销、O(1) 响应。
核心特性
✅ 多线程安全：
读操作完全无锁，写操作由独立后台线程串行执行，天然避免并发冲突；
✅ 可读缓存加速：
属性值、基础值、百分比、战力等计算结果一次性缓存，读取性能极致优化；
✅ 原子化状态管理：
通过 AtomicReference + CAS 实现快照的原子切换，保证状态一致性与可见性；
✅ 异步任务队列：
支持防抖更新、延迟移除、事件回调，兼顾响应性与系统稳定性。
该设计在保证 强一致性 与 逻辑正确性 的前提下，实现了 高吞吐、低延迟、高可扩展 的属性计算能力。
缺点
这套设计在高并发读多写少的场景下表现卓越，但任何架构都有其适用边界和潜在代价。
- 写路径存在“全量重计算”开销（非增量更新）
每次属性源变更（哪怕只改一个），都会重新计算，重新遍历所有来源、重新累加所有属性、重新计算战力。
当属性源数量庞大（如玩家有几十，甚至上百个），单次更新可能耗时数毫秒； - 内存占用较高（空间换时间的代价）
对于海量在线实体（如 1w+ 实体），总内存占用可能显著增加 - 写操作被强制串行化，无法利用多核并行写
如果出现“单个玩家需极高频写入”的极端场景（如每秒数百次动态属性变更），该线程会成为吞吐瓶颈。 - 状态更新存在微小延迟（非实时可见）
异步写入意味着：调用addAttributeSourceAsync()后，属性值不会立即生效； - 不适合“写多读少”或“频繁瞬时查询”场景
如果某系统主要行为是频繁添加/移除临时属性，但几乎不读取，则预计算缓存完全浪费；
或如果属性只在极少数关键时刻读取一次，则缓存收益远低于其维护成本。