39 | bytes包与字节串操作（下）

文章中说：“如果当前内容容器的容量的一半，仍然大于或等于其现有长度再加上另需的字节数的和，cap(b.buf)/2 >= len(b.buf)+need”。 如果是这样的话，那说明还有很多的未使用的空间，起码有一半，那就不用扩容，直接追加就可以了。所以这里的代码是错的，源码(1.16.2)中是 n <= c/2-m ，即cap(b.buf) >= b.Len() + need，也就是未读字节长度 + 另需的字节数 小于等于容量的一半时，才会把未读字节copy到buf的头部，只有在未读字节较少的时候，才发生copy，如果有太多的未读字节，就不copy到头部了(费时)

老师，Buffer的Write，WriteString方法返回一个int，一个err，int是参数长度，err永远是nil，感觉这个返回没啥用啊。这么设计是为了实现某些接口么？

请问老师，用 bytes.Buffer 而不用字节切片是因为它有计数器和一些方法使得操作更方便，还有高效的扩容策略么。这么说对么？

老师你好，为什么我本地的src/runtime包下的stringtoslicebyte方法里面tmpBuf的默认长度是32。 所以文中例子，输出的容量是32

2023年了都，大佬还在看评论吗？写了4年go了总感觉差点意思，最近把郝大佬的文章翻出来每篇仔细阅读、做笔记、看源码，另外也在团队给大家分享golang的学习之路特别充实； 对stringtoslicebyte做了debug，没想到cap为8是这么来的 func stringtoslicebyte(buf *tmpBuf, s string) []byte { var b []byte if buf != nil && len(s) <= len(buf) { *buf = tmpBuf{} b = buf[:len(s)] } else { b = rawbyteslice(len(s))// bytes.Buffer 初始化 buf 为空，需要调用 rawbyteslice 初始化 slice } copy(b, s) return b } func rawbyteslice(size int) (b []byte) { cap := roundupsize(uintptr(size))// roundupsize 计算容量，重点关注这里 p := mallocgc(cap, nil, false)// 分配内存 if cap != uintptr(size) { memclrNoHeapPointers(add(p, uintptr(size)), cap-uintptr(size)) } *(*slice)(unsafe.Pointer(&b)) = slice{p, size, int(cap)} return } // Returns size of the memory block that mallocgc will allocate if you ask for the size. func roundupsize(size uintptr) uintptr { if size < _MaxSmallSize { if size <= smallSizeMax-8 { // 以大佬例子为例：contents := "ab" buffer1 := bytes.NewBufferString(contents)，size长度为2，肯定小于smallSizeMax-8 return uintptr(class_to_size[size_to_class8[divRoundUp(size, smallSizeDiv)]]) // divRoundUp 函数算出来 为1， size_to_class8[1]=1;class_to_size[1]=8返回的uintptr为8，这里做了一个约定类似于查表 } else { return uintptr(class_to_size[size_to_class128[divRoundUp(size-smallSizeMax, largeSizeDiv)]]) } } if size+_PageSize < size { return size } return alignUp(size, _PageSize) } // 这里算出来是1 func divRoundUp(n, a uintptr) uintptr { // a is generally a power of two. This will get inlined and // the compiler will optimize the division. return (n + a - 1) / a // (8+2-1)/ 8=1 }

contents := "ab" buffer1 := bytes.NewBufferString(contents) fmt.Printf("The capacity of new buffer with content %q: %d\n", contents, buffer1.Cap()) // 内容容器的容量：8 单独执行这段代码输出的结果是：The capacity of new buffer with content "ab": 32 请问是原因呢

如果当前内容容器的容量的一半，仍然大于或等于其现有长度再加上所需的字节数的和，即：cap(b.buf)/2 >= len(b.buf)+need 这边len(b.buf)用b.Len()似乎更准确？才是获取未读部分的实际长度

源码里给了推荐的构建方法 // To build strings more efficiently, see the strings.Builder type. func (b *Buffer) String() string { if b == nil { // Special case, useful in debugging. return "<nil>" } return string(b.buf[b.off:]) }

如果只看strings.Builder 和bytes.Buffer的String方法的话，strings.Builder 更高效一些。 我们可以直接查看两个String方法的源代码，其中strings.Builder String方法中 *(*string)(unsafe.Pointer(&b.buf)) 是直接取得buf的地址然后转换成string返回。 而bytes.Buffer的String方法是 string(b.buf[b.off:]) 对buf 进行切片操作,我认为这比直接取址要花费更多的时间。 测试函数: func BenchmarkStrings(b *testing.B) { str := strings.Builder{}/bytes.Buffer{} str.WriteString("test") for i := 0; i < b.N; i++ { str.String() } } 结果为 BenchmarkStrings-8 2000000000 0.66 ns/op BenchmarkBuffer-8 300000000 5.64 ns/op 所以strings.Builder的String方法更高效

https://github.com/golang/go/blob/master/src/strings/builder_test.go#L319-L366 发现最后的问题，Go 的标准库中，已经给出了相关的测试代码了。