首页 > 其他分享 >为什么需要超时控制

为什么需要超时控制

时间:2023-05-07 15:56:36浏览次数:36  
标签:为什么 timerCtx 控制 实现 context time 超时

1. 简介

本文将介绍为什么需要超时控制,然后详细介绍Go语言中实现超时控制的方法。其中,我们将讨论time包和context包实现超时控制的具体方式,并说明两者的适用场景,以便在程序中以更合适的方式来实现超时控制,提高程序的稳定性和可靠性。

2. 为什么需要超时控制

超时控制可以帮助我们避免程序无限期地等待某个操作完成或者防止程序因为某些原因导致资源泄漏。具体来说,超时控制有以下几个优点:

  1. 避免无限期等待:如果某个操作需要等待一段时间,但如果超过了这个时间还没有完成,那么程序可能就需要停止等待并采取其他措施,比如返回错误或者取消操作。超时处理可以让程序避免无限期等待,从而提高程序的健壮性和可靠性。
  2. 防止资源泄漏:如果程序某个操作一直处于等待状态,那么可能会导致资源被一直占用,从而造成资源泄漏。超时控制可以让程序在一定时间内完成操作,如果超时则释放资源,从而避免资源泄漏。
  3. 提高程序响应速度:有些操作可能需要很长时间才能完成,这可能会导致程序在等待过程中变得不响应。超时控制可以让程序在一定时间内完成操作,如果超时则采取其他措施,从而提高程序的响应速度。

基于以上几点原因,我们可以看出来,在某些场景下,超时控制在程序执行过程中必不可少。那么,在Go语言中,有哪些方式可以实现超时控制呢?

3. 超时控制的方法

3.1 time包实现超时控制

time包提供了多种方式来实现超时控制,包括time.After函数、time.NewTimer函数以及time.AfterFunc函数,使用它们可以实现超时控制,下面以time.NewTimer函数为例,说明如何使用其time包实现超时控制。代码示例如下:

// 创建一个定时器
timer := time.NewTimer(5 * time.Second)
defer timer.Stop()

// 使用一个channel来监听任务是否已完成
ch := make(chan string, 1)     
go func() {         
// 模拟任务执行,休眠5秒         
    time.Sleep(2* time.Second)         
    ch <- "hello world"     
}()

// 通过select语句来等待结果,任务正常返回
select {
case <-ch:
    fmt.Println("任务正常完成")
  // ch 已经接收到值,走正常处理逻辑
case <-timer.C:
    fmt.Println("已超时")
  // 超时,走超时逻辑
}

在这里例子中,我们使用 time.NewTimer 方法创建一个定时器,超时时间为2秒钟。然后在 select 语句中使用来等待结果,哪个先返回就使用哪个。

如果操作在2秒钟内完成,那么任务正常完成;如果操作超过2秒钟仍未完成,此时select语句中<-timer.C将接收到值,走超时处理逻辑。

3.2 context实现超时控制

Context 接口是 Go 语言标准库中提供的一个上下文(Context)管理机制。它允许在程序的不同部分之间传递上下文信息,并且可以通过它实现超时控制、取消操作以及截断操作等功能。其中,Context接口存在一个timerCtx的实现,其可以设定一个超时时间,在到达超时时间后,timerCtx对象的 done channel 将会被关闭。

当需要判断是否超时时,只需要调用 context 对象的 Done 方法,其会返回timerCtx对象中的done channel,如果有数据返回,则说明已经超时。基于此,我们便可以实现超时控制。代码示例如下:

// 创建一个timerCtx,设置超时时间为3秒     
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)     
// 调用cancel函数,释放占用的资源  
defer cancel()

// 使用一个channel来监听任务是否已完成
ch := make(chan string, 1)     
go func() {         
// 模拟任务执行,休眠5秒         
    time.Sleep(2* time.Second)         
    ch <- "hello world"     
}()

// 通过select语句来等待结果,任务正常返回
select {
    case <-ctx.Done():
        fmt.Println("timeout")
    case result := <-ch:
        fmt.Println(result)
}

这里通过context.WithTimeout创建一个timerCtx,设定好超时时间,超时时间为3s。然后启动一个协程来执行具体的业务逻辑。

之后通过select语句,对timerCtx和业务执行结果同时进行监听,当任务处理超时时,则执行超时逻辑;如果任务在超时前完成,则执行正常处理流程。通过这种方式,实现了请求的超时处理。

4. 适用场景分析

从上文可以看出,timetimerCtx都可以用于实现超时控制,但是事实上两者的适用场景其实是不太相同的。在某些场景下,超时控制并不适合使用time来实现,而是使用timerCtx来实现更为合适。而在某些场景下,其实两种实现方式均可。

下面我简单介绍几种常见的场景,然后对其来进行分析,从而能够在合适的场景下使用恰当得实现。

4.1 简单超时控制

举个例子,假设我们需要从一个远程服务获取一些数据,我们可以使用Go标准库中的http包进行网络请求,大概请求函数如下:

func makeRequest(url string) (string, error) {
   // 请求数据
}

此时为了避免请求响应时间过长,导致程序长时间处于等待状态,此时我们需要对这个函数实现超时处理,确保程序能够及时响应其他请求,而不是一直等待。

为了实现这个目的,此时可以使用time包或者timerCtx来实现超时控制。在makeRequest函数中实现超时控制,这里代码展示与第三点超时控制的方法中的代码示例大体相同,这里不再赘述。而且,查看上面代码示例,我们也可以看出来timer或者timerCtx在这个场景下,区别并不大,此时是可以相互替换的。

因此,对于这种控制某个函数的执行时间的场景,是可以任意挑选time或者timerCtx其中一个来实现的。

4.2 可选超时控制

这里我们实现一个方法,用于建立网络连接,用户调用该方法时,传入待建立连接的地址列表,然后该方法通过遍历传入的地址列表,并针对每一个地址进行连接尝试,直到连接成功或者所有地址都尝试完成。函数定义如下:

func dialSerial(ras addrList) (Conn, error){
   // 执行建立网络连接的逻辑
}

基于此,在这个函数的基础上,实现一个可选的超时控制的功能。如果用户调用该方法时,有指定超时时间的话,此时便进行超时控制;如果未指定超时时间的话,此时便无需执行超时控制。这里分别使用time包以及context实现。

首先对于time包实现可选的超时控制,可以通过函数参数传递定时器来实现可选的超时控制。具体地说,可以将定时器作为一个time.Timer类型的参数传递给函数,然后在函数中使用select监听time.Timer是超时;如果没有传递定时器实例,则默认不进行超时控制,代码实现如下所示:

func dialSerial(timeout time.Timer, ras addrList) (Conn, error){
   // 执行建立网络连接的逻辑,对每个地址尝试建立连接时,先检查是否超时
   for i, ra := range ras {
          // 通过这里来进行超时控制,首先先判断是否传入定时器实例
          if timeout != nil {
              select {
              // 监听是否超时
              case <-timeout.C:
                  return nil, errors.New("timeout")
              default:
              }
          }
         // 执行后续建立网络连接的逻辑          
   }
}

接着则是使用timerCtx来实现超时控制的实现,可以通过函数传递一个context.Context接口的参数来实现超时控制。

具体来说,用户可以传递一个context.Context接口的实现,如果有指定超时时间,则传入一个timerCtx的实现;如果无需超时控制,此时可以传入context.Background,其永远不会超时。然后函数中通过调用Done方法来判断是否超时,从而实现超时控制。代码实现如下:

func dialSerial(ctx context.Context, ras addrList) (Conn, error){
   // 执行建立网络连接的逻辑,对每个地址尝试建立连接时,先检查是否超时
   for i, ra := range ras {
       select {
       case <-ctx.Done():
          return nil, &OpError{Op: "dial", Net: sd.network, Source: sd.LocalAddr, Addr: ra, Err: mapErr(ctx.Err())}
       default: 
       }
       // 执行建立网络连接的逻辑
   }
}

查看上述代码中,dialSerial函数实现可选超时控制,看起来只是传入参数不同,一个是传入定时器time.Timer实例,一个是传入context.Context接口实例而已,但是实际上不仅仅如此。

首先是代码的可读性上来看,传入time.Timer实例来实现超时控制,并非Go中常见的实现方式,用户不好理解;而对于context.Context接口来说,其被广泛使用,如果要实现超时控制,用户只需要传入一个timerCtx实例即可,用户使用起来没有额外的心智负担,代码可读性更强。

其次是对于整个Go语言的生态来说,context.Context接口在Go语言标准库中得到广泛使用,而且普遍超时控制都是使用timerCtx来实现的,如果此时传入一个time.Timer实例,实际上是与整个Go语言的超时控制的格格不入的。以上面dialSerial方法为例,其建立网络连接是需要调用底层函数来协助实现的,如:

func (fd *netFD) connect(ctx context.Context, la, ra syscall.Sockaddr) (rsa syscall.Sockaddr, ret error) {
    // 执行建立连接的逻辑
    switch err := connectFunc(fd.pfd.Sysfd, ra); err {
    // 未报错,此时检查是否超时
    case nil, syscall.EISCONN:
       select {
       case <-ctx.Done():
           // 如果已经超时,此时返回超时错误
          return nil, mapErr(ctx.Err())
       default:
       }
     }
}

而且刚好,该函数也是实现了可选的超时控制,而且是通过timerCtx来实现的,如果此时传入的timerCtx已经超时,此时函数会直接返回一个超时错误。

如果上面dialSerial的超时控制是通过context.Context的接口实例来实现的话,此时调用函数时,直接将外部的Context实例作为参数传入connect函数,外层调用也无需再检查函数是否超时,代码的可复用性更高。

相对的,如果dialSerial的超时控制是通过传入定时器实现的,此时便无法很好利用connect方法已经实现的超时检查的机制。

因此,综上所述,使用 context.Context 接口作为可选的超时控制参数,相比于使用 time.Timer,更加适合同时也更加高效,与整个Go语言的实现也能够更好得进行融合在一起。

4.3 总结

ContextTime 都是 Go 语言中实现超时控制的方法,它们各有优缺点,不能说哪一种实现更好,要根据具体的场景来选择使用哪种方法。

在一些简单的场景下,使用 Time 包实现超时控制可能更加方便,因为它的 API 更加简单,只需要使用 time.After() 函数即可实现超时控制。

但是,如果涉及到在多个函数,或者是需要多个goroutine之间传递的话,此时使用Context来实现超时控制可能更加适合。

5.总结

本文介绍了需要超时控制的原因,主要是避免无限期等待,防止资源泄漏和提高程序响应速度这几点内容。

接着我们介绍了Go语言中实现超时控制的方法,包括使用time实现超时控制以及使用context实现超时控制,并给出了简单的代码示例。

在接下来,我们便这两种实现的适用场景进行分析,明确了在哪些场景下,适合使用time实现超时控制,以及在哪些场景下,使用timerCtx来实现更为高效。

基于此,完成了为什么需要超时控制的介绍,希望能够让大家在遇到需要超时控制的场景下,更好得去进行实现。

标签:为什么,timerCtx,控制,实现,context,time,超时
From: https://www.cnblogs.com/chenjiazhan/p/17379431.html

相关文章

  • 还原k8s控制节点
    0、基础环境配置参照节点建立搭建配置1、从旧控制节点拷贝/opt/kubernets/usr/local/bin/kubectl/usr/lib/systemd/system/etcd.service/usr/lib/systemd/system/kube-apiserver.service/usr/lib/systemd/system/kube-controller-manager.service/usr/lib/systemd/system/ku......
  • SpringCloud gateway 元数据,超时,Netty Access Logs
    元数据spring:cloud:gateway:routes:-id:route_with_metadatauri:https://example.orgmetadata:optionName:"OptionValue"compositeObject:name:"value"iAmNu......
  • Druid 查询超时配置的探究 → DataSource 和 JdbcTemplate 的 queryTimeout 到底谁生
    前情回顾还记得记一次Druid超时配置的问题→引发对Druid时间配置项的探究遗留的问题吗?如果同时设置 DataSource 的 queryTimeout 和 JdbcTemplate 的 queryTimeout ,那么哪个 queryTimeout 生效?实践出结果想快速知道答案,做法很简单,两个都设置,看生......
  • TCP协议三次握手的原因是什么?为什么不用两次握手和4次握手?
    今天复习了TCP协议的三次握手,对上一篇C++网络编程有了更深的理解。当时考研的时候计网学过,这里再总结一下分享。网图都是截图来的,侵删。TCP协议属于传输层协议,上面的应用层协议包括HTTP、FTP之类,应用层协议是最接近用户的,每往下一层就套一层头部数据来提供给当前层协议解析。那......
  • 基于PSO优化BP神经网络PID控制器matlab仿真
    1.算法仿真效果matlab2022a仿真结果如下:      2.算法涉及理论知识概要       PID控制器(比例-积分-微分控制器),由比例单元P、积分单元I和微分单元D组成。通过Kp,Ki和Kd三个参数的设定。PID控制器主要适用于基本线性和动态特性不随时间变化的系统。......
  • 为什么说程序=算法+数据结构
    听到`程序=数据结构+算法`,可能很多同学觉得不太好理解。那么如果我说`程序=变量+业务`,是不是就好理解了。其实我们开发一款应用程序,就是定义一些变量,然后围绕这些变量进行业务的开展。理解了,我们再来说。变量只是统称,我们可能针对不同的业务使用不同的变量类型(数据结构),来......
  • 【Redis】-使用Lua脚本解决多线程下的超卖问题以及为什么?
    一.多线程下引起的超卖问题呈现1.1.我先初始化库存数量为1、订单数量为01.2.开启3个线程去执行业务业务为:判断如果说库存数量大于0,则库存减1,订单数量加1结果为:库存为-2,订单数量为3原因:如下图所示,这是因为分别有6个指令(3个库存减1指令,3个订单数量加1指令)在redis服务端执行导致......
  • 为什么设备厂商对在线报修平台”情有独钟“?
    在过去的几年中,我们已经看到了一些新兴的在线报修平台的涌现,这些平台向客户提供了无缝的报修服务,使其可以快速准确地获得解决问题的方案。然而,这种服务并不仅仅受到客户的欢迎,越来越多的设备厂商也对这种平台情有独钟。那么,到底是什么原因让这些厂商如此青睐在线报修平台呢?1、能够......
  • pytest之 为什么要做接口自动化
    行情:会接口自动化15-25k工具类实现接口自动化:增加2-3kPostman+newman+git+jenkinsJmeter+Ant+jenkins 一,既然有这些接口测试工具,为什么要做接口自动化?1.敏捷开发,接口一般数量很大,团队需要实现接口测试,多人协作写用例还需要“版本控制”2.功能太死板,有些接口完全无法实现......
  • 第五章 输入输出系统 5.2 I/O设备和设备控制器
    一、I/O设备 1.I/O设备的类型 2.设备与控制器之间的接口 设备并不是直接与CPU进行通信,而是与设备控制器通信,因此,在设备与设备控制器之间应有一接口。  ①数据信号线:在设备与控制器之间传送数据信号。双向,有缓存。  ②状态信号线:传送指示设备当前状态的信号......