谈谈Go语言的字符串设计

摘要： 本文来自：http://www.ttkmwl.com 最给力的程序源码下载论坛 -通天源码论坛 『问题描述』 那天有用户向我反馈在使用 GoJieba 的过程中发现内存泄露的Bug。 具体现象就是这个测试代码 test.go 跑着跑着内存一直增长。

本文来自：http://www.ttkmwl.com 最给力的程序源码下载论坛 -通天源码论坛

 

『问题描述』

那天有用户向我反馈在使用 GoJieba 的过程中发现内存泄露的Bug。 具体现象就是这个测试代码 test.go 跑着跑着内存一直增长。 刚开始以为是代码里面的C语言部分内存没有正确释放导致的， 查了很久一直没有找到问题所在。

最后发现这个Bug非常白痴，是因为 C.CString 使用不当导致的。 在调用了 C.CString 之后需要手动释放内存。 这个Bug非常白痴，但是却反映了我之前对Go语言string理解不彻底的隐患。 才导致在我第一眼看到 C.CString 的时候， 就下意识的认为这个函数肯定没有动态申请新的内存， 和 C++ string::c_str() 一样，复用了内存。 所以也就肯定不需要手动释放。 当然这些只是『我以为』。

『问题深扒』

C语言和Go语言本是同根生嘛， 所以Go语言在设计的时候就通过cgo对C语言调用支持得很好。 而Go语言和C语言之间的数据转换就是通过 C.CString (Go->C), C.GoString(C->Go) 来进行的。

先谈谈 C.GoString ，很显然当使用 C.GoString 的时候， 会复制C语言的*char指针指向的字符串的内容拷贝到Go语言的string管理的内存空间。 Go语言的string管理的内存空间有gc管理，不需要用户主动释放内存。 也就是不需要管它。

而 C.CString 将 Go语言 string 转换成 C语言字符串的时候。 我们就要谈谈为什么它不会像 C++ 的 string::c_str() 一样只是单纯的共用内存了。

本质原因在于对于 Go 来说， string 和 C语言最大的不同是: 在C语言中，字符串是以 ’\0’ 结尾。 其实我认为这个本身是一种历史遗留问题。

『C语言的字符串主要有两种存储方式可选』

比如一个 “hello” 的字符串。 我们在内存中表示可以有两种选择：

第一种：

"hello\0"

第二种：

1 2 3 4

typedef struct {     char* buffer;     size_t len; } string;

 

C语言默认的字符串选择了第一种方式， 我认为主要原因在于当年C语言发明的时候是内存和稀缺的时代。 第一种方式比第二种方式显然更省内存。

但是随着时代的发展，内存越来越便宜。内存已经越来越不是程序开发的瓶颈。 第二种方式越来越成为字符串设计的首选。 比如在Nginx之类的著名开源项目中，也是采用了第二种方式对字符串进行存储。

而第二种方式更受青睐的主要原因我认为有两点:

『1. 更好的内存共享』

比如有一个字符串s1 = “hello world” ， 而有两种字符串s2 s3 分别是 s1 的子串："hello", “world” . 当我们使用第二种方式存储字符串的时候， 我们对于s2 s3就直接复用 s1的内存即可。 无需动态分配和释放，这样的场景在协议解析，比如HTTP包头的场景下特别常用。

而假设我们使用第一种方式存储字符串的话， 那么 s1 = “hello world\0”, s2 = “hello\0”, 虽然 s2 是 s1 的子串，但是因为 “\0” 结尾符的存在， s2 就无法复用 s1 的内存，而是需要新申请一段新的内存。 这也是为什么在Go语言中， C.CString 函数返回的内存肯定是一段新的内存， 也就不得不要求调用者手动释放。

『2. 性能更高,获取长度不再是strlen这种O(N)时间复杂度的函数』

这点就比较显而易见了。

​​​​​​​

原文链接