1700474753
1700474754
public class Client{
1700474755
1700474756
public static void main（String[]args）{
1700474757
1700474758
//初始化对象池
1700474759
1700474760
for（int i=0；i＜4；i++）{
1700474761
1700474762
String subject=“科目”+i；
1700474763
1700474764
//初始化地址
1700474765
1700474766
for（int j=0；j＜30；j++）{
1700474767
1700474768
String key=subject+“考试地点”+j；
1700474769
1700474770
SignInfoFactory.getSignInfo（key）；
1700474771
1700474772
}
1700474773
1700474774
}
1700474775
1700474776
SignInfo signInfo=SignInfoFactory.getSignInfo（“科目1考试地点1”）；
1700474777
1700474778
}
1700474779
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
[
上一页 ]
[ :1.700474753e+09 ]
[
下一页 ]