Why does the code with locks occasionally cause panic: send on closed channel?

Analysis of the reason why the Go language lock code occasionally appears panic: send on closed channel

In Go concurrent programming, it is common to use locks (mutex) to ensure thread safety, but even if locks are used, you may still encounter panic: send on closed channel errors. This article analyzes the causes and solutions for this problem.

Problem code and phenomenon

The following code snippet demonstrates the problem:

 package main

import (
    "context"
    "fmt"
    "sync"
)

var lock sync.Mutex

func main() {
    c := make(chan int, 10)
    wg := sync.WaitGroup{}
    ctx, cancel := context.WithCancel(context.Background())

    wg.Add(1)
    go func() {
        defer wg.Done()
        lock.Lock()
        cancel()
        close(c)
        lock.Unlock()
    }()

    for i := 0; i <p> Although <code>lock.Lock()</code> and <code>lock.Unlock()</code> are used to protect the critical section, the program may still panic at <code>c  because of the nondeterministic behavior of <code>select</code> statement.</code></p><h4 id="Problem-analysis"> Problem analysis</h4><p> The Go language <code>select</code> statement is non-deterministic: if multiple cases are ready to be received or sent, <code>select</code> will randomly select one execution.</p><p> The key is:</p><ol>
<li><p> <strong>Competition between <code>close(c)</code> and <code>c  :</code></strong> <code>close(c)</code> and <code>c  operations are not atomic operations, there are race conditions. Even if lock is added, the <code>close(c)</code> operation may be performed after <code>c  operation, causing <code>c  to attempt to send data to the closed channel, thereby causing panic.</code></code></code></p></li>
<li><p> <strong>Randomity of <code>select</code> statement:</strong> even if <code>ctx.Done()</code> is ready, <code>select</code> may still randomly select <code>c  to execute.</code></p></li>
</ol><h4 id="Solution"> Solution</h4><p> To avoid this problem, you need to make sure that the channel is closed before sending the data. You can use the default case of <code>select</code> statement to implement it:</p><pre class="brush:php;toolbar:false"> select {
case c <p> Alternatively, use an extra channel to coordinate the shutdown operation:</p><pre class="brush:php;toolbar:false"> package main

import (
    "fmt"
    "sync"
)

func main() {
    c := make(chan int, 10)
    done := make(chan struct{})
    wg := sync.WaitGroup{}

    wg.Add(1)
    go func() {
        defer wg.Done()
        close(done) // Signal that the channel is closing
        close(c)
    }()

    for i := 0; i <p> This improved version uses the <code>done</code> channel to notify the goroutine channel to be closed soon, avoiding race conditions.</p><p> Through the above method, <code>panic: send on closed channel</code> error can be effectively avoided, even if locks are used in concurrent environments. Which solution to choose depends on the specific application scenario and code complexity.</p>

The above is the detailed content of Why does the code with locks occasionally cause panic: send on closed channel?. For more information, please follow other related articles on the PHP Chinese website!