Java模式设计之单例模式（二）

Posted 2023-03-28

参考技术A

　　在什么情况下使用单例模式

　　使用单例模式的条件

　　使用单例模式有一个很重要的必要条件

　　在一个系统要求一个类只有一个实例时才应当使用单例模式 反过来说 如果一个类可以有几个实例共存 那么就没有必要使用单例类 但是有经验的读者可能会看到很多不当地使用单例模式的例子 可见做到上面这一点并不容易 下面就是一些这样的情况

　　例子一

　　问 我的一个系统需要一些 全程 变量 学习了单例模式后 我发现可以使用一个单例类盛放所有的 全程 变量 请问这样做对吗？

　　答 这样做是违背单例模式的用意的 单例模式只应当在有真正的 单一实例 的需求时才可使用

　　一个设计得当的系统不应当有所谓的 全程 变量 这些变量应当放到它们所描述的实体所对应的类中去 将这些变量从它们所描述的实体类中抽出来 放到一个不相干的单例类中去 会使得这些变量产生错误的依赖关系和耦合关系

　　例子二

　　问 我的一个系统需要管理与数据库的连接 学习了单例模式后 我发现可以使用一个单例类包装一个Connection 对象 并在finalize（）方法中关闭这个Connection 对象 这样的话 在这个单例类的实例没有被人引用时 这个finalize（） 对象就会被调用 因此 Connection 对象就会被释放 这多妙啊

　　答 这样做是不恰当的 除非有单一实例的需求 不然不要使用单例模式 在这里Connection 对象可以同时有几个实例共存 不需要是单一实例

　　单例模式有很多的错误使用案例都与此例子相似 它们都是试图使用单例模式管理共享资源的生命周期 这是不恰当的

　　单例类的状态

　　有状态的单例类

　　一个单例类可以是有状态的（stateful） 一个有状态的单例对象一般也是可变（mutable） 单例对象

　　有状态的可变的单例对象常常当做状态库（repositary）使用 比如一个单例对象可以持有一个int 类型的属性 用来给一个系统提供一个数值惟一的序列号码 作为某个贩卖系统的账单号码 当然 一个单例类可以持有一个聚集 从而允许存储多个状态

　　没有状态的单例类

　　另一方面 单例类也可以是没有状态的（stateless） 仅用做提供工具性函数的对象 既然是为了提供工具性函数 也就没有必要创建多个实例 因此使用单例模式很合适 一个没有状态的单例类也就是不变（Immutable） 单例类 关于不变模式 读者可以参见本书的 不变（Immutable ）模式 一章

　　多个JVM 系统的分散式系统

　　EJB 容器有能力将一个EJB 的实例跨过几个JVM 调用 由于单例对象不是EJB 因此 单例类局限于某一个JVM 中 换言之 如果EJB 在跨过JVM 后仍然需要引用同一个单例类的话 这个单例类就会在数个JVM 中被实例化 造成多个单例对象的实例出现 一个J EE应用系统可能分布在数个JVM 中 这时候不一定需要EJB 就能造成多个单例类的实例出现在不同JVM 中的情况

　　如果这个单例类是没有状态的 那么就没有问题 因为没有状态的对象是没有区别的 但是如果这个单例类是有状态的 那么问题就来了 举例来说 如果一个单例对象可以持有一个int 类型的属性 用来给一个系统提供一个数值惟一的序列号码 作为某个贩卖系统的账单号码的话 用户会看到同一个号码出现好几次

　　在任何使用了EJB RMI 和JINI 技术的分散式系统中 应当避免使用有状态的单例模式

　　多个类加载器

　　同一个JVM 中会有多个类加载器 当两个类加载器同时加载同一个类时 会出现两个实例 在很多J EE 服务器允许同一个服务器内有几个Servlet 引擎时 每一个引擎都有独立的类加载器 经有不同的类加载器加载的对象之间是绝缘的

lishixinzhi/Article/program/Java/gj/201311/27644

Java设计模式之单例

一、Java中的单例:

特点:

① 单例类只有一个实例

② 单例类必须自己创建自己唯一实例

③ 单例类必须给所有其他对象提供这一实例

二、两种模式:

①懒汉式单例<线程不安全>

在类加载时,不创建实例,运行调用时创建。类加载快，在运行时获取对象速度慢

示例：

//懒汉模式
public class Pet {
    
    private Pet(){
        
    }
    
    private static Pet pet=null;
    
    public static Pet getInfo(){
        if(pet==null){
            pet=new Pet();
        }
        return pet;
    }

}

②饿汉式单例<线程安全>

在类加载的时候，就完成初始化。所以类加载慢，但是在运行时获取对象快

示例：

//饿汉模式
public class Pet {
    
    private Pet(){
        
    }
    
    private static Pet pet=new Pet();
    
    public static Pet getInfo(){
        return pet;
    }

}

饿汉模式线程安全，但是，懒汉模式线程安全性不高，若是多线程，又怎能保证单例？

第一种方法：同步

      在方法调用上加了同步，虽然线程安全了，但是每次都要同步，会影响性能，毕竟99%的情况下是不需要同步的

 public static synchronized Pet getInfo(){
        if(pet==null){
            pet=new Pet();
        }
        return pet;
    }

 

第二种方法：双重检查锁定

      在getInfo中做了两次null检查，确保了只有第一次调用单例的时候才会做同步，这样也是线程安全的，同时避免了每次都同步的性能损耗

所谓“双重检查加锁”机制，指的是：并不是每次进入getInstance方法都需要同步，而是先不同步，进入方法后，先检查实例是否存在，如果不存在才进行下面的同步块，这是第一重检查，进入同步块过后，再次检查实例是否存在，如果不存在，就在同步的情况下创建一个实例，这是第二重检查。这样一来，就只需要同步一次了，从而减少了多次在同步情况下进行判断所浪费的时间。

　　“双重检查加锁”机制的实现会使用关键字volatile，它的意思是：被volatile修饰的变量的值，将不会被本地线程缓存，所有对该变量的读写都是直接操作共享内存，从而确保多个线程能正确的处理该变量。

 public static Pet getInfo(){
        if(pet==null){
            synchronized(Pet.class){
                 if(pet==null){
                     pet=new Pet();
                  }
             }
        }
        return pet;
    }

 

第三种方法：静态内部类

       利用了classloader的机制来保证初始化时只有一个线程，所以也是线程安全的，同时没有性能损耗

public class Pet {    
    private static class LazyHolder {    
       private static final Pet INSTANCE = new Pet();    
    }    
    private Pet (){}    
    public static final Singleton getInfo() {    
       return LazyHolder.INSTANCE;    
    }    
}  

资源加载和性能：

      饿汉模式在类创建的同时就实例化一个静态对象，不管之后会不会使用这个单例，都会占用一定的内存，但是相应的，在第一次调用时速度也会非常快，因为其资源已经初始化完成。

      懒汉模式会延迟加载，在第一次使用该单例的时候才会实例化对象出来，第一次调用时要做初始化，如果要做的工作比较多，性能上会有些延迟，之后就和饿汉模式一样可。