为什么加了锁的代码偶尔还会导致panic: send on closed channel？

Go语言加锁代码偶尔出现panic: send on closed channel的原因分析

在Go语言并发编程中，使用锁(mutex)保证线程安全是常见做法，但即使使用了锁，仍然可能遇到panic: send on closed channel错误。本文分析此问题出现的原因及解决方案。

问题代码及现象

以下代码片段演示了该问题：

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>尽管使用了<code>lock.Lock()</code>和<code>lock.Unlock()</code>保护临界区，但程序仍然可能在<code>c 处panic，因为<code>select</code>语句的非确定性行为。</code></p>
<h4 id="问题分析">问题分析</h4>
<p>Go语言<code>select</code>语句具有非确定性：如果多个case都准备好接收或发送，<code>select</code>会随机选择一个执行。</p>
<p>关键在于：</p>
<ol>
<li>
<p><strong><code>close(c)</code>和<code>c 的竞争:</code></strong>  <code>close(c)</code>操作和<code>c 操作并非原子操作，存在竞争条件。即使加了锁，<code>close(c)</code>操作可能在<code>c 操作之后执行，导致<code>c 尝试向已关闭的通道发送数据，从而引发panic。</code></code></code></p>
</li>
<li>
<p><strong><code>select</code>语句的随机性:</strong>  即使<code>ctx.Done()</code>已经准备好，<code>select</code>仍然可能随机选择<code>c 执行。</code></p>
</li>
</ol>
<h4 id="解决方案">解决方案</h4>
<p>为了避免此问题，需要确保在发送数据前检查通道是否已关闭。  可以使用<code>select</code>语句的默认case来实现：</p>
<pre class="brush:php;toolbar:false">select {
case c 
<p>或者，使用一个额外的通道来协调关闭操作：</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>这个改进的版本使用<code>done</code>通道来通知goroutine通道即将关闭，避免了竞争条件。</p>
<p>通过以上方法，可以有效地避免<code>panic: send on closed channel</code>错误，即使在并发环境下使用锁。  选择哪种解决方案取决于具体的应用场景和代码复杂度。</p>

以上是为什么加了锁的代码偶尔还会导致panic: send on closed channel？的详细内容。更多信息请关注PHP中文网其他相关文章！