本文详细介绍了单例模式的概念、特点及其实现方式，包括饿汉式、懒汉式及利用内部类实现的延迟加载单例等。此外还探讨了单例模式的优点、缺点及其适用场景。
1 定义：
单例模式
Ensure a class has only one instance, and provide a global point of access to it.(确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。)
1.1通用类图：
图1 单例模式通用类图
Singleton： 负责创建Singleton类自己的唯一实例，并提供一个getInstance的方法，让外部来访问这个类的唯一实例。
单例模式应该是23种设计模式中最简单的一种模式了。
它有以下几个要素：
1.私有的构造方法
2.私有静态的类自身实例引用
3. 以自己实例为返回值的静态的公有的方法
1.2通用代码：
饿汉式单例
- public class Singleton {
- private static final Singleton singleton = new Singleton();
- //限制产生多个对象
- private Singleton(){
- }
- //通过该方法获得实例对象
- public static Singleton getSingleton(){
- return singleton;
- }
- //类中其他方法，尽量是static
- public static void doSomething(){
- }
- }
懒汉式单例
一般的线程安全懒汉式单例
- public class Singleton {
- private static Singleton singleton;
- private Singleton(){}
- public static synchronized Singleton getInstance(){
- if(singleton==null){
- singleton = new Singleton();
- }
- return singleton;
- }
- }
此处用了synchronized 关键字，说明是在多线程情况下是安全的。但每次都要判断，会降低整个访问速度！
但在利用具体的synchronized时，有多种写法，比如,synchronized方法、synchronized对象、synchronized类等。
双重检查锁懒汉式单例
可以使用双重检查加锁 的方式来实现，就可以 既实现线程安全 ， 又能够使线程不受到很大的影响 。所谓双重检查加锁机制，指的是：并不是每次进入getInstance方法都需要同步，而是先不同步，进入方法过后，先检查实例是否存在，如果不存在才进入下面的同步块，这是第一重检查。进入同步块过后，再次检查实例是否存在，如果不存在，就在同步的情况下创建一个实例，这是第二重检查。这样一来，就只需要同步一次了，从而减少了多次在同步情况下进行判断所浪费的时间。
双重检查加锁机制的实现会使用一个关键字volatile，它的意思是：被volatile修饰的变量的值，将不会被本地线程缓存，所有对该变量的读写都是直接操作共享内存，从而确保多个线程能正确的处理该变量。
示例代码如下：
- package com.example.test;
- /**
- * 双重检查 单例实现的示例
- */
- public class Singleton {
- /**
- * 定义一个变量来存储创建好的类实例
- */
- private volatile static Singleton instance = null;
- /**
- * 私有化构造方法，可以在内部控制创建实例的数目
- */
- private Singleton(){
- }
- /**
- * 定义一个方法来为客户端提供类实例
- * @return
- */
- public static Singleton getInstance(){
- //先检查实例是否存在，如果不存在才进入下面的同步块
- if(instance==null){
- synchronized (Singleton.class) {
- //同步块，线程安全地创建实例
- if(instance==null){
- //再次检查实例是否存在，如果不存在才真正地创建实例
- instance = new Singleton();
- }
- }
- }
- return instance;
- }
- /**
- * 示意方法，单例可以有自己的操作
- */
- public void operation(){
- //功能处理
- }
- }
利用内部类实现的延迟加载的单例
常见的两种单例实现方式都存在小小的缺陷，那么有没有一种方案，既能够实现延迟加载，又能够实现线程安全呢？要想简单的实现线程安全，可以采用静态初始化器的方式，它可以由JVM来保证线程的安全性。比如前面的饿汉式实现方式。但是这样一来，不是会浪费一定的空间吗？因为这种实现方式，会在类装载的时候就初始化对象，不过你需不需要。
如果现在有一种方法能够让类装载的时候不去初始化对象，那不就解决问题了？一种可行的方式就是采用类级内部类，在这个类级内部类里面去创建对象实例。这样一来，只要不使用到这个类级内部类，那就不好创建对象实例，从而同时实现延迟加载和线程安全。
这个解决方案被称为Lazy Initialization holder class模式，这个模式综合使用了Java类级内部类和多线程缺省同步锁的知识，很巧妙地同时实现了延迟加载和线程安全。
示例代码如下：
- package com.example.test;
- /**
- * Lazy Initialization holder class模式 示例
- */
- public class Singleton {
- /**
- * 类级内部类，也就是静态的成员式内部类，该内部类的实例与外部类的实例没有绑定关系，
- * 而且只有被调用时才会装载，从而实现了延迟加载
- */
- private static class SingletonHolder{
- /**
- * 静态初始化器，由JVM来保证线程安全
- */
- private static Singleton instance = new Singleton();
- }
- /**
- * 私有化构造方法，可以在内部控制创建实例的数目
- */
- private Singleton(){
- }
- /**
- * 定义一个方法来为客户端提供类实例
- * @return
- */
- public static Singleton getInstance(){
- return SingletonHolder.instance;
- }
- }
2优点：
- 内存仅有一个实例，减少内存开支；特别是一个对象需要频繁地创建、销毁时，而且创建或销毁时性能又无法优化，单例模式的优势就非常明显。
- 当一个对象的产生需要比较多的资源时，如读取配置、产生其他依赖对象时，则可以通过在应用启动时直接产生一个单例对象，然后用永驻留内存的方式来解决（在Java EE中注意JVM垃圾回收机制）。
- 单例模式可以在系统设置全局的访问点，优化和共享资源访问，例如可以设计一个单例类，负责所有数据表的映射处理。
3缺点：
3.1 单例模式一般没有接口，扩展很困难，若要扩展，除了修改代码基本上没有别的途径。单例模式为什么不能增加接口呢？因为接口对单例模式是没有任何意义的，它要求“自行实例化”，并且提供单一实例。接口、抽象类是不可能被实例化的。当然特殊情况下，单例模式可以实现接口、被继承等，需要在系统开中根据环境判断。
3.2单例模式对测试不利。在并行开发环境中，如果单例没有完成，是不能进行测试的。
3.3 单例模式与单一职责原则有冲突。一个类应该只实现一个逻辑，而不关心它是否是单例的，是不是要取决于环境，单例模式把“要单例”和业务逻辑融合在一个类中。
4使用场景：
在一个系统中，要求一个类有且仅有一个对象，如果出现多个对象就会出现“不良反应”，可以采用单例模式，具体场景如下：
- 要求生成唯一序列号的环境；
- 在整个项目中需要一个共享访问点或共享数据，如计数器；
- 创建一个对象需要消耗资源过多，如要访问IO和数据库等资源；
- 需要定义大量的静态常量和静态方法（如工具类）的环境，可以采用单例模式。
5注意事项：
5.1 高并发时注意单例模式的线程同步问题。
在单例的实例化时，有“饿汉式”如1.3中实例化方法；也有使用同步方法，仅在需要时创建的方式，这种方式称为“懒汉式”单例；后者不是优秀的方式，前者为推荐方式。
若后者未添加同步关键字，则可能导致“创建 赋值”过程中，被另一调用再次创建。
5.2 不要做断开单例类对象与类中静态引用的危险操作。
5.3 只能使用单例类提供的方法得到单例对象。
在同一个jvm中非正常情况生成多个单例对象的情况：
1.复制生成多单例。
在Java中，对象默认是不可以被复制的，若实现了Cloneable接口，并实现了clone方法，则可以直接通过对象复制方式创建一个新对象，对象复制不调用类的构造函数，因此即使是私有的构造函数，对象仍然可以被复制。即，单例类不要实现Cloneable接口。
2.反射生成多单例
不要使用反射，否则将会实例化一个新对象
在多个JVM中则可以生成多个不同的单例对象,比如：分布式系统、多个类加载器、以及序列化的的情况下，都可以产生多个单例。
6扩展：
如果一个类只要一个对象，使用单例模式即可；如果一个类可以只要两个、三个对象呢？亦可参照单例模式，静态初始若干实例，然后使用时或随机或按某种规则取出即可。
单例模式只有饿汉式和懒汉式两种吗
饿汉式单例和懒汉式单例只是两种比较主流和常用的单例模式方法，从理论上讲，任何可以实现一个类只有一个实例的设计模式，都可以称为单例模式。
单例类可以被继承吗
饿汉式单例和懒汉式单例由于构造方法是private的，所以他们都是不可继承的，但是其他很多单例模式是可以继承的，例如登记式单例。
7范例：
单例用法（计数器类，部分工具类）
- package _01_Singleton;
- public class Counter {
- private static final Counter counter = new Counter();//创建实例
- private static int total = 0;
- private Counter(){}
- public static Counter getInstance(){//获取实例
- return counter;
- }
- //做点事。
- public synchronized void Increase(){
- total++;
- }
- //做点事。
- public synchronized int getTotal(){
- return total;
- }
- //工具类可参考
- public static void whatAmI(){
- System.out.println("我是计数器工具方法");
- }
- }
- package _01_Singleton;
- public class TestCounter {
- public static void main(String[] args) {
- Counter.whatAmI();
- Counter c = Counter.getInstance();
- for(int i=0; i<10; i++){
- c.Increase();
- System.out.println("The current total is : " + c.getTotal());
- }
- }
- }
我是计数器工具方法
The current total is : 1
The current total is : 2
The current total is : 3
The current total is : 4
The current total is : 5
The current total is : 6
The current total is : 7
The current total is : 8
The current total is : 9
The current total is : 10
单例模式的对象长时间不用会被jvm垃圾收集器收集吗
看到不少资料中说：如果一个单例对象在内存中长久不用，会被jvm认为是一个垃圾，在执行垃圾收集的时候会被清理掉。对此这个说法，笔者持怀疑态度，笔者本人的观点是：在hotspot虚拟机1.6版本中，除非人为地断开单例中静态引用到单例对象的联接，否则jvm垃圾收集器是不会回收单例对象的。在1.7中也有人测试过不会被清理。
文章单例模式讨论篇：单例模式与垃圾收集有做单独讨论。
“Jvm的垃圾回收机制会回收掉长时间不用的对象”。这里的“不用的对象”，应该指的是“没有任何引用存在的对象”，英文大概是“object with no reference”的意思，而不是“object is useless”。 a = new Instance()；此时a持有实例的引用，换句话说实例被变量a引用。 a = null；此时变量a与实例的引用断开，那么实例就成为无引用的垃圾，可以被回收掉。
扫一扫
2180
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
