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资源空闲的情况下该对象会被清理掉，下次再调用时就需要重新产生一个对象。如果我们在应用中使用单例类作为有状态值（如计数器）的管理，则会出现恢复原状的情况，应用就会出现故障。如果确实需要采用单例模式来记录有状态的值，有两种办法可以解决该问题：
1700457128
1700457129
❑由容器管理单例的生命周期
1700457130
1700457131
Java EE容器或者框架级容器（如Spring）可以让对象长久驻留内存。当然，自行通过管理对象的生命期也是一个可行的办法，既然有那么多的工具提供给我们，为什么不用呢？
1700457132
1700457133
❑状态随时记录
1700457134
1700457135
可以使用异步记录的方式，或者使用观察者模式，记录状态的变化，写入文件或写入数据库中，确保即使单例对象重新初始化也可以从资源环境获得销毁前的数据，避免应用数据丢失。
1700457136
1700457137
1700457138
1700457139
[
上一页 ]
[ :1.70045709e+09 ]
[
下一页 ]