gball个人知识库
首页
基础组件
基础知识
算法&设计模式
  • 操作手册
  • 数据库
  • 极客时间
  • 每日随笔
  • 学习
  • 面试
  • 心情杂货
  • 实用技巧
  • 友情链接
  • 画图工具 (opens new window)
关于
  • 网盘 (opens new window)
  • 分类
  • 标签
  • 归档
项目
GitHub (opens new window)

ggball

后端界的小学生
首页
基础组件
基础知识
算法&设计模式
  • 操作手册
  • 数据库
  • 极客时间
  • 每日随笔
  • 学习
  • 面试
  • 心情杂货
  • 实用技巧
  • 友情链接
  • 画图工具 (opens new window)
关于
  • 网盘 (opens new window)
  • 分类
  • 标签
  • 归档
项目
GitHub (opens new window)
  • 面试

  • 数据库

  • linux

  • node

  • tensorFlow

  • 基础组件

  • 基础知识

  • 算法与设计模式

  • 分布式

  • 疑难杂症

  • go学习之旅

  • 极客时间

    • 设计模式之美

      • 开篇词 (1讲)

      • 设计模式学习导读 (3讲)

      • 设计原则与思想:面向对象 (11讲)

      • 设计原则与思想:设计原则 (12讲)

      • 设计原则与思想:规范与重构 (11讲)

      • 设计原则与思想:总结课 (3讲)

      • 设计模式与范式:创建型 (7讲)

        • 单例模式(上):为什么说支持懒加载的双重检测不比饿汉式更优?
          • 为什么要使用单例?
            • 实战案例一:处理资源访问冲突
            • 实战案例二:表示全局唯一类
          • 如何实现一个单例?
            • 1.饿汉式
            • 2.懒汉式
            • 3.双重检测
            • 4.静态内部类
            • 5.枚举
          • 重点回顾
          • 课堂讨论
          • 精选评论
        • 单例模式(中):我为什么不推荐使用单例模式?又有何替代方案?
        • 单例模式(下):如何设计实现一个集群环境下的分布式单例模式?
        • 工厂模式(上):我为什么说没事不要随便用工厂模式创建对象?
        • 工厂模式(下):如何设计实现一个DependencyInjection框架?
        • 建造者模式:详解构造函数、set方法、建造者模式三种对象创建方式
        • 原型模式:如何最快速地clone一个HashMap散列表?
      • 设计模式与范式:结构型 (8讲)

      • 设计模式与范式:行为型 (18讲)

      • 设计模式与范式:总结课 (2讲)

      • 开源与项目实战:开源实战 (14讲)

      • 开源与项目实战:项目实战 (9讲)

      • 开源与项目实战:总结课 (2讲)

      • 不定期加餐 (11讲)

      • 结束语 (1讲)

    • Redis核心技术与实战

单例模式(上):为什么说支持懒加载的双重检测不比饿汉式更优?

# 41 | 单例模式(上):为什么说支持懒加载的双重检测不比饿汉式更优?

从今天开始,我们正式进入到设计模式的学习。我们知道,经典的设计模式有23种。其中,常用的并不是很多。据我的工作经验来看,常用的可能都不到一半。如果随便抓一个程序员,让他说一说最熟悉的3种设计模式,那其中肯定会包含今天要讲的单例模式。

网上有很多讲解单例模式的文章,但大部分都侧重讲解,如何来实现一个线程安全的单例。我今天也会讲到各种单例的实现方法,但是,这并不是我们专栏学习的重点,我重点还是希望带你搞清楚下面这样几个问题(第一个问题会在今天讲解,后面三个问题放到下一节课中讲解)。

  • 为什么要使用单例?

  • 单例存在哪些问题?

  • 单例与静态类的区别?

  • 有何替代的解决方案?

话不多说,让我们带着这些问题,正式开始今天的学习吧!

# 为什么要使用单例?

单例设计模式(SingletonDesignPattern)理解起来非常简单。一个类只允许创建一个对象(或者实例),那这个类就是一个单例类,这种设计模式就叫作单例设计模式,简称单例模式。

对于单例的概念,我觉得没必要解释太多,你一看就能明白。我们重点看一下,为什么我们需要单例这种设计模式?它能解决哪些问题?接下来我通过两个实战案例来讲解。

# 实战案例一:处理资源访问冲突

我们先来看第一个例子。在这个例子中,我们自定义实现了一个往文件中打印日志的Logger类。具体的代码实现如下所示:

public class Logger {
  private FileWriter writer;
  
  public Logger() {
    File file = new File("/Users/wangzheng/log.txt");
    writer = new FileWriter(file, true); //true表示追加写入
  }
  
  public void log(String message) {
    writer.write(mesasge);
  }
}

// Logger类的应用示例:
public class UserController {
  private Logger logger = new Logger();
  
  public void login(String username, String password) {
    // ...省略业务逻辑代码...
    logger.log(username + " logined!");
  }
}

public class OrderController {
  private Logger logger = new Logger();
  
  public void create(OrderVo order) {
    // ...省略业务逻辑代码...
    logger.log("Created an order: " + order.toString());
  }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

看完代码之后,先别着急看我下面的讲解,你可以先思考一下,这段代码存在什么问题。

在上面的代码中,我们注意到,所有的日志都写入到同一个文件/Users/wangzheng/log.txt中。在UserController和OrderController中,我们分别创建两个Logger对象。在Web容器的Servlet多线程环境下,如果两个Servlet线程同时分别执行login()和create()两个函数,并且同时写日志到log.txt文件中,那就有可能存在日志信息互相覆盖的情况。

为什么会出现互相覆盖呢?我们可以这么类比着理解。在多线程环境下,如果两个线程同时给同一个共享变量加1,因为共享变量是竞争资源,所以,共享变量最后的结果有可能并不是加了2,而是只加了1。同理,这里的log.txt文件也是竞争资源,两个线程同时往里面写数据,就有可能存在互相覆盖的情况。

图片

那如何来解决这个问题呢?我们最先想到的就是通过加锁的方式:给log()函数加互斥锁(Java中可以通过synchronized的关键字),同一时刻只允许一个线程调用执行log()函数。具体的代码实现如下所示:

public class Logger {
  private FileWriter writer;

  public Logger() {
    File file = new File("/Users/wangzheng/log.txt");
    writer = new FileWriter(file, true); //true表示追加写入
  }
  
  public void log(String message) {
    synchronized(this) {
      writer.write(mesasge);
    }
  }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

不过,你仔细想想,这真的能解决多线程写入日志时互相覆盖的问题吗?答案是否定的。这是因为,这种锁是一个对象级别的锁,一个对象在不同的线程下同时调用log()函数,会被强制要求顺序执行。但是,不同的对象之间并不共享同一把锁。在不同的线程下,通过不同的对象调用执行log()函数,锁并不会起作用,仍然有可能存在写入日志互相覆盖的问题。

图片

我这里稍微补充一下,在刚刚的讲解和给出的代码中,我故意“隐瞒”了一个事实:我们给log()函数加不加对象级别的锁,其实都没有关系。因为FileWriter本身就是线程安全的,它的内部实现中本身就加了对象级别的锁,因此,在在外层调用write()函数的时候,再加对象级别的锁实际上是多此一举。因为不同的Logger对象不共享FileWriter对象,所以,FileWriter对象级别的锁也解决不了数据写入互相覆盖的问题。

那我们该怎么解决这个问题呢?实际上,要想解决这个问题也不难,我们只需要把对象级别的锁,换成类级别的锁就可以了。让所有的对象都共享同一把锁。这样就避免了不同对象之间同时调用log()函数,而导致的日志覆盖问题。具体的代码实现如下所示:

public class Logger {
  private FileWriter writer;

  public Logger() {
    File file = new File("/Users/wangzheng/log.txt");
    writer = new FileWriter(file, true); //true表示追加写入
  }
  
  public void log(String message) {
    synchronized(Logger.class) { // 类级别的锁
      writer.write(mesasge);
    }
  }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

除了使用类级别锁之外,实际上,解决资源竞争问题的办法还有很多,分布式锁是最常听到的一种解决方案。不过,实现一个安全可靠、无bug、高性能的分布式锁,并不是件容易的事情。除此之外,并发队列(比如Java中的BlockingQueue)也可以解决这个问题:多个线程同时往并发队列里写日志,一个单独的线程负责将并发队列中的数据,写入到日志文件。这种方式实现起来也稍微有点复杂。

相对于这两种解决方案,单例模式的解决思路就简单一些了。单例模式相对于之前类级别锁的好处是,不用创建那么多Logger对象,一方面节省内存空间,另一方面节省系统文件句柄(对于操作系统来说,文件句柄也是一种资源,不能随便浪费)。

我们将Logger设计成一个单例类,程序中只允许创建一个Logger对象,所有的线程共享使用的这一个Logger对象,共享一个FileWriter对象,而FileWriter本身是对象级别线程安全的,也就避免了多线程情况下写日志会互相覆盖的问题。

按照这个设计思路,我们实现了Logger单例类。具体代码如下所示:

public class Logger {
  private FileWriter writer;
  private static final Logger instance = new Logger();

  private Logger() {
    File file = new File("/Users/wangzheng/log.txt");
    writer = new FileWriter(file, true); //true表示追加写入
  }
  
  public static Logger getInstance() {
    return instance;
  }
  
  public void log(String message) {
    writer.write(mesasge);
  }
}

// Logger类的应用示例:
public class UserController {
  public void login(String username, String password) {
    // ...省略业务逻辑代码...
    Logger.getInstance().log(username + " logined!");
  }
}

public class OrderController {
  private Logger logger = new Logger();
  
  public void create(OrderVo order) {
    // ...省略业务逻辑代码...
    Logger.getInstance().log("Created a order: " + order.toString());
  }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

# 实战案例二:表示全局唯一类

从业务概念上,如果有些数据在系统中只应保存一份,那就比较适合设计为单例类。

比如,配置信息类。在系统中,我们只有一个配置文件,当配置文件被加载到内存之后,以对象的形式存在,也理所应当只有一份。

再比如,唯一递增ID号码生成器(中我们讲的是唯一ID生成器,这里讲的是唯一递增ID生成器),如果程序中有两个对象,那就会存在生成重复ID的情况,所以,我们应该将ID生成器类设计为单例。

import java.util.concurrent.atomic.AtomicLong;
public class IdGenerator {
  // AtomicLong是一个Java并发库中提供的一个原子变量类型,
  // 它将一些线程不安全需要加锁的复合操作封装为了线程安全的原子操作,
  // 比如下面会用到的incrementAndGet().
  private AtomicLong id = new AtomicLong(0);
  private static final IdGenerator instance = new IdGenerator();
  private IdGenerator() {}
  public static IdGenerator getInstance() {
    return instance;
  }
  public long getId() { 
    return id.incrementAndGet();
  }
}

// IdGenerator使用举例
long id = IdGenerator.getInstance().getId();

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

实际上,今天讲到的两个代码实例(Logger、IdGenerator),设计的都并不优雅,还存在一些问题。至于有什么问题以及如何改造,今天我暂时卖个关子,下一节课我会详细讲解。

# 如何实现一个单例?

尽管介绍如何实现一个单例模式的文章已经有很多了,但为了保证内容的完整性,我这里还是简单介绍一下几种经典实现方式。概括起来,要实现一个单例,我们需要关注的点无外乎下面几个:

  • 构造函数需要是 private 访问权限的,这样才能避免外部通过 new 创建实例;

  • 考虑对象创建时的线程安全问题;

  • 考虑是否支持延迟加载;

  • 考虑 getInstance() 性能是否高(是否加锁)。

如果你对这块已经很熟悉了,你可以当作复习。注意,下面的几种单例实现方式是针对Java语言语法的,如果你熟悉的是其他语言,不妨对比Java的这几种实现方式,自己试着总结一下,利用你熟悉的语言,该如何实现。

# 1.饿汉式

饿汉式的实现方式比较简单。在类加载的时候,instance静态实例就已经创建并初始化好了,所以,instance实例的创建过程是线程安全的。不过,这样的实现方式不支持延迟加载(在真正用到IdGenerator的时候,再创建实例),从名字中我们也可以看出这一点。具体的代码实现如下所示:

public class IdGenerator { 
  private AtomicLong id = new AtomicLong(0);
  private static final IdGenerator instance = new IdGenerator();
  private IdGenerator() {}
  public static IdGenerator getInstance() {
    return instance;
  }
  public long getId() { 
    return id.incrementAndGet();
  }
}

1
2
3
4
5
6
7
8
9
10
11
12

有人觉得这种实现方式不好,因为不支持延迟加载,如果实例占用资源多(比如占用内存多)或初始化耗时长(比如需要加载各种配置文件),提前初始化实例是一种浪费资源的行为。最好的方法应该在用到的时候再去初始化。不过,我个人并不认同这样的观点。

如果初始化耗时长,那我们最好不要等到真正要用它的时候,才去执行这个耗时长的初始化过程,这会影响到系统的性能(比如,在响应客户端接口请求的时候,做这个初始化操作,会导致此请求的响应时间变长,甚至超时)。采用饿汉式实现方式,将耗时的初始化操作,提前到程序启动的时候完成,这样就能避免在程序运行的时候,再去初始化导致的性能问题。

如果实例占用资源多,按照fail-fast的设计原则(有问题及早暴露),那我们也希望在程序启动时就将这个实例初始化好。如果资源不够,就会在程序启动的时候触发报错(比如Java中的PermGenSpaceOOM),我们可以立即去修复。这样也能避免在程序运行一段时间后,突然因为初始化这个实例占用资源过多,导致系统崩溃,影响系统的可用性。

# 2.懒汉式

有饿汉式,对应地,就有懒汉式。懒汉式相对于饿汉式的优势是支持延迟加载。具体的代码实现如下所示:

public class IdGenerator { 
  private AtomicLong id = new AtomicLong(0);
  private static IdGenerator instance;
  private IdGenerator() {}
  public static synchronized IdGenerator getInstance() {
    if (instance == null) {
      instance = new IdGenerator();
    }
    return instance;
  }
  public long getId() { 
    return id.incrementAndGet();
  }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

不过懒汉式的缺点也很明显,我们给getInstance()这个方法加了一把大锁(synchronzed),导致这个函数的并发度很低。量化一下的话,并发度是1,也就相当于串行操作了。而这个函数是在单例使用期间,一直会被调用。如果这个单例类偶尔会被用到,那这种实现方式还可以接受。但是,如果频繁地用到,那频繁加锁、释放锁及并发度低等问题,会导致性能瓶颈,这种实现方式就不可取了。

# 3.双重检测

饿汉式不支持延迟加载,懒汉式有性能问题,不支持高并发。那我们再来看一种既支持延迟加载、又支持高并发的单例实现方式,也就是双重检测实现方式。

在这种实现方式中,只要instance被创建之后,即便再调用getInstance()函数也不会再进入到加锁逻辑中了。所以,这种实现方式解决了懒汉式并发度低的问题。具体的代码实现如下所示:

public class IdGenerator { 
  private AtomicLong id = new AtomicLong(0);
  private static IdGenerator instance;
  private IdGenerator() {}
  public static IdGenerator getInstance() {
    if (instance == null) {
      synchronized(IdGenerator.class) { // 此处为类级别的锁
        if (instance == null) {
          instance = new IdGenerator();
        }
      }
    }
    return instance;
  }
  public long getId() { 
    return id.incrementAndGet();
  }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

网上有人说,这种实现方式有些问题。因为指令重排序,可能会导致IdGenerator对象被new出来,并且赋值给instance之后,还没来得及初始化(执行构造函数中的代码逻辑),就被另一个线程使用了。

要解决这个问题,我们需要给instance成员变量加上volatile关键字,禁止指令重排序才行。实际上,只有很低版本的Java才会有这个问题。我们现在用的高版本的Java已经在JDK内部实现中解决了这个问题(解决的方法很简单,只要把对象new操作和初始化操作设计为原子操作,就自然能禁止重排序)。关于这点的详细解释,跟特定语言有关,我就不展开讲了,感兴趣的同学可以自行研究一下。

# 4.静态内部类

我们再来看一种比双重检测更加简单的实现方法,那就是利用Java的静态内部类。它有点类似饿汉式,但又能做到了延迟加载。具体是怎么做到的呢?我们先来看它的代码实现。

public class IdGenerator { 
  private AtomicLong id = new AtomicLong(0);
  private IdGenerator() {}

  private static class SingletonHolder{
    private static final IdGenerator instance = new IdGenerator();
  }
  
  public static IdGenerator getInstance() {
    return SingletonHolder.instance;
  }
 
  public long getId() { 
    return id.incrementAndGet();
  }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

SingletonHolder是一个静态内部类,当外部类IdGenerator被加载的时候,并不会创建SingletonHolder实例对象。只有当调用getInstance()方法时,SingletonHolder才会被加载,这个时候才会创建instance。insance的唯一性、创建过程的线程安全性,都由JVM来保证。所以,这种实现方法既保证了线程安全,又能做到延迟加载。

# 5.枚举

最后,我们介绍一种最简单的实现方式,基于枚举类型的单例实现。这种实现方式通过Java枚举类型本身的特性,保证了实例创建的线程安全性和实例的唯一性。具体的代码如下所示:

public enum IdGenerator {
  INSTANCE;
  private AtomicLong id = new AtomicLong(0);
 
  public long getId() { 
    return id.incrementAndGet();
  }
}

1
2
3
4
5
6
7
8
9

# 重点回顾

好了,今天的内容到此就讲完了。我们来总结回顾一下,你需要掌握的重点内容。

1.单例的定义

单例设计模式(SingletonDesignPattern)理解起来非常简单。一个类只允许创建一个对象(或者叫实例),那这个类就是一个单例类,这种设计模式就叫作单例设计模式,简称单例模式。

2.单例的用处

从业务概念上,有些数据在系统中只应该保存一份,就比较适合设计为单例类。比如,系统的配置信息类。除此之外,我们还可以使用单例解决资源访问冲突的问题。

3.单例的实现

单例有下面几种经典的实现方式。

  • 饿汉式

饿汉式的实现方式,在类加载的期间,就已经将instance静态实例初始化好了,所以,instance实例的创建是线程安全的。不过,这样的实现方式不支持延迟加载实例。

  • 懒汉式

懒汉式相对于饿汉式的优势是支持延迟加载。这种实现方式会导致频繁加锁、释放锁,以及并发度低等问题,频繁的调用会产生性能瓶颈。

  • 双重检测

双重检测实现方式既支持延迟加载、又支持高并发的单例实现方式。只要instance被创建之后,再调用getInstance()函数都不会进入到加锁逻辑中。所以,这种实现方式解决了懒汉式并发度低的问题。

  • 静态内部类

利用Java的静态内部类来实现单例。这种实现方式,既支持延迟加载,也支持高并发,实现起来也比双重检测简单。

  • 枚举

最简单的实现方式,基于枚举类型的单例实现。这种实现方式通过Java枚举类型本身的特性,保证了实例创建的线程安全性和实例的唯一性。

# 课堂讨论

  • 在你所熟悉的编程语言的类库中,有哪些类是单例类?又为什么要设计成单例类呢?

  • 在第一个实战案例中,除了我们讲到的类级别锁、分布式锁、并发队列、单例模式等解决方案之外,实际上还有一种非常简单的解决日志互相覆盖问题的方法,你想到了吗?

可以在留言区说一说,和同学一起交流和分享。如果有收获,也欢迎你把这篇文章分享给你的朋友。

# 精选评论

点击查看

aof

这真的是看过的关于讲单例的最好的文章


Douglas

争哥新年好,有个问题想请教一下,单例的实现中看到过一种实现方式,包括在spring源码中有类似的实现,代码如下  1.publicclassSingleton{     privatestaticvolatileSingletoninstance=null;     privateSingleton(){     }

publicstaticSingletongetInstance(){//         Singletontemp=instance;//为什么要用局部变量来接收         if(null==temp){             synchronized(Singleton.class){                 temp=instance;                 if(null==temp){                     temp=newSingleton();                     instance=temp;                 }             }         }         returninstance;     } }

spring源码如ReactiveAdapterRegistry。 JDK源码如AbstractQueuedSynchronizer。 很多地方都有用局部变量来接收静态的成员变量,请问下这么写有什么性能上的优化点吗? jcu包下面类似的用法太多。想弄明白为什么要这样写 2.看jdk官方的文档(JMM)有说明指令重排发生的地方有很多,编译器,及时编译,CPU在硬件层面的优化,看spring比较新的代码也使用volatile来修饰,你说的new关键字和初始化作为原子操作可以说一下大概的jdk版本吗


辣么大


黄林晴

打卡

看过Eventbus的源码,写法是典型的双重锁检验方式,但是构造方法是public的

看源码解释,这是因为EventBus可能有多条总线,订阅者注册到不同线上的EventBus,通过不同的实例来发送数据,不同的EventBus是相互隔离开的,订阅者都只会收到注册到该线上事件。

但是按照单例定义他又不属于单例,感觉很有疑问


忆水寒


🤤🤤

这篇非常棒,🔨


小晏子

1.JDK中java.lang.Runtime是单例实现的,该类用于管理应用程序运行期间的各种信息,比如memory和processor信息,所以从该类的用途可以知道该类必须是单例的。 2.使用多个文件,每new一个实例就使用一个新文件,这样就没有文件覆盖问题了。


zs阿帅


沈康

1、javabean大部分都是单例吧,例如我们的servicebean,单例也是为了复用类和资源共享吧,但是要注意单例需要无状态,有状态的则要考虑线程安全问题 2、如果线程安全的话,共享一个类就可以了,依赖注入


Summer 空城

王老师这篇讲解的非常棒,赞!


xindoo


传说中的成大大

为何在讲本文中实战一 ublicclassOrderController{privateLoggerlogger=newLogger();publicvoidcreate(OrderVoorder){//...省略业务逻辑代码...Logger.getInstance().log("Createdaorder:"+order.toString());}} 还有一行这个代码?privateLoggerlogger=newLogger();


Fstar

我想到的其他解决日志互相覆盖问题的方法: 1.配合数据库使用。数据库自己做了处理,就不需要自己考虑覆盖问题了。缺点是日志系统理论上不应该用上数据库,会导致扩展性不好。 2.每个线程创建一个日志文件,间隔一段时间将多个日志文件进行合并为大的日志文件。缺点是线程多的时候比较消耗资源。 3.将日志信息发送出去,比如通过http请求,让一个单线程的服务接收并记录日志。这种实现有点像消息队列了。


相逢是缘

打卡 1、单例模式的定义: 一个类只允许创建一个对象(或者实例),那这个类就是一个单例类,这种设计模式就叫作单例设计模式,简称单例模式。 2、单例的用途: 1)处理资源访问冲突问题 2)处理数据在系统中只应保存一份 3、如何实现一个单例类 1)饿汉模式 类加载时,instance实例已经创建好; 2)懒汉模式 延迟加载,但是getInstance需要加锁,导致并发度很低 publicstaticsynchronizedIdGeneratorgetInstance(){ if(instance==null){ instance=newIdGenerator(); } returninstance;  } 3)双重检测 只要instance被创建之后,即便再调用getInstance()函数也不会再进入到加锁逻辑中了。 (支持延迟加载、支持高并发) publicstaticIdGeneratorgetInstance(){  if(instance==null){ synchronized(IdGenerator.class){//此处为类级别的锁 if(instance==null){  instance=newIdGenerator(); } } } returninstance;  } 4)静态内部类 insance的唯一性、创建过程的线程安全性,都由JVM来保证。 privatestaticclassSingletonHolder{ privatestaticfinalIdGeneratorinstance=newIdGenerator(); } publicstaticIdGeneratorgetInstance(){ returnSingletonHolder.instance;  } 5)枚举


天天向上卡索


东流

1.在你所熟悉的编程语言的类库中,有哪些类是单例类?又为什么要设计成单例类呢? java中的打印类,System.out,(我猜的);原因则是用起来方便

在第一个实战案例中,除了我们讲到的类级别锁、分布式锁、并发队列、单例模式等解决方案之外,实际上还有一种非常简单的解决日志互相覆盖问题的方法,你想到了吗? 没


小猴子吹泡泡

如果要实现序列化反序列化的单例模式,要增加一个readResolve()方法,代码如下: protectedObjectreadResolve()throwsObjectStreamException{     returninstance; }


javaadu


Frank

1.目前能想到的类库中使用了单例模式的有连接池、java.lang.Runtime#getRuntime,Hibernate的SessionFactory、Configuration,这么设计的的原因是维持全局唯一,还存在这些类的实例可能会占用很多内存,或者实例的初始化过程比较冗长。 2.写日志的例子中还可使用JDK1.4提供的FileLock来解决资源竞争问题,其他更简单的方式想不到。


辣么大

写了篇总结,还讨论了单例模式中序列化和反序列化的问题。https://github.com/gdhucoder/DesignPattern/blob/master/021_SingletonPattern.md


编辑 (opens new window)
#极客时间
上次更新: 2025/06/04, 15:06:15
运用学过的设计原则和思想完善之前讲的性能计数器项目(下)
单例模式(中):我为什么不推荐使用单例模式?又有何替代方案?

← 运用学过的设计原则和思想完善之前讲的性能计数器项目(下) 单例模式(中):我为什么不推荐使用单例模式?又有何替代方案?→

最近更新
01
AIIDE
03-07
02
githubActionCICD实战
03-07
03
windows安装Deep-Live-Cam教程
08-11
更多文章>
Theme by Vdoing
总访问量 次 | 总访客数 人
| Copyright © 2021-2025 ggball | 赣ICP备2021008769号-1
  • 跟随系统
  • 浅色模式
  • 深色模式
  • 阅读模式
×

评论

  • 评论 ssss
  • 回复
  • 评论 ssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss
  • 回复
  • 评论 ssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss
  • 回复
×