1700457078
1700457079
代码清单7-6 臣子参拜皇帝的过程
1700457080
1700457081
public class Minister{
1700457082
1700457083
public static void main（String[]args）{
1700457084
1700457085
//定义5个大臣
1700457086
1700457087
int ministerNum=5；
1700457088
1700457089
for（int i=0；i＜ministerNum；i++）{
1700457090
1700457091
Emperor emperor=Emperor.getInstance（）；
1700457092
1700457093
System.out.print（“第”+（i+1）+“个大臣参拜的是：”）；
1700457094
1700457095
emperor.say（）；
1700457096
1700457097
}
1700457098
1700457099
}
1700457100
1700457101
}
1700457102
1700457103
大臣参拜皇帝的结果如下所示。
1700457104
1700457105
第1个大臣参拜的是：皇1帝
1700457106
1700457107
第2个大臣参拜的是：皇2帝
1700457108
1700457109
第3个大臣参拜的是：皇1帝
1700457110
1700457111
第4个大臣参拜的是：皇1帝
1700457112
1700457113
第5个大臣参拜的是：皇2帝
1700457114
1700457115
看，果然每个大臣参拜的皇帝都可能不一样，大臣们就开始糊涂了，A大臣给皇1帝汇报了一件事情，皇2帝不知道，然后就开始怀疑大臣A是皇1帝的亲信，然后就想办法开始整……
1700457116
1700457117
这种需要产生固定数量对象的模式就叫做有上限的多例模式，它是单例模式的一种扩展，采用有上限的多例模式，我们可以在设计时决定在内存中有多少个实例，方便系统进行扩展，修正单例可能存在的性能问题，提供系统的响应速度。例如读取文件，我们可以在系统启动时完成初始化工作，在内存中启动固定数量的reader实例，然后在需要读取文件时就可以快速响应。
1700457118
1700457119
1700457120
1700457121
1700457123
设计模式之禅 7.5 最佳实践
1700457124
1700457125
单例模式是23个模式中比较简单的模式，应用也非常广泛，如在Spring中，每个Bean默认就是单例的，这样做的优点是Spring容器可以管理这些Bean的生命期，决定什么时候创建出来，什么时候销毁，销毁的时候要如何处理，等等。如果采用非单例模式（Prototype类型），则Bean初始化后的管理交由J2EE容器，Spring容器不再跟踪管理Bean的生命周期。
1700457126
1700457127
使用单例模式需要注意的一点就是JVM的垃圾回收机制，如果我们的一个单例对象在内存中长久不使用，JVM就认为这个对象是一个垃圾，在CPU资源空闲的情况下该对象会被清理掉，下次再调用时就需要重新产生一个对象。如果我们在应用中使用单例类作为有状态值（如计数器）的管理，则会出现恢复原状的情况，应用就会出现故障。如果确实需要采用单例模式来记录有状态的值，有两种办法可以解决该问题：
[
上一页 ]
[ :1.700457078e+09 ]
[
下一页 ]