ch2-04: 完善内存模型部分内容

ch2-cgo/ch2-04-memory.md

@@ -42,9 +42,80 @@ func main() {
 
 因为C语言内存空间是稳定的，基于C语言内存构造的切片也是绝对稳定的，不会因为Go语言栈的变化而被移动。
 
-
 ## C临时访问传入的Go内存
 
+cgo之所以存在的一大因素是要继承C/C++语言几十年的软件遗产。而C/C++很多库都是需要通过指针直接处理传入的内存数据的。因此cgo中也有很多需要将Go内存传入C语言函数的场景。
+
+假设一个极端场景：我们将一个Go语言内存传入了C语言函数后，该Go语言内存位于于另一个goroutinue的栈上。在C语言函数执行期间另一个goroutinue因为栈不足的原因发生了栈的扩展，也就是导致了原来的Go语言内存被移动到了新的位置。但是此时此刻C语言函数并不知道该Go语言内存已经移动了位置，仍然用之前的地址来操作该内存——也就是将导致内存越界。以上是一个推论（真实情况有些差异），也就是说C访问传入的Go内存可能是不安全的！
+
+当然有RPC远程远程过程调用的经验的用户可能会考虑通过完全传值的方式处理：借助C语言内存稳定的特性，在C语言空间先开辟同样大小的内存，然后将Go的内存填充到C的内存空间；返回的内存也是如此处理。下面的例子是这种思路的具体实现：
+
+```go
+package main
+
+/*
+void printString(const char* s) {
+	printf("%s", s);
+}
+*/
+import "C"
+
+func printString(s string) {
+	cs := C.CString(s)
+	defer C.free(unsafe.Pointer(cs))
+
+	C.printString(cs)
+}
+
+func main() {
+	s := "hello"
+	printString(s)
+}
+```
+
+需要将Go的字符串传入C语言时，先通过`C.CString`将Go语言字符串对应的内存数据复制到在C语言新创建的内存空间。上面例子的处理思路虽然时安全的，但是效率极其低下（因为要多次分配内存并逐个复制元素），同时也极其繁琐。
+
+为了简化并高效处理该场景向C语言传入Go语言内存，cgo针对该场景定义了专门的规则：在CGO调用的C语言函数返回前，cgo保证传入的Go语言内存在此期间不会发生移动，C语言函数可以大胆地使用Go语言的内存！
+
+根据新的规则我们可以直接传入Go字符串的内存：
+
+```go
+package main
+
+/*
+void printString(const char* s) {
+	printf("%s", s);
+}
+*/
+import "C"
+
+func printString(s string) {
+	C.printString((*C.char)(unsafe.Pointer(&s[0])))
+}
+
+func main() {
+	s := "hello"
+	printString(s)
+}
+```
+
+现在的处理方式更加直接，避免的分配额外的内存，完美的解决方案。
+
+任何完美的技术都有被滥用的时候，CGO的这种看似完美的规则也是存在隐患的。我们假设调用的C语言函数需要长时间运行，那么将会导致被他引用的Go语言内存在C语言返回前不能被移动，从而可能间接地导致这个Go内存栈对应的goroutine不能动态伸缩栈内存，也就是可能导致这个goroutine被阻塞。因此，在需要长时间运行的C语言函数（特别是在纯CPU运算之外，还可能因为需要等待其它的资源而需要不确定时间才能完成的函数），需要谨慎处理传入的Go语言内存。
+
+不过需要小心的是在取到Go内存时需要马上传入C语言函数，期间不能保存到临时变量后再间接传入C语言函数。因为，CGO只能保证在C函数调用之后被传入的Go语言内存不会发生移动，它并不能保证在传入C函数之前内存发送变化。
+
+以下代码是错误的：
+
+```go
+// 错误的代码
+tmp := uintptr(unsafe.Pointer(&x))
+pb := (*int16)(unsafe.Pointer(tmp))
+*pb = 42
+```
+
+因为tmp并不是指针类型，在它获取到Go对象地址之后x对象可能会被移动，但是因为不是指针类型不会被Go语言运行时通过更新新内存的地址。在非制作类型的tmp保持Go对象的地址，和在C语言环境保持Go对象的地址的效果是一样的：如果原始的Go对象内存发生了移动，Go语言运行时并不会同步更新它们。
+
 ## C长期持有Go指针对象
 
 TODO