zoukankan      html  css  js  c++  java
  • 1.Singleton,单例模式

    概念:

    在Java应用程序中,一个类Class只有一个实例存在

    运用:

    1)系统资源,如文件路径,数据库链接,系统常量等

    2)全局状态化类,类似AutomicInteger的使用

    优缺点:

    1)节省内存有利于垃圾回收

    2)只能使用在特定的环境下,受限制于JVM和容器

         单例作用范围的前提是在一个ClassLoad下。所以像分布式应用EJB就要用其它的方式来解决单例问题。

    Demo:

    分别列出多种实现方式,各分析其优缺点

    1)静态成员直接初始化,或者在静态代码块初始化都可以

    1 class Singleton{    
    2     private Singleton(){}    
    3     private static final Singleton singleton = new Singleton();    
    4     public static Singleton getInstance(){return singleton;}    
    5 }  

     该实现只要在一个ClassLoad下就会提供一个对象的单例。但是美中不足的是,不管该资源是否被请求,它都会创建一个对象,占用jvm内存。从lazy initialization思想出发,出现了下2的写法
    2)根据lazy initialization思想,使用到时才初始化。

    1 class Singleton{    
    2     private Singleton(){}    
    3     private static Singleton singleton ;    
    4     public static synchronized Singleton getInstance(){    
    5         if(singleton==null)    
    6             singleton = new Singleton();    
    7         return singleton;           
    8     }       
    9 }  


    该实现方法加了同步锁,可以有效防止多线程在执行getInstance方法得到2个对象。
    缺点:只有在第一次调用的时候,才会出现生成2个对象,才必须要求同步。而一旦singleton 不为null,系统依旧花费同步锁开销,有点得不偿失。
    因此再改进出现写法3
    3)在2的基础上改进,改进标准:尽量减少锁资源(主要体现在执行时间,所占内存等)

     1 class Singleton{    
     2     private Singleton(){}    
     3     private static Singleton singleton ;    
     4     public static Singleton getInstance(){    
     5         if(singleton==null)//1    
     6             synchronized(Singleton.class){//2    
     7                 singleton = new Singleton();//3    
     8             }    
     9         return singleton;           
    10     }       
    11 }

    这种写法减少了锁开销,但是在如下情况,却创建了2个对象:
    a:线程1执行到1挂起,线程1认为singleton为null
    b:线程2执行到1挂起,线程2认为singleton为null
    c:线程1被唤醒执行synchronized块代码,走完创建了一个对象
    d:线程2被唤醒执行synchronized块代码,走完创建了另一个对象
    所以看出这种写法,并不完美。
    4)为了解决3存在的问题,引入双重检查锁定

    1 public static Singleton getInstance(){    
    2         if(singleton==null)//1    
    3             synchronized(Singleton.class){//2    
    4                 if(singleton==null)//3    
    5                     singleton = new Singleton();//4    
    6             }    
    7         return singleton;           
    8     } 

    在同步锁代码块内部,再判断一次对象是否为null,为null才创建对象。这种写法已经接近完美:
    a:线程1执行到1,已经进入synchronized的时候,线程挂起,线程1占有Singleton.class资源锁;
    b:线程2执行到1,当它准备synchronized块时,因为Singleton.class被占用,线程2阻塞;
    c:线程1被唤醒,判断出对象为null,执行完创建一个对象
    d:线程2被唤醒,判断出对象不为null,不执行创建语句
          如此分析,发现似乎没问题。
          但是实际上并不能保证它在单处理器或多处理器上正确运行;
          问题就出现在singleton = new Singleton()这一行代码。它可以简单的分成如下三个步骤:
    mem= singleton();//1
    instance = mem;//2
    ctorSingleton(instance);//3
           这行代码先在内存开辟空间,赋给singleton的引用,然后执行new 初始化数据,但是注意初始化是要消耗时间。如果此时线程3在执行步骤1的时候,发现singleton 为非null,就直接返回,那么线程3返回的其实是一个没构造完成的对象。
          我们期望1,2,3 按照反序执行,但是实际jvm内存模型,并没有明确的有序指定。
          这归咎于java的平台的内存模型允许“无序写入”。

    5)在4的基础上引入volatile
    代码如下:

     1 class Singleton{    
     2     private Singleton(){}    
     3     private static volatile Singleton singleton ;    
     4     public static Singleton getInstance(){    
     5         if(singleton==null)//1    
     6             synchronized(Singleton.class){//2    
     7                 if(singleton==null)//3    
     8                     singleton = new Singleton();    
     9             }    
    10         return singleton;           
    11     }       
    12 } 

    Volatile 变量具有 synchronized 的可见性特性,但是不具备原子特性。这就是说线程能够自动发现 volatile 变量的最新值。
    而volatile使用时有明确的规定:
          对变量的写操作不依赖于当前值;
          该变量没有包含在具有其他变量的不变式中;
    —— 只有在状态真正独立于程序内其他内容时才能使用 volatile。
    但是5的写法,虽然理论上似乎可以解决无序写入问题。实际上并非如此。
    (我个人觉得这里对volatile语法说的不够详细,想知道详细的可以看这篇转帖Java 理论与实践: 正确使用 Volatile 变量 )
    小结:
    1)使用同步锁方法,内部锁存在不安全。
    2)静态成员直接初始化。

    转载地址:http://blog.sina.com.cn/s/blog_9564cb6e0101c3r9.html

  • 相关阅读:
    仙人球的残影
    Calculate the formula
    自定义代码段
    getter-setter方法练习
    封装
    Xcode文档安装
    Xcode模板修改
    匿名对象
    OC多文件开发介绍
    #pragma mark指令
  • 原文地址:https://www.cnblogs.com/androidxiaoyang/p/3022864.html
Copyright © 2011-2022 走看看