解析《Go in Action》资源池实现中的潜在死锁问题

首先明确死锁的触发场景：如果把Close方法的逻辑反过来——先排空通道再关闭，就会出现以下死锁情况：

1. 假设资源池的所有资源都被Acquire出去了，此时resources通道是空的。
2. 调用Close方法，它会先获取p.m锁，然后进入for r := range p.resources循环。因为通道未关闭，当通道为空时，for range会永久阻塞，等待新的元素被发送到通道中。
3. 此时，持有资源的goroutine调用Release方法想要归还资源，Release第一步是调用p.m.Lock()，但锁已经被Close方法持有，所以Release会阻塞等待锁释放。
4. 这就形成了循环等待：Close在等通道有资源进来（但没人能放，因为Release拿不到锁），Release在等锁被释放（但Close在阻塞），最终触发死锁。

而原代码中先关闭通道再排空的逻辑，能避免这个问题：

• 调用close(p.resources)后，通道被标记为关闭，此时for range遍历通道时，会先取出通道中剩余的所有元素，当元素取完后，循环会自动退出，不会阻塞。
• 同时，通道关闭后，Acquire方法中读取通道会得到ok=false，返回ErrPoolClosed，不会再创建新资源；Release方法因为检测到p.closed=true，会直接关闭资源，不会再尝试往通道里发送，进一步避免了后续的阻塞。

你疑惑的Acquire非阻塞设计，其实和这个死锁场景无关——死锁的核心是Close方法持有锁时的通道遍历阻塞，以及Release方法需要锁才能归还资源的冲突，和Acquire是否阻塞没有直接关系。

内容的提问来源于stack exchange，提问作者grzhan