Soalan temuduga Tricky Golang - Part Data Race

Berikut ialah satu lagi soalan temuduga semakan kod untuk anda. Soalan ini lebih maju daripada yang sebelumnya dan disasarkan kepada khalayak yang lebih senior. Masalahnya memerlukan pengetahuan tentang kepingan dan perkongsian data antara proses selari.

Jika anda tidak biasa dengan kepingan dan cara ia dibina, sila lihat artikel saya sebelum ini tentang Pengepala Slice

Apakah Perlumbaan Data?

Perlumbaan data berlaku apabila dua atau lebih utas (atau goroutin, dalam kes Go) mengakses memori yang dikongsi secara serentak dan sekurang-kurangnya satu daripada akses tersebut ialah operasi tulis. Jika tiada mekanisme penyegerakan yang betul (seperti kunci atau saluran) disediakan untuk mengurus akses, hasilnya boleh menjadi gelagat tidak dapat diramal, termasuk kerosakan data, keadaan tidak konsisten atau ranap sistem.

Pada dasarnya, perlumbaan data berlaku apabila:

• Dua atau lebih utas (atau goroutine) mengakses lokasi memori yang sama pada masa yang sama.
• Sekurang-kurangnya satu daripada utas (atau goroutine) sedang menulis untuk ingatan itu.
• Terdapat tiada penyegerakan untuk mengawal akses kepada memori itu.

Oleh sebab itu, urutan urutan atau gorout mengakses atau mengubah suai memori yang dikongsi tidak dapat diramalkan, yang membawa kepada tingkah laku bukan penentu yang boleh berbeza-beza antara larian.

     +----------------------+      +---------------------+
     | Thread A: Write      |      | Thread B: Read      |
     +----------------------+      +---------------------+
     | 1. Reads x           |      | 1. Reads x          |
     | 2. Adds 1 to x       |      |                     |
     | 3. Writes new value  |      |                     |
     +----------------------+      +---------------------+

                    Shared variable x
                    (Concurrent access without synchronization)

Di sini, Thread A sedang mengubah suai x (menulis kepadanya), manakala Thread B membacanya pada masa yang sama. Jika kedua-dua utas berjalan serentak dan tiada penyegerakan, Thread B boleh membaca x sebelum Thread A selesai mengemas kininya. Akibatnya, data mungkin tidak betul atau tidak konsisten.

Soalan: Salah seorang rakan sepasukan anda menyerahkan kod berikut untuk semakan kod. Sila semak kod dengan teliti dan kenal pasti sebarang isu yang berpotensi.
Dan di sini kod yang anda perlu semak:

package main  

import (  
    "bufio"  
    "bytes"
    "io"
    "math/rand"
    "time"
)  

func genData() []byte {  
    r := rand.New(rand.NewSource(time.Now().Unix()))  
    buffer := make([]byte, 512)  
    if _, err := r.Read(buffer); err != nil {  
       return nil  
    }  
    return buffer  
}  

func publish(input []byte, output chan<- []byte) {  
    reader := bytes.NewReader(input)  

    bufferSize := 8  
    buffer := make([]byte, bufferSize)  

    for {  
       n, err := reader.Read(buffer)  
       if err != nil || err == io.EOF {  
          return  
       }  
       if n == 0 {  
          break  
       }  
       output <- buffer[:n]  
    }  
}  

func consume(input []byte) {  
    scanner := bufio.NewScanner(bytes.NewReader(input))  
    for scanner.Scan() {  
       b := scanner.Bytes()  
       _ = b  
       // does the magic  
    }  
}  

func main() {  
    data := genData()  
    workersCount := 4  
    chunkChannel := make(chan []byte, workersCount)  

    for i := 0; i < workersCount; i++ {  
       go func() {  
          for chunk := range chunkChannel {  
             consume(chunk)  
          }  
       }()  
    }  

    publish(data, chunkChannel)  
    close(chunkChannel)  
}

Apa yang kita ada di sini?

Fungsi publish() bertanggungjawab membaca bongkah data input demi bongkah dan menghantar setiap bongkah ke saluran keluaran. Ia bermula dengan menggunakan bytes.NewReader(input) untuk mencipta pembaca daripada data input, yang membolehkan data dibaca secara berurutan. Penampan bersaiz 8 dibuat untuk menyimpan setiap ketulan data semasa ia dibaca daripada input. Semasa setiap lelaran, reader.Read(buffer) membaca sehingga 8 bait daripada input, dan fungsi itu kemudian menghantar sekeping penimbal ini (buffer[:n]) yang mengandungi sehingga 8 bait ke saluran output. Gelung berterusan sehingga pembaca.Baca(penampan) sama ada menghadapi ralat atau mencapai penghujung data input.

Fungsi consume() mengendalikan ketulan data yang diterima daripada saluran. Ia memproses ketulan ini menggunakan bufio.Scanner, yang mengimbas setiap ketulan data, berpotensi memecahkannya kepada baris atau token bergantung pada cara ia dikonfigurasikan. Pembolehubah b := scanner.Bytes() mendapatkan semula token semasa yang sedang diimbas. Fungsi ini mewakili pemprosesan input asas.

Main() mencipta saluran buffered chunkChannel dengan kapasiti yang sama dengan workersCount, yang ditetapkan kepada 4 dalam kes ini. Fungsi itu kemudian melancarkan 4 goroutin pekerja, yang setiap satunya akan membaca data daripada chunkChannel secara serentak. Setiap kali pekerja menerima sebahagian daripada data, ia memproses bahagian tersebut dengan memanggil fungsi consume(). Fungsi publish() membaca data yang dijana, memecahkannya kepada ketulan sehingga 8 bait dan menghantarnya ke saluran.

Program ini menggunakan goroutine untuk mencipta berbilang pengguna, membolehkan pemprosesan data serentak. Setiap pengguna berjalan dalam goroutine yang berasingan, memproses sebahagian daripada data secara bebas.

Jika anda menjalankan kod ini, perasan yang mencurigakan akan berlaku:

[Running] go run "main.go"

[Done] exited with code=0 in 0.94 seconds

Tetapi ada masalah. Kami mempunyai Risiko Perlumbaan Data. Dalam kod ini, terdapat potensi perlumbaan data kerana fungsi publish() menggunakan semula kepingan penimbal yang sama untuk setiap bahagian. Pengguna membaca daripada penimbal ini secara serentak, dan memandangkan kepingan berkongsi memori asas, berbilang pengguna mungkin membaca memori yang sama, yang membawa kepada perlumbaan data. Mari cuba gunakan pengesanan perlumbaan. Go menyediakan alat terbina dalam untuk mengesan perlumbaan data: pengesan perlumbaan. Anda boleh mendayakannya dengan menjalankan program anda dengan bendera -race:

go run -race main.go

Jika kami menambah bendera -race pada arahan larian kami akan menerima output berikut:

[Running] go run -race "main.go"

==================
WARNING: DATA RACE
Read at 0x00c00011e018 by goroutine 6:
  runtime.slicecopy()
      /GOROOT/go1.22.0/src/runtime/slice.go:325 +0x0
  bytes.(*Reader).Read()
      /GOROOT/go1.22.0/src/bytes/reader.go:44 +0xcc
  bufio.(*Scanner).Scan()
      /GOROOT/go1.22.0/src/bufio/scan.go:219 +0xef4
  main.consume()
      /GOPATH/example/main.go:40 +0x140
  main.main.func1()
      /GOPATH/example/main.go:55 +0x48

Previous write at 0x00c00011e018 by main goroutine:
  runtime.slicecopy()
      /GOROOT/go1.22.0/src/runtime/slice.go:325 +0x0
  bytes.(*Reader).Read()
      /GOROOT/go1.22.0/src/bytes/reader.go:44 +0x168
  main.publish()
      /GOPATH/example/main.go:27 +0xe4
  main.main()
      /GOPATH/example/main.go:60 +0xdc

Goroutine 6 (running) created at:
  main.main()
      /GOPATH/example/main.go:53 +0x50
==================
Found 1 data race(s)
exit status 66

[Done] exited with code=0 in 0.94 seconds

The warning you’re seeing is a classic data race detected by Go’s race detector. The warning message indicates that two goroutines are accessing the same memory location (0x00c00011e018) concurrently. One goroutine is reading from this memory, while another goroutine is writing to it at the same time, without proper synchronization.

The first part of the warning tells us that Goroutine 6 (which is one of the worker goroutines in your program) is reading from the memory address 0x00c00011e018 during a call to bufio.Scanner.Scan() inside the consume() function.

Read at 0x00c00011e018 by goroutine 6:
  runtime.slicecopy()
  /GOROOT/go1.22.0/src/runtime/slice.go:325 +0x0
  bytes.(*Reader).Read()
  /GOROOT/go1.22.0/src/bytes/reader.go:44 +0xcc
  bufio.(*Scanner).Scan()
  /GOROOT/go1.22.0/src/bufio/scan.go:219 +0xef4
  main.consume()
  /GOPATH/example/main.go:40 +0x140
  main.main.func1()
  /GOPATH/example/main.go:55 +0x48

The second part of the warning shows that the main goroutine previously wrote to the same memory location (0x00c00011e018) during a call to bytes.Reader.Read() inside the publish() function.

Previous write at 0x00c00011e018 by main goroutine:
  runtime.slicecopy()
  /GOROOT/go1.22.0/src/runtime/slice.go:325 +0x0
  bytes.(*Reader).Read()
  /GOROOT/go1.22.0/src/bytes/reader.go:44 +0x168
  main.publish()
  /GOPATH/example/main.go:27 +0xe4
  main.main()
  /GOPATH/example/main.go:60 +0xdc

The final part of the warning explains that Goroutine 6 was created in the main function.

Goroutine 6 (running) created at:
  main.main()
  /GOPATH/example/main.go:53 +0x50

In this case, while one goroutine (Goroutine 6) is reading from the buffer in consume(), the publish() function in the main goroutine is simultaneously writing to the same buffer, leading to the data race.

+-------------------+               +--------------------+
|     Publisher     |               |      Consumer      |
+-------------------+               +--------------------+
        |                                   |
        v                                   |
1. Read data into buffer                    |
        |                                   |
        v                                   |
2. Send slice of buffer to chunkChannel     |
        |                                   |
        v                                   |
 +----------------+                         |
 |  chunkChannel  |                         |
 +----------------+                         |
        |                                   |
        v                                   |
3. Consume reads from slice                 |
                                            v
                                    4. Concurrent access
                                    (Data Race occurs)

Why the Data Race Occurs

The data race in this code arises because of how Go slices work and how memory is shared between goroutines when a slice is reused. To fully understand this, let’s break it down into two parts: the behavior of the buffer slice and the mechanics of how the race occurs. When you pass a slice like buffer[:n] to a function or channel, what you are really passing is the slice header which contains a reference to the slice’s underlying array. Any modifications to the slice or the underlying array will affect all other references to that slice.

buffer = [ a, b, c, d, e, f, g, h ]  <- Underlying array
           ↑
          Slice: buffer[:n]

func publish(input []byte, output chan<- []byte) {  
    reader := bytes.NewReader(input)  

    bufferSize := 8  
    buffer := make([]byte, bufferSize)  

    for {  
       // ....
       output <- buffer[:n] // <-- passing is a reference to the underlying array
    }  
}

If you send buffer[:n] to a channel, both the publish() function and any consumer goroutines will be accessing the same memory. During each iteration, the reader.Read(buffer) function reads up to 8 bytes from the input data into this buffer slice. After reading, the publisher sends buffer[:n] to the output channel, where n is the number of bytes read in the current iteration.

The problem here is that buffer is reused across iterations. Every time reader.Read() is called, it overwrites the data stored in buffer.

• Iteration 1: publish() function reads the first 8 bytes into buffer and sends buffer[:n] (say, [a, b, c, d, e, f, g, h]) to the channel.
• Iteration 2: The publish() function overwrites the buffer with the next 8 bytes, let’s say [i, j, k, l, m, n, o, p], and sends buffer[:n] again.

At this point, if one of the worker goroutines is still processing the first chunk, it is now reading stale or corrupted data because the buffer has been overwritten by the second chunk. Reusing a slice neans sharing the same memory.

How to fix the Data Race?

To avoid the race condition, we must ensure that each chunk of data sent to the channel has its own independent memory. This can be achieved by creating a new slice for each chunk and copying the data from the buffer to this new slice. The key fix is to copy the contents of the buffer into a new slice before sending it to the chunkChannel:

chunk := make([]byte, n)    // Step 1: Create a new slice with its own memory
copy(chunk, buffer[:n])     // Step 2: Copy data from buffer to the new slice
output <- chunk             // Step 3: Send the new chunk to the channel

Why this fix works? By creating a new slice (chunk) for each iteration, you ensure that each chunk has its own memory. This prevents the consumers from reading from the buffer that the publisher is still modifying. copy() function copies the contents of the buffer into the newly allocated slice (chunk). This decouples the memory used by each chunk from the buffer. Now, when the publisher reads new data into the buffer, it doesn’t affect the chunks that have already been sent to the channel.

+-------------------------+           +------------------------+
|  Publisher (New Memory) |           | Consumers (Read Copy)  |
|  [ a, b, c ] --> chunk1 |           |  Reading: chunk1       |
|  [ d, e, f ] --> chunk2 |           |  Reading: chunk2       |
+-------------------------+           +------------------------+
         ↑                                    ↑
        (1)                                  (2)
   Publisher Creates New Chunk          Consumers Read Safely

This solution works is that it breaks the connection between the publisher and the consumers by eliminating shared memory. Each consumer now works on its own copy of the data, which the publisher does not modify. Here’s how the modified publish() function looks:

func publish(input []byte, output chan<- []byte) {
    reader := bytes.NewReader(input)
    bufferSize := 8
    buffer := make([]byte, bufferSize)

    for {
        n, err := reader.Read(buffer)
        if err != nil || err == io.EOF {
            return
        }
        if n == 0 {
            break
        }

        // Create a new slice for each chunk and copy the data from the buffer
        chunk := make([]byte, n)
        copy(chunk, buffer[:n])

        // Send the newly created chunk to the channel
        output <- chunk
    }
}

Summary

Slices Are Reference Types:
As mentioned earlier, Go slices are reference types, meaning they point to an underlying array. When you pass a slice to a channel or a function, you’re passing a reference to that array, not the data itself. This is why reusing a slice leads to a data race: multiple goroutines end up referencing and modifying the same memory.

Peruntukan Memori:
Apabila kita mencipta kepingan baharu dengan make([]bait, n), Go memperuntukkan blok memori yang berasingan untuk kepingan itu. Ini bermakna kepingan baharu (ketulan) mempunyai tatasusunan sandarannya sendiri, bebas daripada penimbal. Dengan menyalin data daripada penimbal[:n] ke dalam bongkah, kami memastikan setiap bongkah mempunyai ruang memori peribadinya sendiri.

Memori Penyahgandingan:
Dengan mengasingkan memori setiap bahagian daripada penimbal, penerbit boleh terus membaca data baharu ke dalam penimbal tanpa menjejaskan bahagian yang telah dihantar ke saluran. Setiap bahagian kini mempunyai salinan bebas datanya sendiri, jadi pengguna boleh memproses bahagian tersebut tanpa gangguan daripada penerbit.

Mencegah Perlumbaan Data:
Sumber utama perlumbaan data ialah akses serentak kepada penimbal yang dikongsi. Dengan mencipta kepingan baharu dan menyalin data, kami menghapuskan memori yang dikongsi, dan setiap goroutine beroperasi pada datanya sendiri. Ini menghapuskan kemungkinan keadaan perlumbaan kerana tiada lagi sebarang perbalahan mengenai ingatan yang sama.

Kesimpulan

Inti pembetulan adalah mudah tetapi berkuasa: dengan memastikan setiap bahagian data mempunyai ingatan sendiri, kami menghapuskan sumber kongsi (penampan) yang menyebabkan perlumbaan data. Ini dicapai dengan menyalin data daripada penimbal ke dalam kepingan baharu sebelum menghantarnya ke saluran. Dengan pendekatan ini, setiap pengguna menggunakan salinan datanya sendiri, bebas daripada tindakan penerbit, memastikan pemprosesan serentak yang selamat tanpa syarat perlumbaan. Kaedah penyahgandingan memori kongsi ini merupakan strategi asas dalam pengaturcaraan serentak. Ia menghalang tingkah laku yang tidak dapat diramalkan yang disebabkan oleh keadaan perlumbaan dan memastikan program Go anda kekal selamat, boleh diramal dan betul, walaupun apabila berbilang gorout mengakses data secara serentak.

Semudah itu!

Atas ialah kandungan terperinci Soalan temuduga Tricky Golang - Part Data Race. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!