做网站论坛 前置许可,wordpress 自定义栏目 删除,wordpress 在线人数,iis网站子目录设置二级域名1.0 从并发编程本质了解Go高性能的本质 1.1 Goroutine 协程可以理解为轻量级线程#xff1b; Go更适合高并发场景原因之一#xff1a;Go语言一次可以创建上万协成#xff1b; “快速”#xff1a;开多个协成 打印。 go func(): 在函数前加 go 代表 创建协程; time.Sleep():… 1.0 从并发编程本质了解Go高性能的本质 1.1 Goroutine 协程可以理解为轻量级线程 Go更适合高并发场景原因之一Go语言一次可以创建上万协成 “快速”开多个协成 打印。 go func(): 在函数前加 go 代表 创建协程; time.Sleep(): 协程阻塞使主协程 在子协程结束前阻塞不退出 乱序输出 说明并行 1.2 协程通信 CSP (Communicating Sequential Processes) 通过通信共享内存Channel通道遵循 先入先出 保证顺序 1.3Channel Channel创建需要通过make()函数 无缓冲通道也称 同步通道有缓冲缓冲满了之后要拿走才能存。 通过通信共享内存 例子 M主函数作为消费者 实际中业务比较复杂所以会 比 生产者AB慢我们用 带缓冲的通道 就不会因消费者M的消费速度 影响 生产者的执行效率; 1.4 并发安全Lock addWithLock() 通过临界区控制实现在 每次 x1前后加解锁 addWithOutLock() 没加锁 Add 测试函数对两种实现做5个协程并发执行 结果为加锁时输出预期结果10000体现不加锁的并发安全问题 1.5 WaitGroup实现并发任务的同步 计算器0表示所有并发任务结束 1.5.1阻塞的优化 好的以上就是对go并发编程相关概念的介绍这里简单做个小结 整个章节主要涉及3个方面一个是协程通过高效的调度模型实现高并发操作一个是通道channel.通过通信实现共享内存;最后svnc相关关键字实现并发安全操作和协程间的同步 2.0 依赖管理 这一章我们主要讲解go的依赖管理 主要涉及go依赖管理的演进路线和go module实践 依赖指各种开发包 对于hello world以及类似的单体函数只需要依赖原生SDK而实际工程会相对复杂我们不可能基于标准库0~1编码搭建而更多的关注业务逻辑的实现而其他的涉及框架、日志、driver、以及collection等一系列依赖都会通过sdk的方式引入 这样对依赖包的管理就显得尤为重要 2.1 Go依赖管理演进 2.1.1 GoPATH GOPATH是Go语言支持的一个环境变量value是Go项目的工作区。 目录有以下结构: src: 存放Go项目的源码pkg: 存放编译的中间产物加快编译速度; bin: 存放Go项目编译生成的二进制文件 大家想想用gopath依赖管理有 哪些弊端呢? 弊端 如图同一个pkg有2个版本A- A0,B- B0. 而src下只能有1个版本存在那AB项目无法保证都能编译通过。 也就是在gopath管理模式下如果多个项目依赖同一个库则依赖该库是同一份代码所以不同项目不能依赖同一个库的不同版本这很显然不能满足我们的项目依赖需求。为了解决这问题govender出现了 2.1.2 GoVendor Vendor是当前项目中的一个目录其中存放了当前项目依赖的副本在Vendor机制下如果当前项目存在Vendor目录会优先使用该目录下的依赖如果依赖不存在会从GOPATH中寻找。 vendor无法很好解决依赖包的版本变动问题和一个项目依赖同一个包的不同版本的问题下面我们看一个场景 如图项目A依赖pkg b和c而B和C依赖了D的不同版本通过vendor的管理模式我们不能很好的控制对于D的依赖版本一旦更新项目有可能带来依赖冲突。 归根结底vendor不能清晰的标识依赖的版本概念原因是他还是依赖源码。 下面go mod就应运而生了。 2.1.3 Go Module Go Modules 是Go语言官方推出的依赖管理系统解决了之前依赖管理系统存在的诸如无法依赖同一个库的多个版本等问题 G0 module从1.11 开始实验性引入1.16 默认开启;我们一般都读为go mod我们也先统一下名称 2.2 依赖管理三要素 那其实完善的依赖管理一般都需要3要素这里我们先整体介绍下 这里熟悉java的同学可以类比下maven 2.3.1 依赖配置-go.mod 首先模块路径(依赖管理基本单元)用来标识一个模块从模块路径可以看出从哪里找到该模块如果是github前缀则表示可以从Github 仓库找到该模块依赖包的源代码由githu托管如果项目的子包想被单独引用则需要通过单独的go.mod文件进行管理。 下面是依赖的原生库sdk版本go 1.16 最下面是单元依赖(最关键的部分)每个依赖单元用模块路径(跟上面的对应)版本来唯一标示。 2.3.2 依赖配置-version gopath和govendor都是源码副本方式依赖没有版本规则概念 而gmod为了方便版本管理 定义了版本规则分为语义化版本和伪版本 其中语义化版本包括三部分 不同的MAJOR大版本可以表示是不兼容的 所以即使是同一个库MAJOR 版本不同也会被认为是不同的模块 MINOR版本通常是新增函数或功能,需要保持在MAJOR下做到前后兼容 patch 版本一般是修复 bug ; 基于commit的伪版本包括3部分 版本前缀是和语义化版本一样的; 时间戳 yyyymmddhhmmss,也就是提交commit的时间 最后是校验码(abcdefabcdef,包含 12 位的哈希前缀;每次提交commit后 Go 会默认生成一个伪版本号 2.3.3 依赖配置-非直接依赖indirect 下面我们再来看下依赖单元中的特殊标识符首先是indirect后缀 表示go.mod对应的当前模块没有直接导入该依赖模块的包也就是非直接依赖标示间接依赖例如 2.3.4 依赖配置-incompatible 下一个常见是的是incompatible 主版本2模块(v2以上) 会在模块路径增加/vN(v1,v2这种后缀)这让gomod按照不同的模块来处理同一个项目不同主版本的依赖允许不同MAJOR版本间相互兼容) 由于gomod是1.11实验性引入所以这项提出之前已经有一些仓库打上了v2或者更高版本的tag了为了兼容这部分仓库对于没有go.mod文件并且主版本在2或者以上的依赖会在版本号后加上incompatible 后缀 前面讲语义化版本提到对于同一个库的不同的major版本需要建立不同的pkg目录用不同的gomod文件管理 如下面仓库为例V1版本gomod在主目录下而对于V2版本则单独建立了V2目录用另一个gomod文件管理依赖路径来表明不同major的不兼容性。 那对于有些V2tag版本的依赖包并未遵循这定义规则就会打上incompatible标志增加一个compatile的case 依赖图 答案竟然是B Go底层会根据自己的算法 选择最 低的兼容版本 2.3.5 依赖分发-回源 gomodule的依赖分发,也就是从哪里下载如何下载的问题 github是比较常见给的代码托管系统平台而Go Modules 系统中定义的依赖最终可以对应到多版本代码管理系统中某一项目的特定提交或版本这样的话对于go.mod中定义的依赖则直接可以从对应仓库中下载指定软件依赖从而完成依赖分发。 但直接使用版本管理仓库下载依赖存在多个问题 首先无法保证构建确定性:软件作者可以直接码平台增加/修改/删除 软件版本导致下次构建使用另外版本的依赖或者找不到依赖版本。 无法保证依赖可用性:依赖软件作者可以直接代码平台删除软件导致依赖不可用;大幅增加第三方代码托管平台压力。 2.3.5 依赖分发-Proxy 而go proxy就是解决这些问题的方案Go Proxy 是一个服务站点 它会缓存源站中的软件内容缓存的软件版本不会改变并且在源站软件删除之后依然可用从而实现了供“immutability”和“available”的依赖分发 使用 Go Proxy 之后构建时会直接从 Go Proxy 站点拉取依赖。 类比项目中如果下游无法满足我们上游的需求、接口我们可以建一层适配器或Proxy解决 2.3.6 依赖分发-变量-GOPROXY 下面讲一下go proxy的使用Go Modules通过GOPROXY环境变量控制如何使用 Go ProxyGOPROXY是一个Proxy 站点URL列表可以使用 “direct”表示源站 用逗号分隔。 对于示例配置整体的依赖寻址路径会优先从proxy1下载依赖如果proxy1不存在后下钻proxy2寻找如果proxy2中不存在则会回源到源站直接下载依赖缓存到proxy站点中。 2.3.7 工具-go get 对go module的管理工具介绍下使用首先是go get 2.3.8 工具-go mod go mod尽量提交之前执行下go tidy减少构建时无效依赖包的拉取 非常感谢您阅读到这里如果这篇文章对您有帮助希望能留下您的点赞 关注 收藏 评论感谢支持
