为什么不建议一个对象在多处存储引用？ 第1页

这个问题简单多了。

不论是Area里面有一个保存Item容器，还是Item上面有一个Area引用，都已经有足够的信息。所以现在的问题是在于，当Item上已经有Area的引用的时候，那么Area是否还有必要保留对Item的引用。

这是个典型的关于冗余的问题。

冗余会带来什么问题？

首先是占用更多的存储空间，但这通常不成为一个问题，尤其是只存储一个引用的时候。

那么另外一个问题就是数据一致性的问题，当冗余数据出现，就可能存在数据的不一致。在这个例子里面，譬如说a : Area保存了b : Item的引用，但是b的Area属性不是a。

这就是数据不一致，这时候我们不知道b到底是属于a还是不属于。或者说通过不同的方式处理数据的时候，例如我们遍历a的时候能找到b，但是找b的容器的时候又找不到a。

为了避免出现一致性的问题，我们通常需要做原子性操作，原子性就是说多个操作要么都成功，要么都失败。例如我们让a添加子元素b和设置b的Area属性为a这两个操作是原子性的，要么都成功要么都失败，就可以避免产生数据不一致的问题。

但遗憾的是，原子性是非常难做到的一件事情，很多时候代价非常大。因为我们要处理非常多的异常情况，例如操作被中断，数据写入时出现故障，并发冲突等等。

当然，大多数时候我们只要把两个操作写在一个方法里面或者其他强约束就足够满足了。更长的生命周期，更重要的数据会有更加严苛的要求。

但是即便做不到绝对的原子性，我们也不一定就会出现数据不一致的情况。而即便出现了数据不一致的情况，也不一定就无法进行修复和补救，例如我们可以强行认定Area属性是正确的数据，据此来修复所有的不一致情况。

所以，这只是一个需要权衡的问题。冗余会带来更好的性能，但是也会带来数据不一致的风险。