Golang中time.After的使用理解与释放问题
Golang中的time.After的使用理解
关于在goroutine中使用time.After的理解， 新手在学习过程中的“此时此刻”的理解，错误还请指正。
先线上代码：
package main
import (
"fmt"
"time"
)
func main() {
//closeChannel()
c := make(chan int)
timeout := time.After(time.Second * 2) //
t1 := time.NewTimer(time.Second * 3) // 效果相同 只执行一次
var i int
go func() {
for {
select {
case <-c:
fmt.Println("channel sign")
return
case <-t1.C: // 代码段2
fmt.Println("3s定时任务")
case <-timeout: // 代码段1
i++
fmt.Println(i, "2s定时输出")
case <-time.After(time.Second * 4): // 代码段3
fmt.Println("4s timeout。。。。")
default: // 代码段4
fmt.Println("default")
time.Sleep(time.Second * 1)
}
}
}()
time.Sleep(time.Second * 6)
close(c)
time.Sleep(time.Second * 2)
fmt.Println("main退出")
}
主要有以上4点是我们平时遇到的。
首先遇到的问题是：
如上的代码情况下， 代码段3处的case 永远不执行， 无论main进程执行多久。这是为什么呢？
首先我们分析为啥不执行代码段3， 而是程序一直执行的是default. 由此我们判断：
case <- time.After(time.Second) :
是本次监听动作的超时时间， 意思就说，只有在本次select 操作中会有效， 再次select 又会重新开始计时（从当前时间+4秒后）， 但是有default ，那case 超时操作，肯定执行不到了。
那么问题就简单了我们预先定义了计时操作：
case <- timeout:
在goroutine开始前， 我们记录了时间，在此时间3s之后进行操作。相当于定时任务， 并且只执行一次。 代码段1和代码段2 实现的结果都相同
针对以上问题解决后，我写了一个小案例：
package main
import (
"fmt"
"time"
)
//发送者
func sender(c chan int) {
for i := 0; i < 100; i++ {
c <- i
if i >= 5 {
time.Sleep(time.Second * 7)
} else {
time.Sleep(time.Second)
}
}
}
func main() {
c := make(chan int)
go sender(c)
timeout := time.After(time.Second * 3)
for {
select {
case d := <-c:
fmt.Println(d)
case <-timeout:
fmt.Println("这是定时操作任务 >")
case dd := <-time.After(time.Second * 3):
fmt.Println(dd, "这是超时*****")
}
fmt.Println("for end")
}
}
执行结果：
要注意的是，虽然执行到i == 6时， 堵塞了，并且执行了超时操作， 但是下次select 依旧去除的是6
因为通道中已经发送了6,如果未取出，程序堵塞。
GOLANG中time.After释放的问题
在谢大群里看到有同学在讨论time.After泄漏的问题，就算时间到了也不会释放，瞬间就惊呆了，忍不住做了试验，结果发现应该没有这么的恐怖的，是有泄漏的风险不过不算是泄漏，先看API的说明：
// After waits for the duration to elapse and then sends the current time
// on the returned channel.
// It is equivalent to NewTimer(d).C.
// The underlying Timer is not recovered by the garbage collector
// until the timer fires. If efficiency is a concern, use NewTimer
// instead and call Timer.Stop if the timer is no longer needed.
func After(d Duration) <-chan Time {
return NewTimer(d).C
}
提到了一句The underlying Timer is not recovered by the garbage collector，这句挺吓人不会被GC回收，不过后面还有条件until the timer fires，说明fire后是会被回收的，所谓fire就是到时间了，写个例子证明下压压惊：
package main
import "time"
func main() {
for {
<- time.After(10 * time.Nanosecond)
}
}
显示内存稳定在5.3MB，CPU为161%，肯定被GC回收了的。当然如果放在goroutine也是没有问题的，一样会回收：
package main
import "time"
func main() {
for i := 0; i < 100; i++ {
go func(){
for {
<- time.After(10 * time.Nanosecond)
}
}()
}
time.Sleep(1 * time.Hour)
}
只是资源消耗会多一点，CPU为422%，内存占用6.4MB。因此：
Remark: time.After(d)在d时间之后就会fire，然后被GC回收，不会造成资源泄漏的。
那么API所说的If efficieny is a concern, user NewTimer instead and call Timer.Stop是什么意思呢？这是因为一般time.After会在select中使用，如果另外的分支跑得更快，那么timer是不会立马释放的(到期后才会释放)，比如这种：
select {
case time.After(3*time.Second):
return errTimeout
case packet := packetChannel:
// process packet.
}
如果packet非常多，那么总是会走到下面的分支，上面的timer不会立刻释放而是在3秒后才能释放，和下面代码一样：
package main
import "time"
func main() {
for {
select {
case <-time.After(3 * time.Second):
default:
}
}
}
这个时候，就相当于会堆积了3秒的timer没有释放而已，会不断的新建和释放timer，内存会稳定在2.8GB，这个当然就不是最好的了，可以主动释放：
package main
import "time"
func main() {
for {
t := time.NewTimer(3*time.Second)
select {
case <- t.C:
default:
t.Stop()
}
}
}
这样就不会占用2.8GB内存了，只有5MB左右。因此，总结下这个After的说明：
- GC肯定会回收time.After的，就在d之后就回收。一般情况下让系统自己回收就好了。
- 如果有效率问题，应该使用Timer在不需要时主动Stop。大部分时候都不用考虑这个问题的。
总结
以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对的支持。
下一篇：利用golang进行OpenCV学习和开发的步骤