【设计模式】单例模式|最常用的设计模式

这篇具有很好参考价值的文章主要介绍了【设计模式】单例模式|最常用的设计模式。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

写在前面

单例模式是最常用的设计模式之一,虽然简单,但是还是有一些小坑点需要注意。本文介绍单例模式并使用go语言实现一遍单例模式。

单例模式介绍

简介

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

使用场景:

  1. 当类只能有一个实例而且可以从一个公开的众所周知的访问点访问它。
  2. 当这个唯一实例是通过子类化可扩展的,并且应该无须更改单例代码就能使用一个扩展的实例。

结构图
【设计模式】单例模式|最常用的设计模式,遇见Golang,拥抱未来,设计模式,单例模式

分类

单例里面分成了两种模式,一种是饿汉式,一种是懒汉式。

饿汉式

饿汉模式下的单例,只在使用实例的时候就创建了对象。
代码实例:

var req *Request

type Request struct {
}

func NewRequest() *Request {
	if req == nil {
		req = new(Request)
	}
	return req
}

这个代码看起来没什么问题,但是这段代码是线程不安全的。 因为如果有多个请求过来,就会同时创建多个对象,就会出现频繁的创建和删除对象,给gc造成很大的压力。

当然我们也可以加锁,但是频繁的加锁,解锁会严重影响系统的性能。

var req *Request
var lock sync.Mutex

type Request struct {
}

func NewRequest() *Request {
	lock.Lock()
	defer lock.Unlock()
	if req == nil {
		req = new(Request)
	}
	return req
}

每一个对象的创建,都需要加锁解锁,非常影响性能

懒汉式

懒汉式的单例模式可以解决我们饿汉式的缺点,并且是线程安全的,保证了我们对象全局唯一并且不会重复创建。

代码如下:

var req *Request
var reqOnce sync.Once

type Request struct {
}

func NewRequest() *Request {
	reqOnce.Do(func() {
		req = &Request{}
	})

	return req
}

这里我们用到go语言的 sync.Once 包,而sync.Once的作用就是使得我们的函数只执行一次。并且是并发安全的。

那为什么是并发安全的呢?接下来我们详解一下 sync.Once

sync.Once

sync.once 内部原理很简单,Once的结构题如下:

type Once struct {
    // done变量用来标识函数是否执行完毕
    done uint32
    // m用来保证函数执行期间,其他goroutine阻塞
    m    Mutex
}

这个Do方法是判断有无执行过这个该方法,并且是使用atomic.LoadUint32的原子操作。

func (o *Once) Do(f func()) {
    // 1.判断函数是否执行过,done=0说明没执行过
    if atomic.LoadUint32(&o.done) == 0 {
        o.doSlow(f)
    }
}
  1. 如果没执行过就执行这个方法,那么这里会有一个double check的工作,其实就是防止可能在上一次检查到这一次加锁加完的时间段间隙上有人执行完了这个函数

  2. 确认确实没有执行的时候,就执行函数,并进行原子操作标识,将 done 置为1。

func (o *Once) doSlow(f func()) {
    // 1.加锁
    o.m.Lock()
    // 5.函数返回后,释放锁
    defer o.m.Unlock()
    // 2.判断是否执行过
    if o.done == 0 {
        // 4.函数返回后,设置执行标识
        defer atomic.StoreUint32(&o.done, 1)
        // 3.具体执行函数
        f()
    }
}

应用场景举例子

我们可以在 service 上定义某一个方法的结构体函数,并将可以根据这个结构体函数进行方法的扩展。
【设计模式】单例模式|最常用的设计模式,遇见Golang,拥抱未来,设计模式,单例模式
在controll层只需要调用这个函数方法即可GetUserSrv()文章来源地址https://www.toymoban.com/news/detail-861684.html

到了这里,关于【设计模式】单例模式|最常用的设计模式的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 设计模式学习(一)单例模式补充——单例模式析构

    目录 前言 无法调用析构函数的原因 改进方法 内嵌回收类 智能指针 局部静态变量 参考文章 在《单例模式学习》中提到了,在单例对象是通过 new 动态分配在堆上的情况下,当程序退出时,不会通过C++的RAII机制自动调用其析构函数。本文讨论一下这种现象的原因以及

    2024年03月19日
    浏览(20)
  • 设计模式之单例设计模式

    就是一个类只允许创建一个对象,那么我们称该类为单例类,这种设计模式我们称为单例模式。 资源共享:有些类拥有共享的资源,例如数据库连接池、线程池、缓存等。使用单例模式确保只有一个实例,避免资源浪费和竞争条件。 线程安全:单例模式可以用来保证多线程

    2024年02月07日
    浏览(21)
  • 设计模式-单例模式

          单例模式(Singleton Pattern)是设计模式中最简单且最常用的一种创建型模式,其目的是保证一个类在整个系统中只存在一个实例,并提供全局访问点来获取这个唯一实例。这种模式主要适用于那些需要频繁实例化然后又希望避免因为多次实例化而消耗过多资源或产生副

    2024年01月17日
    浏览(17)
  • 设计模式 ~ 单例模式

    单例模式:指在确保一个类只有一个实例,创建之后缓存以便继续使用,并提供一个全局访问点来访问该实例; 前端对于单例模式不常用,但对于单例的思想无处不在; 如:弹窗、遮罩层、登录框、vuex redux 中的 store; 闭包: 模块化:

    2024年02月16日
    浏览(20)
  • 设计模式——单例模式

    确保某一个类只有一个实例,而且自行实例化并向整个系统提供这个实例。 即保证一个类只有一个实例,并且提供一个全局访问点 优点 单例对象在内存中只有一个实例,减少了内存的开支。尤其对于一个频繁创建、销毁的对象时,单例模式的优势就更明显。 减少系统的性能

    2024年02月16日
    浏览(13)
  • 设计模式(单例模式)

            保证指定的类只有一个实例,不能创建出其他的实例                 1.1 代码展示                 1.2 Singleton类中instance对象的创建时机                 Singleton类中instance对象的创建时机:在Singleton类被jvm加载的时候创建,Singleton类会在第一次使用的时

    2024年02月15日
    浏览(11)
  • 【设计模式-单例模式】

    在一个项目中的全局范围内, 一个类 有且仅有一个实例对象 。这个唯一的实例对象给其他模块提供数据的 全局访问 。这样的模式就叫 单例模式 。 单例模式的典型例子就是任务队列。 首先, 考虑单例模式的要求为有且仅有一个实例对象。那么就先从构造函数入手。类的构

    2024年02月13日
    浏览(17)
  • 设计模式一:单例模式

    1、单例模式的实现方式 2、spring中的单例实现方式 spring中的单例不是线程安全的,当涉及到共享数据时需要记性多线程安全性的处理

    2024年02月20日
    浏览(12)
  • 设计模式 : 单例模式笔记

    一个类 只能创建一个对象 ,这样的类的设计模式就称为单例模式,该模式保证 系统中 该类 只能有一个实例 (并且 父子进程共享 ),一个很典型的单例类就是C++STL的内存池 C++单例模式的基本设计思路: 私有化 构造函数 ,删除默认的 拷贝构造函数 和 赋值运算符重载 防止对象被直

    2024年02月12日
    浏览(12)
  • 设计模式-单例模式进阶

    在前面的文章(设计模式-单例模式)中,我们分别介绍了四种单例设计模式,包括 普通恶汉式单例、双重检查锁单例(DCL)、静态内部类单例以及枚举单例 。但是,这四种模式还有一些 问题 我们没有仔细分析,以至于我们无法深入分析他们的优点以及可能存在的问题,更无法确

    2024年02月16日
    浏览(11)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包