单例模式（Singleton Pattern）。-蒲公英云

定义：

确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。

通用代码：

恶汉式单例

public class Singleton{
private static final Singleton singleton = new Singleton();
// 限制产生多个对象
private SIngleton(){}
// 通过该方法获得实例对象
public static Singleton getSingleton() {
return singleton;
}
// 类中其他方法，尽量是static
public static void doSomething(){}
}

优点：

由于单例模式在内存中只有一个实例，减少了内存开支，特别是一个对象需要频繁地创建，销毁时，而且创建或销毁时性能又无法优化，单例模式的优势就非常明显。
由于单例模式只生成一个实例，所以减少了系统的性能开销，当一个对象的产生需要比较多的资源时，如读取配置、产生其他依赖对象时，则可以通过在应用启动时直接产生一个单例对象，然后用永久驻留内存的方式来解决（在JaveEE中采用单例模式时需要注意JVM垃圾回收机制）。
单例模式可以避免对资源的多重占用，例如一个写文件动作，由于只有一个实例存在内存中，避免对同一个资源文件的同时写操作。
单例模式可以再系统设置全局的访问点，优化和共享资源访问，例如可以设计一个单例类，负责所有数据表的映射处理。

缺点：

单例模式一般没有接口，扩展很苦难，若要扩展，除了修改代码基本上没有第二种途径可以实现。单例模式为什么不能增加接口呢？因为接口对单例模式是没有任何意义的，他要求“自行实例化”，并且提供单一实例、接口或抽象类是不能被实例化的。当然，在特殊情况下，单例模式可以实现接口、被继承灯，需要在系统开发中根据环境判断。
单例模式对测试是不利的。在并行开发环境中，如果单例模式没有完成，是不能进行测试的，没有接口也不能使用mock的方式虚拟一个对象。
单例模式与单一职责原则有冲突。一个类应该只实现一个逻辑，而不关心它是否是单例的，是不是要单例取决于环境，单例模式把“要单例”和业务逻辑融合在一个类中。

使用场景：

要求生成唯一序列号的环境；
在整个项目中需要一个共享访问点或共享数据，例如一个Web页面上的计数器，可以不用把每次刷新都记录到数据库中，使用单例模式保持计数器的值，并确保是线程安全的；
创建一个对象需要消耗的资源过多，如要访问IO和数据库灯资源；
需要定义大量的静态常量和静态方法（如工具类）的环境，可以采用单例模式（当然，也可以直接声明为static的方式）。

注意事项：

在高并发情况下，请注意单例模式的线程同步问题。解决线程不安全的方法有很多：可以再getSingleton方法前加synchronized关键字，也可以在getSingleton方法内增加synchronized来实现，但都不是最优秀的单例模式，建议读者使用恶汉式单例。

懒汉式单例：

public class Singleton {
private static Singleton singleton = null;
// 限制产生多个对象
private Singleton(){}
// 通过该方法获得实例对象
public static synchronized Singleton getSingleton() {
if(singleton == null) {
singleton = new Singleton();
}
return singleton;
}
}

需要考虑对象的复制情况。在Java中，对象默认是不可以被复制的，若实现Cloneable接口，并实现了clone方法，则可以直接通过对象复制方式创建一个新对象，对象复制是不用调用类的构造函数，因此即使是私有的构造函数，对象仍然可以被复制。在一般情况下，类复制的情况下不需要考虑，很少会出现一个单例类会主动要求被复制的情况，解决的最好方法就是单例类不要实现Cloneable接口。

单例模式的扩展（有上限的多例模式）

固定数量的黄帝类

public class Emperor {
// 定义最多能产生的实例数量
private static int maxNumOfEmperor = 2;
// 每个皇帝都有名字，使用一个ArrayList来容纳，每个对象的私有属性
private static ArrayList<String> nameList = new ArrayList<Stirng>();
// 定义一个列表，容纳所有的皇帝实例
private static ArrayList<Emperor> emperorList = new ArrayList<Emperor>();
// 当前皇帝序列号
private static int countNumOfEmperor = 0;
// 产生所有的对象
static{
for(int i = 0;i < maxNumOfEmperor ; i++) {
emperorList.add(new Emperor("皇帝" + (i + 1) + "帝"));
}
}
// 世俗和道德约束你，目的就是不产生第二个皇帝
private Emperor(){}
// 传入皇帝名称，建立一个皇帝对象
private Emperor(String name) {
nameList.add(name);
}
// 随机获得一个皇帝对象
public static Emperor getInstance() {
Random random = new Random();
// 随机拉出一个 皇帝，只要是个精神领袖就成
countNumOfEmperor = random.nextInt(maxNumOfEmperor );
return emperorList.get(countNumOfEmperor);
}
// 皇帝发话了
public static void say() {
System.out.println(nameList.get(countNumOfEmperor));
}
}

在Emperor中使用了两个ArrayList分别存储实例和实例变量。当然，如果考虑到线程安全问题可以使用Vector来代替。

臣子参拜皇帝的过程

public class Minister {
public static void main(String[] args) {
// 定义5个大臣
int ministerNum = 5;
for(int i = 0; i < ministerNum ; i ++) {
Emperor emperor = Emperor.getInstance();
System.out.print("第" + (i + 1) + "个大臣参拜的是：");
emperor.say();
}
}
}

注重需要产生固定数量的对象的模式就叫做有上限的多例模式，它是单例模式的一种扩展，采用有上限的多例模式，我们可以在设计时决定在内存中有多少个实例，方便系统进行扩展修正单例可能存在的性能问题，提供系统的响应速度。例如读取文件，我们可以在系统启动时完成初始化工作，在内存中启动固定数量的reader实例，然后在需要读取文件时就可以快速响应。

最佳实践：

单例模式时23个模式中比较简单的模式，应用也非常广泛，如在Spring中，每个Bean默认就是单例模式的，这样做的优点是Spring容器可以管理这些Bean的生命期，决定什么时候创建，什么时候销毁，销毁的时候如何处理，等等。如果采用非单例模式（Propertype类型），则Bean初始化后的管理交由J2EE容器，Spring容器不再跟踪管理Bean的生命周期。