云溪的 blog
  • Archive
  • Media
  • Search
  • Tags
  • About

golang设计模式之单例模式

日常开发中经常会遇到单例模式的使用场景,单例模式可以保证我们初始化出来的结构体只有一个,在一些请求上下文,mysql 连接池..场景经常有着不可估量的作用。 在 golang 开发中,我们应当如何去设计单例模式呢? 常见的错误书写方式 相信如果你对 PHP 写的比较多的情况下经常会写出下面代码一样的单例模式 package main type Singleton struct { } var ins *Singleton func GetIns() *Singleton { if ins == nil { ins = &Singleton{} } return ins } 那上述代码,在正常开发存在什么样的问题呢?上述代码如果用于 PHP 项目是没有任何问题的,因为 PHP 本事是请求隔离的,因而也不会存在并发的问题,但是如果放在常驻内存类型的语言中就会出现并发性不安全问题。 接下来考虑一个场景,在高并发场景下,同时又两个业务都执行到 ins == nil 而此时的 ins 确实没有实例化,那程序将会如何执行呢?答案显而易见,两个业务都会实例化出自己的 ins 结构体,这显然不符合我们的程序预期。 如何解决 golang 标准库sync中找到了Once类型。它能保证某个操作仅且只执行一次。有了他我们就可以很方便的解决并发的问题了接下看看代码示例: package main import "sync" type Singleton struct { } var ins *Singleton var once sync.Once func GetIns() *Singleton { once.Do(func() { ins = &Singleton{} }) return ins } 这样就可以利用 go 语言的特性,比较方便的实现单例模式了 Conclusion 到此,golang 的单例模式就完成了,在 golang 的开发中,我们最常考虑的就是,并发安全问题,是需要我们经常考虑的问题,编程是一件非常复杂的事情,只有深入的了细节,又能把控的了全局,才可以在开发过程中无往不利。

June 19, 2021 · 1 min · 云溪

golang base64 编码与 PHP 输出不一致

最近开发中,将一个 php 算法,移植到 golang 中,发现 base64 算法生成的字符串不一致,经过排查发现是由于 ASCII 控制字符导致的原因,加下来看代码 <?php $asciiArr =[10, 187, 217, 12, 207, 183, 184, 231, 184, 149, 118, 151]; $str = ''; foreach ($asciiArr as $ascii) { $str .= chr($ascii); } echo base64_encode($str); 上述代码输出: CrvZDM+3uOe4lXaX package main import ( "encoding/base64" "fmt" ) func main() { res := []int{10, 187, 217, 12, 207, 183, 184, 231, 184, 149, 118, 151} var str string var b []byte for _, v := range res { str += string(v) b = append(b, byte(v)) } byteCode := base64.StdEncoding.EncodeToString([]byte(b)) strCode := base64.StdEncoding.EncodeToString([]byte(str)) fmt.Println("byteCode:", byteCode) fmt.Println("stringCode:", strCode) } 上述代码输出: byteCode: CrvZDM+3uOe4lXaX stringCode: CsK7w5kMw4/Ct8K4w6fCuMKVdsKX 由此可以看出,关于 ASCII 控制字符的转码,不可以用 string 转 byte 到 EncodeToString 方法,如果需要一致输出,需要直接用 []byte 接收值传入 EncodeToString 即可

June 16, 2021 · 1 min · 云溪

Godev  [draft]

June 15, 2021 · 0 min · 云溪

jenkins pipeline 环境变量详解

关于 Jenkins 的环境变量,可以分为系统内置环境变量和自定义环境变量。系统内置环境变量是 Jenkins 内部定义的环境变量。自定义环境变量是用户自己定义的环境变量 系统环境变量 jenkins 的内置环境变量的查看方式有两种,一种是通过 web url 地址查看,另一种是通过 shell 命令 printenv 查看 方式一:通过地址访问 直接在浏览器中访问 ${YOUR_JENKINS_HOST}/env-vars.html 页面就可以,比如 http://localhost:8080/env-vars.html ,每个变量的用途写的都很清楚 方式二:printenv 通过 shell 命令printenv 获取 pipeline { agent any stages { stage("Env Variables") { steps { sh "printenv" } } } } 通过执行上述 pipeline 的构建,就可以打印出系统内置的环境变量 自定义环境变量 在内置环境变量的基础上,有事我们也需要定义我们自己的的环境变量来方便开发和部署,自定义环境变量的设置分为三种,分别是:声明式,脚本式,内置函数式,接下来分别讲解一下三种方式各是如何设置的。 声明式 声明式定义结构如下: environment { key = value } 声明式可以在 pipeline 的任意阶段声明,看如下示例 pipeline { agent { label any } environment { //全局环境变量 NAME = "zhangsan" } stages { stage('Build') { environment { // 仅在 Build 阶段下有效的环境变量 NAME = "Andy" } steps { sh 'printenv' } } } } 脚本式 脚本式基本结构如下: ...

June 7, 2021 · 2 min · 云溪

nginx location 优先级

location 优先级介绍 location 匹配方式有以下几种 location = /path/a/exact.png {}: 精确匹配 location ^~ /path/a/ {}: 优先前缀匹配(符合最长匹配原则) location ~ /Path?/ {} : 区分大小写正则匹配(首次匹配原则) location ~* /path?/ {} : 不区分大小写正则匹配(首次匹配原则) location /path/a/test.png {} : 前缀匹配(符合最长匹配原则) location 优先级匹配与配置的先后顺序无关,优先级排列顺序如下 精确匹配 > 优先前缀匹配 > 区分大小写正则匹配=不区分大小写正则匹配 > 前缀匹配 实例说明 location = /path/a/exact.png { [ configuration A ] } location ~ /Path?/ { [ configuration B ] } location ~* /path?/ { [ configuration C ] } 如果理解了优先级,将很容易得出如下结论: www.web.com/path/a/exact.png => 匹配 configuration A www.web.com/Path/a => 匹配 configuration B www.web.com/path/a => 匹配 configuration C 当我们发现能够很好的猜测各种 URL 所匹配各个 location 是否心中有些许窃喜,对 location 优先级的理解已经不再话下了?事实并非如此,关于 location 优先级,还有一件事你需要知道。 ...

May 19, 2021 · 1 min · 云溪
« Prev  Next  »
© 2025 云溪的 blog