在GoF设计模式书中，当涉及Observer模式的实现部分时，说明如下：
将主题映射给其观察者主题跟踪观察者应遵循的最简单方法 notify是在主题中显式存储对它们的引用。但是，这样的存储可能太昂贵了 当主题多而观察者少时。一种解决方案是使用 关联查找（例如哈希表）以维护主题到观察者的映射。因此，一个没有 观察者不会产生存储开销。另一方面，这种方法增加了访问成本 观察者。
我看不到使用哈希表如何提高存储容量。在Java中，对于每个主题，我们可以有一个观察者列表List<Observer>。如果没有与该主题相关的观察者，则列表引用为null。如果我们使用哈希表Map<Subject, List<Observer>，我们仍然有列表，但是我们也有对主题的引用，因此这种方式会占用更多内存
效率低下。我不知道它是否相关，但是Gof书中用于实现的语言是Smalltalk和C ++。
答案 0 :(得分：3)
报价的要点似乎是，如果主体负责存储自己的观察者，那么在大多数主体在给定时间未被观测的情况下，每个主体都要承担存储空白列表的费用（想象数百万个主体）。
另一方面，如果将主体到观察者的映射集中到单个Map中，则只有（很少）观察到的主体具有任何内存占用。正确地指出，由于需要存储对主题的引用，因此使用集中化映射时，每个观察到的主题的内存成本会更高，这就是为什么“当主题很多且观察者较少时”这样的设计才有意义的原因
请注意一个更现代的示例，该示例优化代码以避免空集合：Why overload the varargs method of() in Java Stream interface?