为什么这个接收者在连接关闭时进入例程拒绝终止

这按预期运行，但随后随机地，每调用 20-10,000 次，接收器将无法关闭，然后导致 go routine 泄漏，导致 100% cpu。

注意:如果我记录所有错误，如果 conn.SetReadDeadline 被注释掉，我将在关闭的 channel 上看到读取。使用时，我将 i/o 超时视为错误。

这运行了 10k 个周期，其中主进程启动了 11 对这样的发送/接收方，它们在主进程发送关闭信号之前处理了 1000 个作业。此设置在一夜之间运行了 6 小时以上而没有任何问题，达到 10k 个周期标记，但今天早上我无法让它运行超过 20 个周期而没有将接收器标记为未关闭和退出。

func sender(w worker, ch channel) {

    var j job
    for {
        select {
        case <-ch.quit: // shutdown broadcast, exit
            w.Close()
            ch.stopped <- w.id // debug, send stop confirmed
            return

        case j = <-w.job: // worker designated jobs
        case j = <-ch.spawner: // FCFS jobs
        }

        ... prepare job ...

        w.WriteToUDP(buf, w.addr)

}

func receiver(w worker, ch channel) {

    deadline := 100 * time.Millisecond
out:
    for {
        w.SetReadDeadline(time.Now().Add(deadline))
        // blocking read, should release on close (or deadline)
        n, err = w.c.Read(buf)

        select {
        case <-ch.quit: // shutdown broadcast, exit
            ch.stopped <- w.id+100 // debug, receiver stop confirmed
            return
        default:
        }

        if n == 0 || err != nil {
            continue
        }
        update := &update{id: w.id}

         ... process update logic ...

        select {
        case <-ch.quit: // shutting down
            break out
        case ch.update <- update
        }

}

我需要一种可靠的方法来让接收器在接收到关闭广播或 conn 关闭时关闭。从功能上讲，关闭 channel 应该足够了，并且根据 go 包 documentation 是首选方法。 ，请参见 Conn 接口(interface)。

我升级到最新的 go，即 1.12.1，没有任何变化。 在开发中运行在 MacOS 上，在生产中运行在 CentOS 上。

有人遇到过这个问题吗？ 如果是这样，您是如何可靠地修复它的？

可能的解决方案

我的非常冗长和棘手的解决方案似乎可能有效，作为一种解决方法，就是这样做:

1) 在 go routine 中启动发送器，像这样(如上，不变)

2) 在 go routine 中启动接收器，像这样(如下)

func receive(w worker, ch channel) {

    request := make(chan []byte, 1)
    reader := make(chan []byte, 1)

    defer func() {
        close(request) // exit signaling
        w.c.Close()    // exit signaling
        //close(reader)
    }()

    go func() {

        // untried senario, for if we still have leaks -> 100% cpu
        // we may need to be totally reliant on closing request or ch.quit
        // defer w.c.Close()

        deadline := 100 * time.Millisecond
        var n int
        var err error

        for buf := range request {
            for {
                select {
                case <-ch.quit: // shutdown signal
                    return
                default:
                }
                w.c.SetReadDeadline(time.Now().Add(deadline))
                n, err = w.c.Read(buf)
                if err != nil { // timeout or close
                    continue
                }
                break
            }
            select {
            case <-ch.quit: // shutdown signal
                return
            case reader <- buf[:n]:
                //default:
            }
        }
    }()

    var buf []byte

out:
    for {

        request <- make([]byte, messageSize)

        select {
        case <-ch.quit: // shutting down
            break out
        case buf = <-reader:
        }

        update := &update{id: w.id}

      ... process update logic ...


        select {
        case <-ch.quit: // shutting down
            break out
        case ch.update <- update
        }

    }

我的问题是，为什么这个可怕的版本 2 会生成一个新的 go 例程以从阻塞的 c.Read(buf) 中读取数据，它似乎工作得更可靠，这意味着它在发送关闭信号时不会泄漏，当更简单的第一个版本没有......而且由于阻塞 c.Read(buf)，它似乎本质上是同一件事。

当这是一个合法且可验证的可重复问题时，降级我的问题没有帮助，问题仍然没有答案。

最佳答案

感谢大家的回复。

所以。从来没有堆栈跟踪。事实上，我根本没有发现任何错误，没有出现竞争检测或其他任何错误，而且它没有陷入僵局，go 例程只是不会关闭和退出，而且它不能始终如一地重现。两周来我一直在运行相同的数据。

当 go 例程无法报告正在退出时，它会简单地失去控制并将 CPU 驱动到 100%，但只有在所有其他例程退出并且系统继续运行之后。我从未见过内存增长。 CPU 会逐渐上升到 200%、300%、400%，此时系统必须重新启动。

我记录了泄漏发生的时间，它总是不同的，并且在之前的 380 次成功运行(23 对联合运行的 go 例程中)之后我会得到一次泄漏，下一次是 1832 之前一个接收器泄漏，下一次只有 23 个，在相同的起点上咀嚼完全相同的数据。泄漏的接收器刚刚失控旋转，但只有在其他 22 名同伴全部关闭并成功退出并且系统转移到下一批之后。它不会一直失败，除非它保证会在某个时候泄漏。

经过许多天、无数次重写以及每次操作之前/之后的一百万条日志，这最终似乎是问题所在，在深入了解图书馆之后，我不确定为什么会这样，也不知道为什么它只是随机发生.

无论出于何种原因，如果您解析并直接跳过问题而不先阅读问题，golang.org/x/net/dns/dnsmessage 库将随机崩溃。不知道为什么这很重要，你好，跳过问题意味着你不关心那个标题部分并将其标记为已处理，并且它连续一百万次都可以正常工作，但后来却没有，所以你似乎需要先阅读问题，然后才能跳过所有问题，因为这似乎是解决方案。我有 18,525 个批处理，并补充说关闭了泄漏。

var p dnsmessage.Parser
h, err := p.Start(buf[:n])
if err != nil {
    continue // what!?
}

switch {
case h.RCode == dnsmessage.RCodeSuccess:
    q, err := p.Question() // should only have one question
    if q.Type != w.Type || err != nil {
        continue // what!?, impossible
    }
    // Note: if you do NOT do the above first, you're asking for pain! (tr)
    if err := p.SkipAllQuestions(); err != nil {
        continue // what!?
    }
    // Do not count as "received" until we have passed above point and
    // validated that response had a question that we could skip...

关于go - 为什么这个 go 例程在关闭阻塞读取连接时随机无法退出？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/55486000/