本文目录一览：
- 1、go语言无缓冲的channel
- 2、golang调用so库同步函数停止
- 3、Go语言WaitGroup使用时需要注意什么
- 4、Golang 语言深入理解：channel
- 5、golangaddint64作用
go语言无缓冲的channel
无缓冲的通道（unbuffered channel）是指在接收前没有能力保存任何值的通道。
这种类型的通道要求发送goroutine和接收goroutine同时准备好，才能完成发送和接收操作。否则，通道会导致先执行发送或接收操作的 goroutine 阻塞等待。
这种对通道进行发送和接收的交互行为本身就是同步的。其中任意一个操作都无法离开另一个操作单独存在。
阻塞：由于某种原因数据没有到达，当前协程（线程）持续处于等待状态，直到条件满足，才接触阻塞。
同步：在两个或多个协程（线程）间，保持数据内容一致性的机制。
下图展示两个 goroutine 如何利用无缓冲的通道来共享一个值：
在第 1 步，两个 goroutine 都到达通道，但哪个都没有开始执行发送或者接收。
在第 2 步，左侧的 goroutine 将它的手伸进了通道，这模拟了向通道发送数据的行为。这时，这个 goroutine 会在通道中被锁住，直到交换完成。
在第 3 步，右侧的 goroutine 将它的手放入通道，这模拟了从通道里接收数据。这个 goroutine 一样也会在通道中被锁住，直到交换完成。
在第 4 步和第 5 步，进行交换，并最终，在第 6 步，两个 goroutine 都将它们的手从通道里拿出来，这模拟了被锁住的 goroutine 得到释放。两个 goroutine 现在都可以去做别的事情了。
如果没有指定缓冲区容量，那么该通道就是同步的，因此会阻塞到发送者准备好发送和接收者准备好接收。
无缓冲channel： —— 同步通信
golang调用so库同步函数停止
测试动态库步骤：
1、test_so.h
2、test_so.c
3、生成so
4、复制so文件到Go项目目录
Go项目目录
1、load_so.h
2、load_so.c
3、test.go
4、Go项目目录要放在$GOPATH/src/目录下，这也是正常操作。
test目录为Go项目，里边是上述创建的所有源码文件。
在$GOPATH/src/test/里直接使用gobuild编译生成test二进制文件，此处需要注意执行路径。
问题
1、/**/注释的代码下一行一定是import“C”，中间不能有空行
2、importC必须单独一行，不能和其它库一起导入
3、有人编译的时候会报错：
这个主要是执行目录问题，一定要在$GOPATH/src/项目/目录下，用gobuild执行，gobuild后边不要有任何文件名。
或者用gorun.运行，或者goruntest，test是项目名。不能用goruntest.go。
4、还有人报这个错：test.go文件里的cgoLDFLAGS:-ldl这一行不要删掉。
Go语言WaitGroup使用时需要注意什么
WaitGroup在go语言中，用于线程同步，单从字面意思理解，wait等待的意思，group组、团队的意思，WaitGroup就是指等待一组，等待一个系列执行完成后才会继续向下执行。Golang 中的 WaitGroup 一直是同步 goroutine 的推荐实践。自己用了两年多也没遇到过什么问题。
直到最近的一天同事扔过来一段奇怪的代码：
好了，到这里终于解决了，以上就是关于Go语言WaitGroup使用时需要注意的一些坑，希望本文中提到的这些问题对大家学习或者使用Go语言的时候能有所帮助，如果有疑问大家可以留言交流。
Golang 语言深入理解：channel
本文是对 Gopher 2017 中一个非常好的 Talk�: [Understanding Channel](GopherCon 2017: Kavya Joshi - Understanding Channels) 的学习笔记，希望能够通过对 channel 的关键特性的理解，进一步掌握其用法细节以及 Golang 语言设计哲学的管窥蠡测。
channel 是可以让一个 goroutine 发送特定值到另一个 gouroutine 的通信机制。
原生的 channel 是没有缓存的(unbuffered channel)，可以用于 goroutine 之间实现同步。
关闭后不能再写入，可以读取直到 channel 中再没有数据，并返回元素类型的零值。
gopl/ch3/netcat3
首先从 channel 是怎么被创建的开始:
在 heap 上分配一个 hchan 类型的对象，并将其初始化，然后返回一个指向这个 hchan 对象的指针。
理解了 channel 的数据结构实现，现在转到 channel 的两个最基本方法: sends 和 receivces ，看一下以上的特性是如何体现在 sends 和 receives 中的:
假设发送方先启动，执行 ch - task0 :
如此为 channel 带来了 goroutine-safe 的特性。
在这样的模型里， sender goroutine - channel - receiver goroutine 之间， hchan 是唯一的共享内存，而这个唯一的共享内存又通过 mutex 来确保 goroutine-safe ，所有在队列中的内容都只是副本。
这便是著名的 golang 并发原则的体现:
发送方 goroutine 会阻塞，暂停，并在收到 receive 后才恢复。
goroutine 是一种 用户态线程 , 由 Go runtime 创建并管理，而不是操作系统，比起操作系统线程来说，goroutine更加轻量。
Go runtime scheduler 负责将 goroutine 调度到操作系统线程上。
runtime scheduler 怎么将 goroutine 调度到操作系统线程上？
当阻塞发生时，一次 goroutine 上下文切换的全过程:
然而，被阻塞的 goroutine 怎么恢复过来？
阻塞发生时，调用 runtime sheduler 执行 gopark 之前，G1 会创建一个 sudog ，并将它存放在 hchan 的 sendq 中。 sudog 中便记录了即将被阻塞的 goroutine G1 ，以及它要发送的数据元素 task4 等等。
接收方 将通过这个 sudog 来恢复 G1
接收方 G2 接收数据, 并发出一个 receivce ，将 G1 置为 runnable :
同样的, 接收方 G2 会被阻塞，G2 会创建 sudoq ，存放在 recvq ，基本过程和发送方阻塞一样。
不同的是，发送方 G1如何恢复接收方 G2，这是一个非常神奇的实现。
理论上可以将 task 入队，然后恢复 G2, 但恢复 G2后，G2会做什么呢？
G2会将队列中的 task 复制出来，放到自己的 memory 中，基于这个思路，G1在这个时候，直接将 task 写到 G2的 stack memory 中！
这是违反常规的操作，理论上 goroutine 之间的 stack 是相互独立的，只有在运行时可以执行这样的操作。
这么做纯粹是出于性能优化的考虑，原来的步骤是：
优化后，相当于减少了 G2 获取锁并且执行 memcopy 的性能消耗。
channel 设计背后的思想可以理解为 simplicity 和 performance 之间权衡抉择，具体如下：
queue with a lock prefered to lock-free implementation:
比起完全 lock-free 的实现，使用锁的队列实现更简单，容易实现
golangaddint64作用
在Go语言中，原子包提供lower-level原子内存，这对实现同步算法很有帮助。Go语言的AddInt64（）函数用于将增量自动添加到*addr。此函数在原子包下定义。在这里，您需要导入sync/atomic软件包才能使用这些函数。
用法：funcAddInt64(addr*int64,deltaint64)(newint64)；
在此，addr表示地址，而delta表示少量大于零的位。
注意：（*int64）是指向int64值的指针。此外，int64包含从-9223372036854775808到9223372036854775807的所有带符号的64位整数的集合。
返回值：它自动添加addr和delta并返回一个新值。
我们定义了一个add函数，该函数返回调用AddInt64方法返回的输出。在主函数中，我们定义了一个for循环，该循环将在每个调用中增加's'的值。在这里，AddInt64（）方法的第二个参数是恒定的，只有第一个参数的值是可变的。但是，上一个调用的输出将是下一个调用中AddInt64（）方法的第一个参数的值，直到循环停止为止。
