Go bytes.Buffer 是线程安全的吗？答案

【问题标题】：Is the Go bytes.Buffer thread-safe?Go bytes.Buffer 是线程安全的吗？
【发布时间】：2013-11-07 22:17:45
【问题描述】：

在 Go 编程语言中，bytes.Buffer 是线程安全的吗？ AFAIK，its documentation 没有提到线程安全。

【问题讨论】：

标签： go

【解决方案1】：

使用io.Pipe() 函数调用，它提供一对连接对象（*PipeReader，*PipeWriter）用于同步读/写。这可以并行完成，并且是线程安全的。

【讨论】：

为这个答案投票！
如果你能展示一些代码就好了。对于像我这样的新手来说，“使用io.Pipe()”是一个很好的起点，但还有很多工作要做。

【解决方案2】：

不 - 但您可以轻松地将其包装在线程安全结构中！

对于简单的事情：

type Buffer struct {
    b bytes.Buffer
    m sync.Mutex
}
func (b *Buffer) Read(p []byte) (n int, err error) {
    b.m.Lock()
    defer b.m.Unlock()
    return b.b.Read(p)
}
func (b *Buffer) Write(p []byte) (n int, err error) {
    b.m.Lock()
    defer b.m.Unlock()
    return b.b.Write(p)
}
func (b *Buffer) String() string {
    b.m.Lock()
    defer b.m.Unlock()
    return b.b.String()
}

..照常使用var buf Buffer等

想要更多 bytes.Buffer？随意挑选：

func (b *Buffer) Bytes() []byte {
    b.m.Lock()
    defer b.m.Unlock()
    return b.b.Bytes()
}
func (b *Buffer) Cap() int {
    b.m.Lock()
    defer b.m.Unlock()
    return b.b.Cap()
}
func (b *Buffer) Grow(n int) {
    b.m.Lock()
    defer b.m.Unlock()
    b.b.Grow(n)
}
func (b *Buffer) Len() int {
    b.m.Lock()
    defer b.m.Unlock()
    return b.b.Len()
}
func (b *Buffer) Next(n int) []byte {
    b.m.Lock()
    defer b.m.Unlock()
    return b.b.Next(n)
}
func (b *Buffer) ReadByte() (c byte, err error) {
    b.m.Lock()
    defer b.m.Unlock()
    return b.b.ReadByte()
}
func (b *Buffer) ReadBytes(delim byte) (line []byte, err error) {
    b.m.Lock()
    defer b.m.Unlock()
    return b.b.ReadBytes(delim)
}
func (b *Buffer) ReadFrom(r io.Reader) (n int64, err error) {
    b.m.Lock()
    defer b.m.Unlock()
    return b.b.ReadFrom(r)
}
func (b *Buffer) ReadRune() (r rune, size int, err error) {
    b.m.Lock()
    defer b.m.Unlock()
    return b.b.ReadRune()
}
func (b *Buffer) ReadString(delim byte) (line string, err error) {
    b.m.Lock()
    defer b.m.Unlock()
    return b.b.ReadString(delim)
}
func (b *Buffer) Reset() {
    b.m.Lock()
    defer b.m.Unlock()
    b.b.Reset()
}
func (b *Buffer) Truncate(n int) {
    b.m.Lock()
    defer b.m.Unlock()
    b.b.Truncate(n)
}
func (b *Buffer) UnreadByte() error {
    b.m.Lock()
    defer b.m.Unlock()
    return b.b.UnreadByte()
}
func (b *Buffer) UnreadRune() error {
    b.m.Lock()
    defer b.m.Unlock()
    return b.b.UnreadRune()
}
func (b *Buffer) WriteByte(c byte) error {
    b.m.Lock()
    defer b.m.Unlock()
    return b.b.WriteByte(c)
}
func (b *Buffer) WriteRune(r rune) (n int, err error) {
    b.m.Lock()
    defer b.m.Unlock()
    return b.b.WriteRune(r)
}
func (b *Buffer) WriteString(s string) (n int, err error) {
    b.m.Lock()
    defer b.m.Unlock()
    return b.b.WriteString(s)
}
func (b *Buffer) WriteTo(w io.Writer) (n int64, err error) {
    b.m.Lock()
    defer b.m.Unlock()
    return b.b.WriteTo(w)
}

【讨论】：

@xiaoyi 为什么选择 rwmux？
@JackTuck 我的最新评论是maybe rwmux?。 bytes.Buffer 实际上更改了Read() 中的数据，因此即使使用 rwmux，也必须使用写锁。但是，如果使用不同的 Buffer 实现，使用 rwmux 可能会增加吞吐量。
恕我直言，恕我直言，互斥锁/锁的使用本身就是违反 CSP 范式的，不是吗？ CSP 是 Go 语言的基础，不是吗？

【解决方案3】：

没有。

Go 文档遵循一个简单的规则：如果没有明确声明并发访问某物是安全的，则不是。

【讨论】：

只是好奇，该规则是否记录在某处？
@Ztyx 有时直接查看源代码会更直接，我们很容易发现 bufio Read/Write 周围没有锁定操作