golang小问题记录

退出程序时怎么防止channel没有消费完？

不要在消费端关闭channel，不要在有多个并行的生产者时对channel执行关闭操作，应只在唯一或最后唯一剩下的生产者协程中关闭channel，来通知消费者已经无值可读。

对无缓冲channel来说，程序退出时将生产者关闭就不会产生多余数据给消费者。

对有缓冲channel最本质的原则只有一个，就是不要关闭或将值发送到已关闭通道。

可使用sync.Once来确保只会关闭一次channel，使用sync.Mutex达到同样的目的，但推荐的话，还是使用sync.Once。

关闭有缓冲channel有以下几种情况：

• 多消费者-单一生产者：可直接让生产者关闭channel。

• 多生产者-单一消费者：不能在消费端关闭channel，此操作违背channel关闭原则，可让消费端关闭或发送信号通知生产者停止生产数据。

• 多生产者-多消费者：不能让生产者或消费者关闭channel，也不能让消费者关闭或发送信号通知生产者停止生产数据，只能可以引入额外的协调者来关闭附加的退出信号channel。

协程泄露(Goroutine Leak)？

Go并发是以goroutine和channel的形式实现，协程泄露指的是goroutine创建后长时间得不到释放，且还在不断创建新goroutine，最终导致内存耗尽，程序崩溃。

常见导致协程泄露的场景如下

• 缺少接收器，导致发送阻塞：启动N个协程接收channel中信息，但channel并不会发送那么多信息，从而导致接收协程阻塞，不能退出。

• 死锁(dead lock)：同一个goroutine中使用同一个chnnel读写，其次是2个以上的Go程中使用同一个channel通信，且读写channel先于Go程序创建，再次就是channel和读写锁、互斥锁混用。

• 无限死循环(infinite loops)：I/O 操作上的堵塞也可能造成泄露，例如发送请求到 API 服务器，而没有使用超时；或者程序单纯地陷入死循环中

服务器出现TIME_WAIT和CLOSE_WAIT的原因以及解决方法？

• TIME_WAIT：对基于TCP的HTTP协议，关闭TCP连接的是Server端，此时Server端会进入TIME_WAIT状态，访问量大的Web Server会存在大量TIME_WAIT状态，解决方案很简单，可通过配置服务器的参数来处理。

• CLOSE_WAIT：客户端关闭连接后，服务器程序未发出ack信号，也就是说在客户端连接关闭后，程序里没有检测到或程序压根就没有关闭连接操作，此时该资源就一直被程序占着，这种情况通过服务器内核参数无法解决，服务器对于程序抢占的资源没有主动回收的权利，除非终止程序运行，只能去排查代码找原因。