1700474780
}
1700474781
1700474782
运行结果如下所示：
1700474783
1700474784
科目3考试地点25–-建立对象，并放置到池中
1700474785
1700474786
科目3考试地点26–-建立对象，并放置到池中
1700474787
1700474788
科目3考试地点27–-建立对象，并放置到池中
1700474789
1700474790
科目3考试地点28–-建立对象，并放置到池中
1700474791
1700474792
科目3考试地点29–-建立对象，并放置到池中
1700474793
1700474794
科目1考试地点1–直接从池中取得
1700474795
1700474796
前面还有很多的对象创建提示语句，不再复制。通过这样的改造后，我们想想内存中有多少个SignInfo对象？是的，最多120个对象，相比之前几万个SignInfo对象优化了非常多。细心的读者可能注意到了SignInfo4Pool类基本上没有跑出我们的视线范围，仅仅在工厂方法中使用到了，尽量缩小变更引起的风险，想想看我们的改动是不是很小，只要在展示层中拼一个字符串，然后传递到工厂方法中就可以了。
1700474797
1700474798
通过这样的改造后，第三天系统运行得非常稳定，CPU占用率也下降了，而且以后再也没有出现类似问题，这就是享元模式的功劳。
1700474799
1700474800
1700474801
1700474802
1700474803
设计模式之禅 [:1700454054]
1700474804
设计模式之禅 28.2 享元模式的定义
1700474805
1700474806
享元模式（Flyweight Pattern）是池技术的重要实现方式，其定义如下：Use sharing to support large numbers of fine-grained objects efficiently.（使用共享对象可有效地支持大量的细粒度的对象。）
1700474807
1700474808
享元模式的定义为我们提出了两个要求：细粒度的对象和共享对象。我们知道分配太多的对象到应用程序中将有损程序的性能，同时还容易造成内存溢出，那怎么避免呢？就是享元模式提到的共享技术。我们先来了解一下对象的内部状态和外部状态。
1700474809
1700474810
要求细粒度对象，那么不可避免地使得对象数量多且性质相近，那我们就将这些对象的信息分为两个部分：内部状态（intrinsic）与外部状态（extrinsic）。
1700474811
1700474812
❑内部状态
1700474813
1700474814
内部状态是对象可共享出来的信息，存储在享元对象内部并且不会随环境改变而改变，如我们例子中的id、postAddress等，它们可以作为一个对象的动态附加信息，不必直接储存在具体某个对象中，属于可以共享的部分。
1700474815
1700474816
❑外部状态
1700474817
1700474818
外部状态是对象得以依赖的一个标记，是随环境改变而改变的、不可以共享的状态，如我们例子中的考试科目+考试地点复合字符串，它是一批对象的统一标识，是唯一的一个索引值。
1700474819
1700474820
有了对象的两个状态，我们就可以来看享元模式的通用类图，如图28-3所示。
1700474821
1700474822
1700474823
1700474824
1700474825
图28-3 享元模式的通用类图
1700474826
1700474827
类图也很简单，我们先来看我们享元模式角色名称。
1700474828
1700474829
❑Flyweight——抽象享元角色