对《Go语言进阶与依赖管理》这门课记笔记：
1. Go语言进阶（协程）
1.0 并发 vs 并行
多线程在一个核上运行，时间片进行切换，达到一个并行的状态。
多线程在多个核CPU上运行，时间片重合了。
1.1 协程
线程还在内核状态，协程是在用户态下，协程小，线程大，协程并发好。
协程调用：在函数调用的加一个 “go” 关键字，为函数创新一个协程运行。
1.2 协程通信 两种方法：通过通信共享内存；通过共享内存实现通信（临界区） 提倡通过通信共享内存而不是通过共享内存实现通信。 通道：传输信息
1.3 channel 创建：make(channal 元素类型， [缓冲区大小]) 例子：无缓冲通道 make(chan int) 有缓冲通道 make(chan int, 2) 无缓冲通道时：导致发送和接受同步更新 有缓冲通道：通道可以存放相应大小的元素，可以不同步更新（类似生产者消费者模型） 例子：消费者中可以加入缓存区，来消除生产者生产速度过快导致生产者需要等待消费者的问题；
1.4 并发安全Lock 利用锁机制来进行并发安全控制，对加锁协程和不加锁协程进行五个协程并发执行时，不加锁的会有概率得到错误结果（未知），加锁后，会得到正常结果。
测试了一下：第一次未加锁的程序输出了6930，加锁的程序由于写错了，忘记Unlock了，导致只执行了一次，锁一直处于未开锁状态。后续再执行该程序时，未加锁的程序也执行了一万遍。
lock用来控制安全的访问临界区，在实际项目开发中，并发安全有概率引起问题，所以在项目开发中，避免对共享内存进行非并发安全的读写操作。
1.5 time.sleep Add(delta int) // 计数器 + delta Done() // 计数器 - 1 Wait() // 阻塞计数器，直到变为0 开启协程 计数器+1；执行结束协程 计数器 - 1； 主协程阻塞一直到计数器为0. 总结：协程开启时，利用add(总协程数), 每完成一个协程Done()，主程序调用Wait()
2. 依赖管理
利用已经开发好的开发组件和工具，提升开发效率。 后面的感觉有点难懂了...... Go依赖管理演进：GOPATH -> Go Vendor -> Go Module 2.1.1 GOPATH：Go语言支持的环境变量。Go项目工作区。 该目录下： bin：项目编译的二进制文件 pkg：项目编译产生的中间产物，加速编译 src：项目源码 弊端：无法实现package的多版本控制，项目A实现的函数，在项目B中被删掉，同时pkg版本得到了升级。
2.1.2 Go Vendor 项目增加Vendor文件，所有依赖包副本形式放在vendor中 解决了多个项目需要同一个package版本，依赖的冲突解决。 问题：项目A依赖项目B和项目C，项目B依赖D-v1，项目C依赖D-v2，D的v1和v2不兼容，导致依赖冲突。 vendor依赖项目源码
2.1.3 Go Module 解决了上述依赖管理系统的问题。 利用go.mod管理依赖包版本 利用go get/go mod 指令工具管理依赖包
2.3.1 依赖配置 - go.mod 依赖管理基本单元 ：project/app 原生库 ： go 版本 单元依赖：[Module Path][Version/Pseudo-version] 唯一定位一个仓库的某一版本或某次提交
2.3.2 依赖配置 - version 语义化版本 基于commit伪版本
2.3.3 依赖配置 - indirect（关键字） 对于没有直接导入的依赖模块，标识为非直接依赖，用indirect关键字标识
2.3.4 依赖配置 - incompatible （关键字） 主版本更新时，标识可能存在不兼容的代码逻辑
依赖图：
选B
选择最低的兼容版本
2.3.5 依赖分发 - 回源 依赖从哪下载：GitHub、SVN、... 直接下载会有问题：无法保证构建稳定性（依赖版本更新/修改/删除了) 无法保证依赖可用性（被删了） 增加第三方压力（代码托管平台负载问题） 解决：proxy，作为中间存储，保证依赖稳定
2.3.6 依赖分发：GOPROXY
GOPROXY = "proxy1.cn, proxy2.cn, direct" 依次从proxy1，proxy2查找依赖，如果两者都没有，最后会回源到第三方源站上。
2.3.7 工具 - go get 用法：
2.3.8 工具 - go mod
- 依赖管理三要素 配置文件，描述依赖 go.mod 中心仓库管理依赖库 Proxy 本地工具 go get/mod
