【计划模式】单例模式深度解析:从饿汉式到枚举实现的全方位解读 ...

打印 上一主题 下一主题

主题 956|帖子 956|积分 2868

单例计划模式概念

就是采取一定的方法包管在整个的软件系统中,对某个类只能存在一个对象实例,并且该类只提供一个取得其对象实例的方法。如果我们要让类在一个虚拟机中只能产生一个对象,我们首先必须将类的构造器的访问权限设置为private,这样,就不能用new操作符在类的外部产生类的对象了,但在类内部仍可以产生该类的对象。因为在类的外部开始还无法得到类的对象,只能调用该类的某个静态方法以返回类内部创建的对象,静态方法只能访问类中的静态成员变量,所以,指向类内部产生的该类对象的变量也必须定义成静态的。
饿汉式
  1. class Singleton {
  2.     // 1.私有化构造器
  3.     private Singleton() {
  4.     }
  5.     // 2.内部提供一个当前类的实例
  6.     // 4.此实例也必须静态化
  7.     private static Singleton single = new Singleton();
  8.     // 3.提供公共的静态的方法,返回当前类的对象;在内存中自始至终都存在
  9.     public static Singleton getInstance() {
  10.         return single;
  11.     }
  12. }
复制代码
案例:
  1. public static void main(String[] args) {
  2.         User user1 = User.getUser();
  3.         System.out.println(user1);
  4.         User user2 = User.getUser();
  5.         System.out.println(user2);
  6. }
  7. class User{
  8.     //1、私有化构造器
  9.     private User() {
  10.     }
  11.     //2、内部提供一个当前类的实例,此实例也必须静态化
  12.     private static User user = new User();
  13.     //3、提供公共的静态的方法,返回当前类的对象;在内存中自始至终都存在
  14.     public static User getUser() {
  15.         return user;
  16.     }
  17. }
  18. //结果是一样的,即同一个对象
  19. com.gupao.singleton.User@6d6f6e28
  20. com.gupao.singleton.User@6d6f6e28
复制代码
static变量在类加载的时候初始化,此时不会涉及到多个线程对象访问该对象的问题,虚拟机包管只会装载一次该类,肯定不会发生并发问题,无需使用synchronized 关键字
存在的问题:如果只是加载了本类,而并不需要调用getUser,则会造成资源的浪费。
总结:线程安全、非懒加载、效率高,资源浪费
懒汉式

延迟对象的创建
方式1:平凡创建
  1. public class Singleton {
  2.     //私有构造方法
  3.     private Singleton() {}
  4.     //在成员位置创建该类的对象
  5.     private static Singleton instance;
  6.     //对外提供静态方法获取该对象
  7.     public static Singleton getInstance() {
  8.         if(instance == null) {
  9.             instance = new Singleton();
  10.         }
  11.         return instance;
  12.     }
  13. }
复制代码
如果是多线程环境,以上代码会出现线程安全问题。
方式2:方法加锁
  1. class Singleton {
  2.     // 1.私有化构造器
  3.     private Singleton() {
  4.     }
  5.     // 2.内部提供一个当前类的实例
  6.     // 4.此实例也必须静态化
  7.     private static Singleton instance;
  8.     // 3.提供公共的静态的方法,返回当前类的对象
  9.     public static synchronized Singleton getInstance() {//注意多线程情况
  10.         if(instance== null) {
  11.         instance= new Singleton();
  12.         }
  13.     return instance;
  14.     }
  15. }
复制代码
以上使用同步方法会造成每次获取实例的线程都要等锁,会对系统性能造成影响,未能完全发挥系统性能,可使用同步代码块来办理
方式3:双重检查锁

对于 getInstance() 方法来说,绝大部分的操作都是读操作,读操作是线程安全的,所以我们没必让每个线程必须持有锁才能调用该方法,我们需要调整加锁的机遇。由此也产生了一种新的实现模式:双重检查锁模式
  1. public class Singleton {
  2.     //私有构造方法
  3.     private Singleton() {}
  4.     private volatile static Singleton instance;
  5.    //对外提供静态方法获取该对象
  6.     public static Singleton getInstance() {
  7.                 //第一次判断,如果instance不为null,不进入抢锁阶段,直接返回实例
  8.         if(instance == null) { // ①
  9.             synchronized (Singleton.class) {
  10.                 //抢到锁之后再次判断是否为null
  11.                 if(instance == null) {
  12.                     instance = new Singleton();// ②
  13.                 }
  14.             }
  15.         }
  16.         return instance;
  17.     }
  18. }
复制代码
为什么判断两次instance==null

第一次判断是在代码块前,第二次是进入代码块后,第二个判断想必都知道,多个线程都堵到代码块前等待锁的释放,进入代码块后要获取到最新的instance值,如果为空就进行创建对象。
那么为什么还要进行第一个判断,第一个判断起到优化作用,假设如果instance已经不为空了,那么没有第一个判断仍然会有线程堵在代码块前等待进一步判断,所以如果不为空,有了第一个判断就不消再去进入代码块进行判断,也就不消再去等锁了,直接返回。
为什么要加volatile?


  • 是为了防止指令重排序,给私有变量加 volatile 主要是为了防止第 ② 处实行时,也就是“instance = new Singleton()”实行时的指令重排序的,这行代码看似只是一个创建对象的过程,然而它的实际实行却分为以下 3 步:

    • 创建内存空间。
    • 在内存空间中初始化对象 Singleton。
    • 将内存地址赋值给 instance 对象(实行了此步调,instance 就不等于 null 了)。
    试想一下,如果不加 volatile,那么线程A在实行到上述代码的第 ② 处时就可能会实行指令重排序,将原本是 1、2、3 的实行序次,重排为 1、3、2。但是特别情况下,线程 A在实行完第 3 步之后,如果来了线程 B实行到上述代码的第 ① 处,判断 instance 对象已经不为 null,但此时线程 A还未将对象实例化完,那么线程B将会得到一个被实例化“一半”的对象,从而导致程序实行出错,这就是为什么要给私有变量添加 volatile 的原因了。

  • 优化作用,synchronized块只有实行完才会同步到主内存,那么好比说instance刚创建完成,不为空,但还没有跳出synchronized块,此时又有10000个线程调用方法,那么如果没有volatile,此使instance在主内存中仍然为空,这一万个线程仍然要通过第一次判断,进入代码块前进行等待,正是有了volatile,一旦instance改变,那么便会同步到主内存,即使没有出synchronized块,instance仍然同步到了主内存,通过不了第一个判断也就避免了新加的10000个线程进入去争取锁。
总结:线程安全、懒加载、效率高。
静态内部类(延迟初始化占位类)

静态内部类单例模式中实例由内部类创建,由于 JVM 在加载外部类的过程中, 是不会加载静态内部类的, 只有内部类的属性/方法被调用时才会被加载, 并初始化其静态属性。静态属性由于被 static 修饰,包管只被实例化一次,并且严格包管实例化序次。
  1. public class Singleton {
  2.     private Singleton() {
  3.     }
  4.     private static class SingletonHolder{
  5.         private  static final Singleton Instance = new Singleton();
  6.     }
  7.     public static Singleton getInstance(){
  8.         return SingletonHolder.Instance;
  9.     }
  10. }
复制代码
第一次加载Singleton类时不会去初始化INSTANCE,只有第一次调用getInstance,虚拟机加载SingletonHolder并初始化INSTANCE,这样不光能确保线程安全,也能包管 Singleton 类的唯一性。
静态内部类单例模式是一种优秀的单例模式,是开源项目中比较常用的一种单例模式。在没有加任何锁的情况下,包管了多线程下的安全,并且没有任何性能影响和空间的浪费。
总结:线程安全、懒加载、效率高。
枚举

枚举类实现单例模式是极力推荐的单例实现模式,因为枚举类型是线程安全的,并且只会装载一次,计划者充分的利用了枚举的这个特性来实现单例模式,枚举的写法非常简单,而且枚举类型是所用单例实现中唯一一种不会被破坏的单例实现模式。
  1. public enum Singleton {
  2.      INSTANCE;
  3. }
复制代码
提供了序列化机制,包管线程安全,绝对防止多次实例化,即使是在面对复杂的序列化或者反射攻击的时候。
枚举方式属于饿汉式方式,会浪费资源
总结:线程安全、非懒加载、效率高。
几种方式对比

方式优点缺点饿汉式线程安全、效率高非懒加载,资源浪费懒汉式synchronized方法线程安全、懒加载效率低懒汉式双重检测线程安全、懒加载、效率高无静态内部类线程安全、懒加载、效率高无枚举线程安全、效率高非懒加载,资源浪费Runtime类

Runtime类就是使用的单例计划模式。
  1. public class Runtime {
  2.     private static Runtime currentRuntime = new Runtime();
  3.     /**
  4.      * Returns the runtime object associated with the current Java application.
  5.      * Most of the methods of class Runtime are instance
  6.      * methods and must be invoked with respect to the current runtime object.
  7.      *
  8.      * @return  the Runtime object associated with the current
  9.      *          Java application.
  10.      */
  11.     public static Runtime getRuntime() {
  12.         return currentRuntime;
  13.     }
  14.     /** Don't let anyone else instantiate this class */
  15.     private Runtime() {}
  16.     ...
  17. }
复制代码
可以看出Runtime类使用的是饿汉式(静态属性)方式来实现单例模式的。
往期推荐


免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。
回复

使用道具 举报

0 个回复

正序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

勿忘初心做自己

金牌会员
这个人很懒什么都没写!
快速回复 返回顶部 返回列表