单例模式

关注

原创最新推荐文章于 2026-05-18 09:00:00 发布 376 阅读 AI 写同款· GEO 优化 ›

Unity框架学习【单例模式基类】{个人单例模式总结，框架单例模式总结} 这三天花了点时间，学习了B站唐老师的框架，里面有很多知识都有很强的复用性。即，完成一次之后的很多工作都可以节省，而且优化整个程序的结构。首先就是唐老师的课程都是递进式的，也就是前面的课程会很大程度的影响到后面的课程，而单例模式，是我目前使用最多的模式【要加紧学习新的设计模式】，例如在我的一本介绍《游戏设计模式》课本里面就有明确的写到。 “唯独单例模式，我们是要考虑怎么尽可能少的去使用他” 然后... 阅读详情

Singleton模式主要作用是保证在Java应用程序中，一个类Class只有一个实例存在。在很多操作中，比如建立目录数据库连接都需要这样的单线程操作。一些资源管理器常常设计成单例模式。
外部资源：譬如每台计算机可以有若干个打印机，但只能有一个Printer Spooler,以避免两个打印作业同时输出到打印机中。每台计算机可以有若干个通信端口，系统应当集中管理这些通信端口，以避免一个通信端口被两个请求同时调用。

意图：

保证一个类仅有一个实例，并提供一个访问它的全局访问点。

1. 最简单的实现

首先，能够想到的最简单的实现是，把类的构造函数写成private的，从而保证别的类不能实例化此类，然后在类中提供一个静态的实例并能够返回给使用者。这样，使用者就可以通过这个引用使用到这个类的实例了。

public class SingletonClass {

private static final SingletonClass instance = new SingletonClass();

//这就是饿汉式单例模式

  public static SingletonClass getInstance() {
    return instance;
  }

  private SingletonClass() {

  }

}

如上例，外部使用者如果需要使用SingletonClass的实例，只能通过getInstance()方法，并且它的构造方法是private的，这样就保证了只能有一个对象存在。

饿汉式在类创建的同时就已经创建好一个静态的对象供系统使用，以后不再改变，所以天生是线程安全的。

2. 性能优化——lazy loaded

上面的代码虽然简单，但是有一个问题——无论这个类是否被使用，都会创建一个instance对象。如果这个创建过程很耗时，比如需要连接10000次数据库(夸张了…:-))，并且这个类还并不一定会被使用，那么这个创建过程就是无用的。怎么办呢？

为了解决这个问题，我们想到了新的解决方案：

public class SingletonClass {
//这就是懒汉式单例模式
  private static SingletonClass instance = null;

  public static SingletonClass getInstance() {
    if(instance == null) {
      instance = new SingletonClass();
    }
    return instance;
  }

  private SingletonClass() {

  }

}

代码的变化有两处——首先，把instance初始化为null，直到第一次使用的时候通过判断是否为null来创建对象。因为创建过程不在声明处，所以那个final的修饰必须去掉。

但是以上懒汉式单例的实现没有考虑线程安全问题

我们来想象一下这个过程。要使用SingletonClass，调用getInstance()方法。第一次的时候发现instance是null，然后就新建一个对象，返回出去；第二次再使用的时候，因为这个instance是static的，所以已经不是null了，因此不会再创建对象，直接将其返回。

有以下三种方式，都是对getInstance这个方法改造，保证了懒汉式单例的线程安全

3. 同步

上面的代码很清楚，也很简单。然而就像那句名言：“80%的错误都是由20%代码优化引起的”。单线程下，这段代码没有什么问题，可是如果是多线程，麻烦就来了。我们来分析一下：

线程A希望使用SingletonClass，调用getInstance()方法。因为是第一次调用，A就发现instance是null的，于是它开始创建实例，就在这个时候，CPU发生时间片切换，线程B开始执行，它要使用SingletonClass，调用getInstance()方法，同样检测到instance是null——注意，这是在A检测完之后切换的，也就是说A并没有来得及创建对象——因此B开始创建。B创建完成后，切换到A继续执行，因为它已经检测完了，所以A不会再检测一遍，它会直接创建对象。这样，线程A和B各自拥有一个SingletonClass的对象——单例失败！

解决的方法也很简单，那就是加锁：

1、在getInstance方法上加同步

public class SingletonClass {

private static SingletonClass instance = null;

//这也是懒汉式单例模式

  public synchronized static SingletonClass getInstance() {
    if(instance == null) {
      instance = new SingletonClass();
    }
    return instance;
  }

  private SingletonClass() {

  }

}

是要getInstance()加上同步锁，一个线程必须等待另外一个线程创建完成后才能使用这个方法，这就保证了单例的唯一性。

4. 又是性能

上面的代码又是很清楚很简单的，然而，简单的东西往往不够理想。这段代码毫无疑问存在性能的问题——synchronized修饰的同步块可是要比一般的代码段慢上几倍的！如果存在很多次getInstance()的调用，那性能问题就不得不考虑了！

让我们来分析一下，究竟是整个方法都必须加锁，还是仅仅其中某一句加锁就足够了？我们为什么要加锁呢？分析一下出现lazy loaded的那种情形的原因。原因就是检测null的操作和创建对象的操作分离了。如果这两个操作能够原子地进行，那么单例就已经保证了。于是，我们开始修改代码：

2、双重检查锁定

public class SingletonClass {

  private static SingletonClass instance = null;

  public static SingletonClass getInstance() {
    synchronized (SingletonClass.class) {
      if(instance == null) {
        instance = new SingletonClass();
      }
    }
    return instance;
  }

  private SingletonClass() {

  }

}

3、静态内部类 //不再写了，不懂了都

饿汉式和懒汉式区别

从名字上来说，饿汉和懒汉，

饿汉就是类一旦加载，就把单例初始化完成，保证getInstance的时候，单例是已经存在的了，

而懒汉比较懒，只有当调用getInstance的时候，才回去初始化这个单例。

另外从以下两点再区分以下这两种方式：

1、线程安全：

饿汉式天生就是线程安全的，可以直接用于多线程而不会出现问题，

懒汉式本身是非线程安全的，为了实现线程安全有几种写法，分别是上面的1、2、3，这三种实现在资源加载和性能方面有些区别。

2、资源加载和性能：

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

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