Golang in buffer efficiently stitching strings and customizing thread safety buffer

This is a creation in Article, where the information may have evolved or changed.

The "+" can be used to merge strings in go, but this is very inefficient, and each time a merge is created, a new string must be traversed and copied once . The StringBuilder class (the most efficient, thread insecure) is provided in Java to address this problem. There is a similar mechanism in go that is buffer (thread insecure).

The following is the sample code:

package mainimport (    "bytes"    "fmt")func main() {    var buffer bytes.Buffer    for i := 0; i < 1000; i++ {        buffer.WriteString("a")    }    fmt.Println(buffer.String())}

Use bytes. Buffer to assemble the string without copying it, just put the added string at the end of the cache.

Buffer Why is thread unsafe?

The Go documentation follows a simple rule:if it's not explicitly stated this concurrent access to something is safe, it is not.

The go document follows a simple rule: if there is no explicit declaration that concurrent access to something is safe, it is not.

The following is the bytes.buffer part of the source code in Golang

A buffer is a variable-sized buffer of bytes with Read and Write methods.//the zero value for Buffer was an empty Buffe      R ready to Use.type Buffer struct {buf []byte//Contents is the bytes Buf[off:len (BUF)] off int Read at &buf[off], "Write at &buf[len (BUF)" Bootstrap [64]byte//memory to hold first slice;    Helps small buffers avoid allocation. Lastread READOP//Last read operation, so this unread* can work correctly.} Write appends the contents of p to the buffer, growing the buffer as//needed. The return value n is the length of p; Err is always nil.     If the//buffer becomes too large, write would panic with Errtoolarge.func (b *buffer) write (P []byte) (n int, err error) { B.lastread = opinvalid M: = B.grow (len (p)) return copy (b.buf[m:], p), nil}//Read reads the next len (p) Bytes fr Om the buffer or until the buffer//is drained. The return value n is the number of bytes read. If the//Buffer has no data to return, err is Io. EOF (unless Len (p) is zero);//Otherwise it is Nil.func (b *buffer) Read (P []byte) (n int, err error) {B.lastread = op        Invalid if B.off >= len (b.buf) {//Buffer is empty and reset to recover space. B.truncate (0) If Len (p) = = 0 {return} return 0, Io. EOF} n = Copy (P, B.buf[b.off:]) B.off + = N if n > 0 {b.lastread = opread} return}

The source code for the definition of buffer, there is no lock on the field, in the write and read functions also found no trace of the lock, so it conforms to the rule in the above mentioned document, that is, buffer concurrency is not secure .

How to customize the implementation of a concurrency-safe buffer

type Buffer struct {    b bytes.Buffer    rw sync.RWMutex}func (b *Buffer) Read(p []byte) (n int, err error) {    b.rw.RLock()    defer b.rw.RUnlock()    return b.b.Read(p)}func (b *Buffer) Write(p []byte) (n int, err error) {    b.rw.Lock()    defer b.rw.Unlock()    return b.b.Write(p)}

through the read-write lock, to solve the concurrent read and write problems , the above provides read and write functions, Pro, is not the Golang code concise and clear? Other functions can be golang on the basis of the buffer source of the self-realization

The difference between two types of locks

sync. Mutex (mutex)	sync. Rwmutex (read-write lock)
When a goroutine access, other goroutine can not access, ensure the synchronization of resources, avoid competition, but also reduce the performance	Non-write state: Multiple goroutine can read at the same time, a goroutine write, the other goroutine can not read or write, good performance