Go语言入门 | 青训营笔记这是我参与「第三届青训营 -后端场」笔记创作活动的的第2篇笔记 channel golang

这是我参与「第三届青训营 -后端场」笔记创作活动的的第2篇笔记

channel

golang通过通信共享内存。

func main() {
   src := make(chan int)
   dest := make(chan int, 3)
    
    //暂且称为协程A
   go func() {
      defer close(src)
      for i := 0; i < 10; i++ {
         src <- i
      }
   }()

    //暂且称为协程B
   go func() {
      defer close(dest)
      for i := range src {
         dest <- i * i
      }
   }()

   for i := range dest {
      fmt.Println(i)
   }
}

执行的结果：

主协程main中开启了两个协程AB，两个协程之间的通信使用的是无缓冲区的channel，是同步通信的，A往src放入一个元素，阻塞，等待B从src中取出元素。AB是相互阻塞的。 B从src中取出元素，处理之后将处理后的结果放入dest中，如果这个时候dest是满的，B就会阻塞，同理，如果缓冲区是空的，主协程就会阻塞等待数据。

Sync.WaitGroup

Add(): 计数器+delta
Done()：计数器-1
Wait()：主协程阻塞直到计算器为0

依赖管理

GOPATH -> GO Vender -> Go Module

GOPATH

bin: 项目编译的二进制文件
pkg：项目编译的中间产物，加速编译
src：项目的源码

项目代码直接依赖src下的代码，go get下载的所有依赖都存放到src目录下面。

存在的弊端：

无法实现包的多版本控制

GOPATH下面存放所有的依赖包，如果项目A和项目B依赖于不同版本的package，同时该package又没有做到完全的向前兼容，往往会导致一些问题。

Go Vender

其实就是在每个项目增加一个vendor文件夹，所有依赖副本存放在这里。

寻址方式：首先去vendor下面寻找，没有的话去GOPATH

这样解决了多个项目需要同一个package依赖的冲突问题

但是，还是无法控制依赖的版本，更新项目可能出现以来冲突，导致编译出错

packageB和packageD同时依赖packageD，但是依赖的是不同的版本，这样就会出现问题。

以上两种依赖的管理方式，归根结底，都是依赖于源码，不能清晰的标识依赖的版本，就会出现问题

Go Module

通过go.mod文件管理依赖包版本，通过go get/go mod指令工具管理依赖包。

终极目标：定义版本规则和管理项目依赖关系。

依赖管理三要素：

配置文件，描述依赖 go.mod
中心仓库管理依赖库 Proxy
本地工具 go get/mod

依赖标识： [Module Path][Version/Pseudo-version]

版本version

版本语义-时间戳(提交的时间戳)-哈希的编码

indirect

A->B->C

A与B是直接依赖
A与C是间接依赖

在执行命令go mod tidy时，Go module 会自动整理go.mod 文件，如果有必要会在部分依赖包的后面增加// indirect注释。一般而言，被添加注释的包肯定是间接依赖的包，而没有添加// indirect注释的包则是直接依赖的包，即明确的出现在某个import语句中。

然而，这里需要着重强调的是：并不是所有的间接依赖都会出现在 go.mod文件中。

间接依赖出现在go.mod文件的情况，可能符合下面所列场景的一种或多种：