nhooyr/websocket中的WaitGroup重用问题分析与修复

在Go语言的WebSocket实现库nhooyr/websocket中，开发者发现了一个关于sync.WaitGroup重用的并发安全问题。这个问题会导致在特定情况下程序出现panic，影响服务的稳定性。

问题现象

当多个goroutine同时调用Conn.CloseNow()方法时，会出现以下panic错误：

panic: sync: WaitGroup is reused before previous Wait has returned

这个panic表明程序在WaitGroup的Wait方法尚未返回时，就尝试重用这个WaitGroup，这是sync.WaitGroup不允许的操作。

问题根源分析

通过查看源代码，我们发现CloseNow方法的实现存在潜在的竞态条件。原始代码如下：

func (c *Conn) CloseNow() (err error) {
    defer c.wg.Wait()
    defer errd.Wrap(&err, "failed to close WebSocket")

    if c.isClosed() {
        return net.ErrClosed
    }
    // ...其他关闭逻辑
}

问题出在方法开始处就使用了defer c.wg.Wait()。当两个goroutine同时调用CloseNow()时，可能会出现以下时序：

1. 第一个goroutine执行到defer c.wg.Wait()
2. 第二个goroutine也执行到defer c.wg.Wait()
3. 第一个goroutine的Wait()开始执行但尚未返回
4. 第二个goroutine的Wait()尝试执行，此时就会触发panic

解决方案

修复方案很简单但很有效：将defer语句移到isClosed()检查之后。修改后的代码如下：

func (c *Conn) CloseNow() (err error) {
    if c.isClosed() {
        return net.ErrClosed
    }
    defer c.wg.Wait()
    defer errd.Wrap(&err, "failed to close WebSocket")
    // ...其他关闭逻辑
}

这样修改后，如果连接已经关闭，方法会直接返回而不会设置任何defer，避免了WaitGroup的重用问题。只有在连接确实需要关闭时，才会设置WaitGroup的Wait调用。

深入理解WaitGroup的正确使用

这个修复案例很好地展示了sync.WaitGroup的正确使用模式。WaitGroup是Go语言中用于同步goroutine的重要工具，但使用时需要注意：

1. WaitGroup不能在被Wait的同时被Add或Done
2. WaitGroup的Wait调用必须保证在Add之后
3. 在多goroutine环境下，对WaitGroup的操作需要特别小心竞态条件

在实际开发中，我们应该：

1. 尽量将WaitGroup的使用限制在单一控制流中
2. 避免在可能被并发调用的函数中使用WaitGroup
3. 如果必须使用，确保有适当的同步机制保护

总结

nhooyr/websocket库中的这个修复案例展示了并发编程中常见的陷阱。通过简单的代码调整，就解决了一个可能导致程序崩溃的严重问题。这也提醒我们，在编写并发代码时，需要对同步原语的使用格外小心，特别是在可能被多个goroutine同时调用的函数中。

对于使用WebSocket进行网络编程的开发者来说，理解这类底层库的实现细节和潜在问题，有助于编写更健壮的网络应用程序。