在Go语言中，panic:sendonclosedchannel错误通常发生在尝试向已经关闭的通道发送数据时。即使你对通道加了锁，这种错误仍然可能发生，原因可能包括以下几种情况：锁的粒度不够细致：如果锁的范围不够精确，可能导致在锁保护之外的代码段中关闭了通道。例如，假设你有一个锁保护了对通道的操作，但关闭通道的操作在锁之外进行，那么在关闭通道后，仍然可能有其他goroutine尝试向该通道发送数据

Go语言并发编程中，即使使用了互斥锁（mutex），仍然可能出现`panic: send on closed channel`错误。该错误通常发生在尝试向已关闭的通道发送数据时。本文分析了导致此问题的三种主要原因：锁粒度不够细致导致锁保护范围之外关闭通道；锁使用不当（例如忘记加锁或解锁）；以及即使使用锁，仍可能存在的竞争条件，导致`close(c)`和`c

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 < 10; i++ {
        wg.Add(1)
        go func(i int) {
            defer wg.Done()
            select {
            case c <- i:
                fmt.Printf("sent %d\n", i)
            case <-ctx.Done():
                fmt.Println("context cancelled")
            }
        }(i)
    }
    wg.Wait()
}

尽管使用了lock.Lock()和lock.Unlock()保护临界区，但程序仍然可能在c <- i处panic，因为select语句的非确定性行为。

问题分析

Go语言select语句具有非确定性：如果多个case都准备好接收或发送，select会随机选择一个执行。

关键在于：

1. close(c)和c <- i的竞争: close(c)操作和c <- i操作并非原子操作，存在竞争条件。即使加了锁，close(c)操作可能在c <- i操作之后执行，导致c <- i尝试向已关闭的通道发送数据，从而引发panic。

2. select语句的随机性: 即使ctx.Done()已经准备好，select仍然可能随机选择c <- i执行。

解决方案

为了避免此问题，需要确保在发送数据前检查通道是否已关闭。 可以使用select语句的默认case来实现：

select {
case c <- i:
    fmt.Printf("sent %d\n", i)
default:
    fmt.Println("channel closed or full")
}

或者，使用一个额外的通道来协调关闭操作：

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 < 10; i++ {
        wg.Add(1)
        go func(i int) {
            defer wg.Done()
            select {
            case c <- i:
                fmt.Printf("sent %d\n", i)
            case <-done:
                fmt.Println("channel closing")
            }
        }(i)
    }
    wg.Wait()
}

这个改进的版本使用done通道来通知goroutine通道即将关闭，避免了竞争条件。

通过以上方法，可以有效地避免panic: send on closed channel错误，即使在并发环境下使用锁。 选择哪种解决方案取决于具体的应用场景和代码复杂度。

今天关于《在Go语言中，panic:sendonclosedchannel错误通常发生在尝试向已经关闭的通道发送数据时。即使你对通道加了锁，这种错误仍然可能发生，原因可能包括以下几种情况：锁的粒度不够细致：如果锁的范围不够精确，可能导致在锁保护之外的代码段中关闭了通道。例如，假设你有一个锁保护了对通道的操作，但关闭通道的操作在锁之外进行，那么在关闭通道后，仍然可能有其他goroutine尝试向该通道发送数据，从而导致panic。varch=make(chanint)varmusync.Mutexfuncsender(){mu.Lock()//假设这里有其他代码ch<-1//如果此时通道已被关闭，将会panicmu.Unlock()}funccloser(){//关闭通道的操作在锁之外进行close(ch)}在上面的例子中，如果closer函数在sender函数获取锁之前关闭了通道，那么sender函数在尝试向通道发送数据时就会panic。竞争条件：即使锁的使用正确，仍然可能存在竞争条件。例如，如果多个goroutine同时尝试关闭通道，并且其中一个goroutine成功关闭了通道，其他goroutine可能会在不知情的情况下继续尝试向该通道发送数据。varch=make(chanint)varmusync.Mutexfuncsender(){mu.Lock()defermu.Unlock()ch<-1//如果通道已被关闭，将会panic}funccloser(){mu.Lock()defermu.Unlock()close(ch)}在这个例子中，如果closer函数在sender函数之前执行并关闭了通道，那么sender函数在尝试向通道发送数据时就会panic。延迟执行的关闭操作：有时关闭通道的操作可能在某个延迟执行的函数中进行，例如在defer语句中。如果在关闭通道之前有其他goroutine尝试向通道发送数据，也会导致panic。varch=make(chanint)varmusync.Mutexfuncsender(){mu.Lock()defermu.Unlock()ch<-1//如果通道已被关闭，将会panic}funccloser(){mu.Lock()defermu.Unlock()deferclose(ch)//关闭通道操作延迟执行}在这个例子中，如果closer函数在sender函数之前执行，但sender函数在closer函数的defer语句执行之前尝试向通道发送数据，那么也会导致panic。为了避免这种错误，确保所有对通道的操作都在同一个锁的保护之下，并且在关闭通道之前，确保没有其他goroutine会尝试向该通道发送数据。》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！