Go-知识-定时器

Go-知识-定时器

  • 1. 介绍
  • 2. Timer使用场景
    • 2.1 设定超时时间
    • 2.2 延迟执行某个方法
  • 3. Timer 对外接口
    • 3.1 创建定时器
    • 3.2 停止定时器
    • 3.3 重置定时器
    • 3.4 After
    • 3.5 AfterFunc
  • 4. Timer 的实现原理
    • 4.1 Timer数据结构
      • 4.1.1 Timer
      • 4.1.2 runtimeTimer
    • 4.2 Timer 实现原理
      • 4.2.1 创建Timer
      • 4.2.2 停止Timer
      • 4.2.3 重置Timer
  • 5. Ticker 使用场景
    • 5.1 简单定时任务
    • 5.2 定时刷新缓存
  • 6. Ticker 对外接口
    • 6.1 创建定时器
    • 6.2 停止定时器
    • 6.3 Tick
  • 7. Ticker 实现原理
    • 7.1 数据结构
      • 7.1.1 Ticker
      • 7.1.2 runtimeTimer
    • 7.2 Ticker实现原理
      • 7.2.1 创建Ticker
      • 7.2.2 停止Ticker
  • 8. runtimeTimer 原理(go 1.11)
    • 8.1 定时器存储
      • 8.1.1 timer 的数据结构
      • 8.1.2 timersBucket 的数据结构
      • 8.1.3 Ticker & timer & timersBucket 关系
      • 8.1.4 timersBucket 数组
    • 8.2 定时器运行机制
      • 8.2.1 创建定时器
      • 8.2.2 删除定时器
    • 8.3 资源泄露
  • 9. 性能优化 (go 1.14+)
    • 9.1 消除了timersBucket
    • 9.2 消除了timeproc
    • 9.3 更少的锁竞争
    • 9.4 更少的上下文切换
    • 9.5 优化效果

Go语言提供了两种定时器,分别为一次性定时器和周期性定时器。

  • 一次性定时器(Timer):定时器只计时一次,计时结束变停止运行。
  • 周期性定时器(Ticker):定时器周期性进行计时,除非主动停止,否则将永久运行。

以下都是 go 1.10~1.13的逻辑,在go 1.14 有非常大的优化。

1. 介绍

Timer是一种单一事件的定时器,即经过指定的时间后触发一个事件,这个事件通过其本身提供的
channel进行通知。Timer只执行一次就结束。
通过timer.NewTimer(d Duration)可以创建一个Timer,参数即等待时间,时间到来后立即触发一个事件。
src/time/sleep.go中定义了Timer的数据结构
在这里插入图片描述

Timer对外仅暴露一个channel,指定的时间到来时就往该channel种写入系统时间,即一个事件。

Ticker是周期性定时器,即周期性地触发一个事件,通过Ticker本身提供的channel将事件传递出去。
Ticker的数据结构与Timer非常类似:
在这里插入图片描述

Ticker对外仅暴露一个channel,当指定的时间到来时就往该channel种写入系统时间,即一个事件。
在创建Ticker时会指定一个时间,作为事件触发的周期,这是Ticker和Timer最主要的区别。

2. Timer使用场景

2.1 设定超时时间

有时候在等待资源的时候,又不希望永久等待,而是希望加个超时时间,如果在指定的时间还未获取到,那么就超时,不在等待了。

func TestWait(t *testing.T) {timer := time.NewTimer(1 * time.Second)c := make(<-chan string)select {case <-c:t.Log("chan string ")case <-timer.C:t.Log("time out")}
}

因为case <-c 不会触发,所以在1秒后,超时结束
在这里插入图片描述

通过select语句轮询timer.C 和 c 两个channel,如果1s内,c还没有数据写入,那就认为超时了。

2.2 延迟执行某个方法

在应用启动中,一般会初始化很多组件,如果在应用启动后,马上就使用,可能出现组件还未初始化成功,拿到的组件对象是还未准备好的对象。
这个时候,如果能延迟使用,那么就不会出现使用未准备好的组件的情况。

func TestDelay(t *testing.T) {timer := time.NewTimer(1 * time.Second)select {case <-timer.C:t.Log("wait 1 s")}t.Log("do something")
}

select 只有一个case,就是当时间到了,该case满足,如果时间没到,那么select会阻塞。
当触发select 后,可以什么都不做,也可以打印日志,然后跳出select的语句,顺序执行后续逻辑,以此实现延迟等待后执行。
在这里插入图片描述

3. Timer 对外接口

3.1 创建定时器

使用func NewTimer(d Duration) *Timer方法指定一个时间即可创建一个Timer,Timer一经创建便开始计时,不需要额外的启动命令。
实际上,创建Timer意味着把一个计时任务交给系统守护协程,该协程管理着所有的Timer,当Timer的时间到达后,Timer向Channel中发送当前的时间作为事件。

3.2 停止定时器

Timer创建后可以随时停止,停止计时器的方法如下:
func (t *Timer) Stop() bool
其返回值代表定时器有没有超时。

  • true : 定时器超时前停止,后续不会在发送事件
  • false : 定时器超时后停止。

实际上,停止计时器意味着通知系统守护协程移除该定时器。

3.3 重置定时器

已过期的定时器或已停止的定时器可以通过重置动作重新激活,重置方法如下:
func (t *Timer) Reset(d Duration) bool
重置的动作实质上是先停止定时器,在启动,其返回值即停止计时器(Stop()) 的返回值。
需要注意的是,重置定时器虽然可以用于修改还未超时的定时器,但正确的使用方式还是针对已过期的定时器或已被停止的定时器,同时其返回值也不可靠,返回值存在的价值仅仅是与前面的版本兼容。
实际上,重置定时器意味着通知系统守护协程移除该定时器,重新设定时间后,再把定时器交给守护协程。

3.4 After

如果仅仅是向等待指定的时间,没有提前停止定时器的需求,也没有复用该定时器的需求,那么可以使用匿名的定时器。
使用func After(d Duration) <-chan Time方法创建一个定时器,并返回定时器的管道。

func TestAfter(t *testing.T) {select {case <-time.After(1 * time.Second):t.Log("after 1 s")}
}

执行后和之前的延迟执行一模一样:
在这里插入图片描述

实际上还是一个定时器,但是代码更加简洁。

3.5 AfterFunc

除了 After调用,返回 channel,进行同步处理,还可以使用 AfterFunc,将需要延迟的操作交给系统协程异步执行。
AfterFunc的定义: func AfterFunc(d Duration, f Func()) *Timer
比如:

func TestAfterFunc(t *testing.T) {time.AfterFunc(1*time.Second, func() {t.Log("after 1 s")})t.Log("waiting")time.Sleep(2 * time.Second)t.Log("done")
}

执行结果如下:
在这里插入图片描述

很明显执行和等待已经不是一个协程了.

4. Timer 的实现原理

4.1 Timer数据结构

4.1.1 Timer

在源码包src/time/sleep.go中定义了其数据结构:
在这里插入图片描述

Timer只有两个成员:

  • C:channel ,上层应用根据此channel接收事件
  • r:runtime定时器,该定时器即系统管理的定时器,对上层应用不可见。

这里按照层次来理解Timer的数据结构,Timer.C是面向Timer用户的,Timer.r是面向底层的定时器实现。

4.1.2 runtimeTimer

创建一个Timer实质上是把一个定时任务交给专门的写成进行监控,这个任务的载体便是runtimeTimer。
每创建一个Timer意味着创建了一个runtimeTimer变量,然后把它交给系统进行监控。通过设置runtimeTimer过期后的行为来达到定时的目的。

type runtimeTimer struct {tb     uintptr                    // 存储当前定时器的数组地址i      int                        // 存储当前定时器的数组下标when   int64                      // 当前定时器触发事件period int64                      // 当前定时器周期性触发间隔f      func(interface{}, uintptr) // 定时器触发时执行的回调函数arg    interface{}                // 定时器触发时执行回调函数传递的参数一seq    uintptr                    // 定时器触发时执行回调函数传递的参数二
}
  • tb: 系统底层存储runtimeTimer的数组地址
  • i: 当前runtimeTime在tb数组中的下标
  • when: 定时器触发事件的时间
  • period: 定时器周期性触发间隔(对于Timer来说,此值为0)
  • f: 定时器触发时执行的回调函数,回调函数接收两个参数。
  • arg: 定时器触发时执行回调函数的参数一
  • seq: 定时器触发时执行回调函数的参数二(Timer并不使用该参数)

4.2 Timer 实现原理

一个进程中的多个Timer都由底层的写成来管理,这个协程称为系统协程。
runtimeTimer存放在数组中,并看招when字段对所有的runtimeTimer进行堆排序,定时器触发时执行runtimeTimer中的预定义函数f,即完成了一次定时任务。

4.2.1 创建Timer

创建Timer的实现,非常简单:

func NewTimer(d Duration) *Timer {c := make(chan Time, 1) // 创建一个channelt := &Timer{ // Timer的数据结构C: c,r: runtimeTimer{when: when(d), // 触发事件f:    sendTime, // 触发后执行 sendTime 函数arg:  c, // 触发后执行sendTime函数时附带的参数},}startTimer(&t.r) // 此处启动定时器,只是把 runtimeTimer放到系统协程的堆中,由系统协程维护return t
}

NewTimer函数只是构造了一个Timer,然后把Timer.r 通过startTimer()交给系统协程维护。其中when()方法是计算下一次
定时器触发的绝对时间,即当前时间+NewTimer()的参数d。sendTimer()方法是定时器触发时的动作。

  • when函数
// when是一个辅助函数,用于设置runtimeTimer的“when”字段。
// 它返回未来的持续时间d,单位为纳秒。
// 如果d为负,则忽略。如果返回值小于
// 由于溢出,返回MaxInt64。
func when(d Duration) int64 {if d <= 0 {return runtimeNano()}t := runtimeNano() + int64(d)if t < 0 {t = 1<<63 - 1 // math.MaxInt64}return t
}
  • sendTimer函数
func sendTime(c interface{}, seq uintptr) {//c上的非阻塞时间发送。//在NewTimer中使用,它无论如何都不能阻塞(缓冲区)。//在NewTicker中使用,在地板上放下发送是//当读者落后时的期望行为,//因为发送是周期性的。select {case c.(chan Time) <- Now():default:}
}

sendTime接收一个channel作为参数,其主要任务是向channel中写入当前时间。
创建Timer时生成的管道含有一个缓冲区(make(chan Time,1)),所以Timer触发时向channel写入事件永远不会阻塞,sendTime写完即退出。
sendTime使用select搭配一个空的default分支,是因为Ticker也复用了sendTime,Ticker触发时也会向channel中写入事件,但无法保证之前的数据已经
被取走,所以使用select并搭配一个空的default分支,确保sendTime不会阻塞,Ticker触发时,如果管道中还有值,则本次不在向管道中写入时间,将本次触发的事件直接丢弃。

  • startTime函数

startTime函数的具体实现在runtime包中,其主要作用是把runtimeTimer写入系统写成的数组中,并启动系统协程(如果系统协程还未开始运行)
在这里插入图片描述

其主要是addTimer(t *timer)函数,timer是runtime包中用于表示time包中runtimeTimer结构的struct
在这里插入图片描述

addTimer(t *timer)函数

func addtimer(t *timer) {tb := t.assignBucket() // 获取time桶数组lock(&tb.lock) // 加锁ok := tb.addtimerLocked(t) // 将 timer加入数据组unlock(&tb.lock) // 解锁if !ok { // 如果timer加入数组失败,那么触发 panic badTimer()}
}

在这里插入图片描述

4.2.2 停止Timer

停止Timer,只是简单地把Timer从系统协程中移除。
在这里插入图片描述

stopTimer即通知系统协程把该Timer移除,即不在监控。
stopTimer也是runtime中的函数
在这里插入图片描述

系统协程只是移除Timer,并不会关闭channel,以避免用户协程读取错误。
Stop 的返回值取决于定时器的状态:

  • 如果Timer已经触发,则Stop返回false
  • 如果Timer还未触发,则Stop返回true

在这里插入图片描述

4.2.3 重置Timer

重置Timer时会先把Timer从系统协程中删除,修改新的时间后重新添加到系统协程中。
重置的实现如下:
在这里插入图片描述

其返回值与Stop保持一致,如果Timer成功停止,则返回true,如果Timer已经触发,则返回false.
在这里插入图片描述

由于新加的Timer时间很可能变化,所以其在系统协程中的位置也会相应地发生变化。
需要注意的是,按照源码注释,Reset应该作用于已经停止的Timer或已经触发的Timer。
按照这个约定,Reset的返回值总是false,仍然保留是为了保持向前兼容,使用老版本Go编写的应用不需要因为Go升级而修改代码。
如果不按照此约定使用Reset,则有可能遇到Reset和Timer触发后同时执行的情况,此时有可能会收到两个事件,从而对应用程序造成一些负面影响。

5. Ticker 使用场景

5.1 简单定时任务

假设需求是每隔1秒就报时一次:

func TestTicker(t *testing.T) {// 创建一个一秒的Tickerticker := time.NewTicker(1 * time.Second)// 使用defer关闭Tickerdefer ticker.Stop()// 收到事件就打印时间 (根据之前Timer的实现,res := <-ticker.C , res 就是 Time 类型的时间戳 )for range ticker.C {t.Log("tick 1 s : " + time.Now().String())}
}

在这里插入图片描述

如果不主动停止,那么永远不会结束。

5.2 定时刷新缓存

假设需求是定时将内存中的数据写到磁盘中,或者内存中数据满了,需要落盘:

func TestFlush(t *testing.T) {// 创建一个每1秒刷新一次的Tickerticker := time.NewTicker(1 * time.Second)// 使用 defer 关闭defer ticker.Stop()// 模拟内存数据mem := 0for {select {// 时间到,不管如何,必须刷新case <-ticker.C:t.Log("flush 1 s : " + time.Now().String())default:// 内存满了,需要刷新if mem > 15 {t.Logf("flush mem : %d", mem)mem = 0}}// 每次for循环设置随机值mem += rand.Intn(10)// 每次循环等待300毫秒time.Sleep(300 * time.Millisecond)}
}

在这里插入图片描述

6. Ticker 对外接口

6.1 创建定时器

使用NewTicker函数就能创建一个Ticker

// NewTicker返回一个新的Ticker,其中包含一个将发送
// 由duration参数指定的时间段。
// 它调整间隔或降低滴答声,以弥补接收器速度慢的问题。
// 持续时间d必须大于零;否则,NewTicker将会恐慌。
// 停止自动收报机以释放相关资源。
func NewTicker(d Duration) *Ticker {if d <= 0 {panic(errors.New("non-positive interval for NewTicker"))}c := make(chan Time, 1)t := &Ticker{C: c,r: runtimeTimer{when:   when(d),// Timer 的 period 是 0period: int64(d),f:      sendTime,arg:    c,},}startTimer(&t.r)return t
}

NewTimer和NewTicker非常类似,在初始化runtimeTimer的时候,Timer没有设置period,Ticker则设置period等于d.

6.2 停止定时器

使用定时器对外暴露的Stop方法就可以停止Ticker
在这里插入图片描述

其实不管是 Timer还是Ticker的startTimer和stopTimer,最终都是由runtime/time.go 中的timer的startTimer和stopTimer实现的
在这里插入图片描述

在这里插入图片描述

需要注意的是,该方法会停止计时,意味着不会向定时器的channel中写入事件,但是channel并不会给关闭,channel在使用完后,声明周期结束后会自动释放。

Ticker 在使用完后务必要释放,否则会产生资源泄露,进而会持续消耗CPU资源,最后会把CPU资源消耗完。

6.3 Tick

在有些长江下,启动一个Ticker后,该Ticker永远不会停止,比如定时轮询任务,此时可以使用一个简单的Tick函数来获取定时器的channel。
在这里插入图片描述

注释上面说的很明白,因为该函数内部实际上还是创建了一个Ticker,但是并没有返回,只是返回了channel,因为没有Ticker对象,所以没法调用Stop。

在for循环中,使用Ticker的时候,一定三思
在Timer中,很容易写出如下代码:

for {select {case <-time.After(1 * time.Second):t.Log("flush 1 s : " + time.Now().String())}
} ```

使用Timer这样写当然没错,因为Timer在触发事件后,就会从数组中移除。
但是当把Timer换成Ticker,那么就出现了资源泄露

for {select {case <-time.Tick(1 * time.Second):t.Log("flush 1 s : " + time.Now().String())}
}```

上面的代码出现了资源泄露,因为 Tick 会创建Ticker,并且因为使用Tick直接获取的Ticker.C,所以没有手段去Stop。
随着for的执行,最终会导致越来越多的Ticker耗尽CPU资源。

7. Ticker 实现原理

实际上Ticker与Timer几乎完全相同,数据结构和内部实现机制都相同,唯一不同的是创建方式。
在创建Timer时,不指定时间触发周期,时间触发后Timer自动销毁。而在创建Ticker时会指定一个事件触发周期,事件按照这个周期触发,如果不显式停止,则定时器永不停止。

7.1 数据结构

7.1.1 Ticker

Ticker的数据结构与Timer的数据结构除名字不同外,其他完全一样。
源码包src/time/tick.go中定义了数据结构
在这里插入图片描述

Ticker只有两个成员:

  • C: channel,上层应用根据此channel接收事件。
  • r: runtimeTimer定时器,该定时器即系统管理的定时器,对上层应用不可见。

按照层次来理解Ticker的数据结构,Ticker.C 是面向Ticker 用户的,Ticker.r 是面向底层的定时器的。

7.1.2 runtimeTimer

runtimeTimer和Timer的一样,创建一个Timer实质上是把一个定时任务交给专门的写成进行监控,这个任务的载体便是runtimeTimer。
每创建一个Timer意味着创建了一个runtimeTimer变量,然后把它交给系统进行监控。通过设置runtimeTimer过期后的行为来达到定时的目的。

type runtimeTimer struct {tb     uintptr                    // 存储当前定时器的数组地址i      int                        // 存储当前定时器的数组下标when   int64                      // 当前定时器触发事件period int64                      // 当前定时器周期性触发间隔f      func(interface{}, uintptr) // 定时器触发时执行的回调函数arg    interface{}                // 定时器触发时执行回调函数传递的参数一seq    uintptr                    // 定时器触发时执行回调函数传递的参数二
}
  • tb: 系统底层存储runtimeTimer的数组地址
  • i: 当前runtimeTime在tb数组中的下标
  • when: 定时器触发事件的时间
  • period: 定时器周期性触发间隔(对于Timer来说,此值为0)
  • f: 定时器触发时执行的回调函数,回调函数接收两个参数。
  • arg: 定时器触发时执行回调函数的参数一
  • seq: 定时器触发时执行回调函数的参数二(Timer并不使用该参数)

7.2 Ticker实现原理

7.2.1 创建Ticker

创建Ticker的实现非常简单:

func NewTicker(d Duration) *Ticker {if d <= 0 {panic(errors.New("non-positive interval for NewTicker"))}c := make(chan Time, 1)t := &Ticker{C: c,r: runtimeTimer{when:   when(d),period: int64(d), // 这个在Timer中是没有的f:      sendTime,arg:    c,},}startTimer(&t.r)return t
}

Ticker 和Timer的重要区别就是提供了period参数,据此决定Timer是一次性的,还是周期性的。
NewTicker只是构造了一个Ticker,然后把Ticker通过startTimer交给系统协程维护。
其中period为事件触发的周期,sendTime函数是定时器触发时的动作。

  • sendTimer函数
func sendTime(c interface{}, seq uintptr) {//c上的非阻塞时间发送。//在NewTimer中使用,它无论如何都不能阻塞(缓冲区)。//在NewTicker中使用,在地板上放下发送是//当读者落后时的期望行为,//因为发送是周期性的。select {case c.(chan Time) <- Now():default:}
}

sendTime接收一个channel作为参数,其主要任务是向channel中写入当前时间。
创建Timer时生成的管道含有一个缓冲区(make(chan Time,1)),所以Timer触发时向channel写入事件永远不会阻塞,sendTime写完即退出。
sendTime使用select搭配一个空的default分支,是因为Ticker也复用了sendTime,Ticker触发时也会向channel中写入事件,但无法保证之前的数据已经
被取走,所以使用select并搭配一个空的default分支,确保sendTime不会阻塞,Ticker触发时,如果管道中还有值,则本次不在向管道中写入时间,将本次触发的事件直接丢弃。

  • startTime函数

startTime函数的具体实现在runtime包中,其主要作用是把runtimeTimer写入系统写成的数组中,并启动系统协程(如果系统协程还未开始运行)
在这里插入图片描述

其主要是addTimer(t *timer)函数,timer是runtime包中用于表示time包中runtimeTimer结构的struct
在这里插入图片描述

addTimer(t *timer)函数

func addtimer(t *timer) {tb := t.assignBucket() // 获取time桶数组lock(&tb.lock) // 加锁ok := tb.addtimerLocked(t) // 将 timer加入数据组unlock(&tb.lock) // 解锁if !ok { // 如果timer加入数组失败,那么触发 panic badTimer()}
}

在这里插入图片描述

7.2.2 停止Ticker

停止Ticker时,只是简单地把Ticker从系统协程中移除。
在这里插入图片描述

stopTimer即通知系统协程把该Ticker移除,即不在监控。
stopTimer也是runtime中的函数
在这里插入图片描述

系统协程只是移除Ticker,并不会关闭channel,以避免用户协程读取错误。
与Timer不同的是,Ticker停止时没有返回值,即不需要关注返回值,实际上返回值也没有什么用途。
在这里插入图片描述

Ticker 没有重置接口,即Ticker创建后不能通过重置修改周期。

需要格外注意的是,Ticker用完后必须主动停止,否则会产生资源泄露,持续消耗CPU资源。

8. runtimeTimer 原理(go 1.11)

NewTimer和NewTicker都会在底层创建一个runtimeTimer,runtime包负责管理runtimeTimer,保证定时器按照约定的时间触发。

  • Go 1.10 之前: 所有的runtimeTimer 保存在一个全局的堆中
  • G0 1.10 ~ 1.13 : runtimeTimer被拆分到多个全局的堆中,减少了多个系统协程的锁等待时间
  • Go 1.14+: runtimeTimer保存在每个处理器P中,消除了专门的系统协程,减少了系统协程上下文切换。

8.1 定时器存储

8.1.1 timer 的数据结构

Timer和Ticker的数据结构除名字外,其他完全一样,二者都含有一个runtimeTimer类型的成员,这就是系统协程所维护的对象。
runtimeTimer类型是time包的名字,在runtime包中,这个类型叫做timer.

// 包装时间知道这个结构的布局。
// 如果此结构更改,请调整/time/sleep.go:/runtimeTimer。
// 对于GOOS=nacl,包syscall知道这个结构的布局。
// 如果此结构更改,请调整/syscall/net_nacl.go:/runtimeTimer。
type timer struct {tb *timersBucket // the bucket the timer lives in // 当前定时器寄存于系统timer堆的地址i  int           // heap index // 当前定时器寄存于系统timer堆的下标//定时器在何时唤醒,然后在何时+时段唤醒。。。(仅限大于0的时段)//每次在计时器goroutine中调用f(arg,now)时,f必须//一个行为良好的函数,而不是块。when   int64                      // 当前定时器下次触发时间period int64                      // 当前定时器周期性触发间隔(如果是Timer,间隔为0,表示不重复触发)f      func(interface{}, uintptr) // 定时器触发时执行的函数arg    interface{}                // 定时器触发时执行的参数一seq    uintptr                    // 定时器触发时执行的参数二(该参数只在网络收发场景下使用)
}

其中timersBucket便是系统协程存储timer的容器,里面有一个切片来存储timer,而i便是timer所在切片的下标。

8.1.2 timersBucket 的数据结构

//go:notinheap
type timersBucket struct {lock         mutexgp           *g       // 处理堆中事件的协程created      bool     // 时间处理协程是否已创建,默认为false,添加收个定时器是置为truesleeping     bool     // 事件处理协程(gp)是否在睡眠,(如果t中有定时器,那么还未到达触发的时间,gp会睡眠)rescheduling bool     // 事件处理协程(gp)是否已暂停,(如果t中定时器均已删除,那么gp会暂停)sleepUntil   int64    // 时间处理协程睡眠事件waitnote     note     // 时间处理协程睡眠事件(据此唤醒协程)t            []*timer // 定时器切片
}

Bucket是存储timer的桶。

  • lock: 互斥锁,在timer增加和删除时需要加锁,防止并发
  • gp: 事件处理协程,就是系统协程,这个协程在首次创建Timer或Ticker时生成
  • created: 状态值,表示系统协程是否创建
  • sleeping: 系统协程是否已暂停
  • sleepUntil: 系统协程睡眠到指定的时间(如果有新的定时任务则可能会提前唤醒)
  • waitnote: 提前唤醒时使用的通知
  • t: 保存timer的切片,当调用NewTimer或NewTicker时,便会有新的timer存储到切片中

系统协程在首次创建定时器时创建,定时器存储在切片中,系统写成负责计时并维护这个切片。

8.1.3 Ticker & timer & timersBucket 关系

假设创建了1个Timer,2个Ticker,关系如下
在这里插入图片描述

用户创建Timer或者Ticker时会生成一个timer,这个timer指向timersBucket,timersBucket记录timer的指针。

8.1.4 timersBucket 数组

通过timersBucket的数据结构可以看到,系统写成负责计时并维护其中的多个timer,一个timersBucket由一个特定的系统协程来维护。
当系统重的定时器非常多时,一个系统协程的处理能力可能跟不上,所以Go在实现时实际上提供了多个timerBucket,也就是有多个系统协程来处理定时器。
最理想的情况是应该预留GOMAXPROCS个timersBucket,以便充分使用CPU资源,但需要根据实际环境动态分配。为了实现简单,Go在实现时预留了64个timersBucket,可以满足绝大部分场景。
在这里插入图片描述

在addTimer时调用的
在这里插入图片描述

当协程创建定时器时,使用协程所属的ProcessId%64来计算定时器存入的timersBucket。
在上面的关系中,当三个协程创建定时器时,定时器的分布可能如下:
在这里插入图片描述

一般情况下,同一个Process的协程创建的定时器分布于同一个timersBucket中,只有当GOMAXPROCS大于64时才会出现多个Process分布于同一个timersBucket中的情况。

8.2 定时器运行机制

8.2.1 创建定时器

创建Timer或Ticker实际上分为两步:

  • 创建一个channel
  • 创建一个timer并启动(这里的timer是指runtime包中的timer,不是Timer)

在这里插入图片描述

在这里插入图片描述

不管是 Timer还是Ticker都是先创建channel,channel都是带有一个缓冲区的。
接着创建timer,调用startTimer启动。
startTimer在runtime包中实现,通过go:link关联
在这里插入图片描述

addTimer的实现如下:

func addtimer(t *timer) {tb := t.assignBucket()     // 分配 timersBucket ,从64个中选择一个lock(&tb.lock)             // 加锁ok := tb.addtimerLocked(t) // 加入切片unlock(&tb.lock)           // 解锁if !ok {                   // 加入失败badTimer() // 错误处理}
}

首先,每个timer都必须归属于某个timersBucket,所以第一步是先选择一个timersBucket,选择的算法很简单,将当前协程所属的Process ID 与 timersBucket数据长度求模,结果就是timersBucket数组的下标。
在这里插入图片描述

其次,每个timer都必须加入timersBucket,timersBucket数据结构中的切片t保存着timer的指针,新创建的timer也需要加入这个切片。
保存timer的切片是一个按timer触发事件排序的小顶堆,所以新timer插入的过程中会触发堆调整,堆顶的timer最快被触发。

// 在堆中添加一个计时器,并在新计时器为时启动或启动timerproc
// 比其他任何人都早。
// 计时器已锁定。
// 返回是否一切正常:如果数据结构损坏,则返回false
// 由于用户级别的竞争。
func (tb *timersBucket) addtimerLocked(t *timer) bool {//何时决不能为负数;否则timerproc将溢出//在其增量计算期间,并且永远不会使其他运行时计时器过期。if t.when < 0 {t.when = 1<<63 - 1}t.i = len(tb.t)              // 先把定时器插入堆尾tb.t = append(tb.t, t)       // 保存定时器if !siftupTimer(tb.t, t.i) { // 在堆中插入数据,触发重新排序return false}if t.i == 0 { // 堆排序后,如果新插入的定时器跑到了堆顶,需要唤醒系统协程来处理// siftup moved to top: new earliest deadline.if tb.sleeping && tb.sleepUntil > t.when { // 系统协程在睡眠(切片中有数据,未到时间),唤醒系统协程来处理新加入的定时器tb.sleeping = falsenotewakeup(&tb.waitnote)}if tb.rescheduling { // 系统协程已暂停(切片中没有数据),唤醒系统协程来处理新加入的定时器tb.rescheduling = falsegoready(tb.gp, 0)}if !tb.created { // 如果是系统协程收个定时器,则启动协程处理堆中的定时器tb.created = truego timerproc(tb) // 系统协程就是这里创建的}}return true
}
  • 如果timer的时间是负值,那么就会被修改为很大的值来保证后续定时算法的正确性
  • 系统协程是在首次添加timer时创建的,并不是一直存在
  • 新加入timer后,如果新的timer跑到了堆顶,则意味着新的timer需要立即处理,那么会唤醒系统协程

小顶堆排序

func siftupTimer(t []*timer, i int) bool { // 入参是数组和数组尾部if i >= len(t) {return false} // 数组越界when := t[i].when // 获取数组尾部元素的触发事件tmp := t[i]       // 存储到临时变量中for i > 0 {       // 只要没到堆顶,那么就一直运行p := (i - 1) / 4       // parent // 使用 4 叉堆,所以 (i-1)/4 得到父节点if when >= t[p].when { // 如果 子节点的触发事件大于等于 父节点,那么结束,满足小顶堆的规则break // 满足小顶堆的规则,结束}t[i] = t[p] // 否则先将父节点 写到 子节点位置上,(子节点在临时变量中有,不会丢失)t[i].i = i  // 将 timersBucket中的index 设置为子节点的indexi = p       // 将指针移动到父节点,进行下一轮循环(因为使用数组保存树,所以当index=0时,就到达了根节点)}if tmp != t[i] { // 判断是否发生了并发,理论上 tmp 就是 t[i]t[i] = tmp // 如果并发导致数据不一致,那么强行设置t[i].i = i}return true
}

这是用数组存储的一个小顶堆的维护逻辑。

创建系统协程
当第一次addTimer的时候,会触发创建系统协程:

// Timerproc运行时间驱动的事件。
// 它一直休眠到tb堆中的下一个事件。
// 如果addtimer插入一个新的较早事件,它会提前唤醒timerproc。
func timerproc(tb *timersBucket) {tb.gp = getg() // 获取协程for {lock(&tb.lock)      // 加锁tb.sleeping = false // 设置标志now := nanotime()   // 获取当前时间delta := int64(-1)for {if len(tb.t) == 0 { // 切片数组为空,堆中没有等待的元素delta = -1 // 不创建系统协程,结束break}t := tb.t[0]         // 拿到小顶堆堆顶的元素delta = t.when - now // 计算需要等待的时间if delta > 0 {       // 如果还未到时间,结束,delta 大于0表示时间未到,小于0表示已过时执行break}ok := trueif t.period > 0 { // Ticker 的 period 才会大于0, Timer 的 period 等于0// leave in heap but adjust next time to firet.when += t.period * (1 + -delta/t.period)// delta小于0,表示本次是过时执行,那么下次执行时间需要加上delta,比如delta=1s,那么下次执行时间 when(next) = when(this) + period + delta// 将上述式子进行变形 when(next) = when(this) + period (1 + delta/period)// 因为已知delta <= 0 ,所以 when(next)=when(this) + period * (1 + -delta/period) => when += period * (1 + -delta/period)if !siftdownTimer(tb.t, 0) { // 将根节点值进行了增加,那么从 小堆顶 进行平衡ok = false}} else { // period = 0 表示是 Timer,触发一次后,需要从小顶堆中删除// remove from heaplast := len(tb.t) - 1 // 切片长度缩小if last > 0 {         // 小顶堆不为空tb.t[0] = tb.t[last] // 将最大值设置到根节点,然后执行 根节点值增加,然后从 小堆顶进行平衡tb.t[0].i = 0}tb.t[last] = nil   // 将最后一个元素置空,删除,显示的置空,用于 gctb.t = tb.t[:last] // 将最后一个元素删除if last > 0 {      // 如果 小顶堆不为空,那么从根节点进行平衡if !siftdownTimer(tb.t, 0) {ok = false}}t.i = -1 // mark as removed // 标记该 timer 已经被删除了,无法通过 index 在 timersBucket中索引到了}f := t.f         // 拿到 触发后的 funcarg := t.arg     // 获取第一个参数,channel , Timer.C or Ticker.Cseq := t.seq     // 获取第二个参数,只有网络才会用到unlock(&tb.lock) // 解锁if !ok {         // 如果小顶堆平衡失败,那么返回错误信息badTimer()}if raceenabled {raceacquire(unsafe.Pointer(t))}f(arg, seq)    // 执行预设的 func ,也就是 sendTime , 也就是将 now 写入 Timer.C 或 Ticker.C 触发事件lock(&tb.lock) // 加锁,防止多次触发,分两次加锁解锁,是为了防止执行 sendTime 的时候,太费时间,导致协程无法进行其他操作}if delta < 0 || faketime > 0 { // 小顶堆中没有元素了,系统协程需要暂停// No timers left - put goroutine to sleep.tb.rescheduling = true // 设置暂停标志goparkunlock(&tb.lock, waitReasonTimerGoroutineIdle, traceEvGoBlock, 1)continue}// At least one timer pending. Sleep until then.tb.sleeping = true               // 没有待触发的事件,设置睡眠标志tb.sleepUntil = now + delta      // 计算系统协程睡眠时间noteclear(&tb.waitnote)          // 清除系统协程的唤醒通知unlock(&tb.lock)                 // 解锁notetsleepg(&tb.waitnote, delta) // 系统协程睡眠,没有待触发的事件}
}

唤醒系统协程(睡眠)
当有定时器需要触发的时候,会唤醒系统协程,触发事件:

func notewakeup(n *note) {var v uintptrfor { // 加锁,乐观锁,自旋v = atomic.Loaduintptr(&n.key)if atomic.Casuintptr(&n.key, v, locked) {break}}// Successfully set waitm to locked.// What was it before?switch {case v == 0:// Nothing was waiting. Done.case v == locked:// Two notewakeups! Not allowed.throw("notewakeup - double wakeup")default:// Must be the waiting m. Wake it up.semawakeup((*m)(unsafe.Pointer(v))) // 唤醒,唤醒后,进入 timerproc 的 for 循环,再次触发事件, 当小顶堆没有触发的定时器时,协程会在for最后一步sleep,唤醒后继续执行}
}

唤醒,唤醒后,进入 timerproc 的 for 循环,再次触发事件, 当小顶堆没有触发的定时器时,协程会在for最后一步sleep,唤醒后继续执行.

唤醒系统协程(暂停)
当小顶堆中没有元素,系统协程会进入暂停状态,等待addTimer

func goready(gp *g, traceskip int) {systemstack(func() {ready(gp, traceskip, true)})
}

睡眠(Sleep):time.Sleep(duration) 函数会使当前的 goroutine 暂停指定的时间。
在这段时间内,goroutine 不会执行任何操作,也不会消耗 CPU 资源。
这个函数通常用于模拟 I/O 操作,或者在测试中插入人为的延迟。
暂停(Yield):runtime.Gosched() 函数会使当前的 goroutine 让出 CPU,让其他 goroutine 有机会执行。
这个函数通常用于在一个长时间运行的 goroutine 中,插入一些 “断点”,以避免阻塞其他 goroutine 的执行。
需要注意的是,runtime.Gosched() 并不保证当前 goroutine 会立即停止执行,也不保证其他 goroutine 会立即开始执行。

8.2.2 删除定时器

当Timer执行结束或Ticker调用Stop时会触发定时器的删除操作。从timersBucket中删除定时器是添加定时器的你过程,即堆中元素删除后,触发小顶堆平衡。
不管是Timer还是Ticker的删除操作,最终都会执行runtime中的 stopTimer

//go:linkname stopTimer time.stopTimer
func stopTimer(t *timer) bool {return deltimer(t)
}

接下来看看deltimer的逻辑:

// Do not need to update the timerproc: if it wakes up early, no big deal.
func deltimer(t *timer) bool {if t.tb == nil { // 用户自己创建的 Timer 或者 Ticker 是不可用的// t.tb can be nil if the user created a timer// directly, without invoking startTimer e.g//    time.Ticker{C: c}// In this case, return early without any deletion.// See Issue 21874.return false}tb := t.tblock(&tb.lock)                      // 加锁removed, ok := tb.deltimerLocked(t) // 移除元素unlock(&tb.lock)                    // 解锁if !ok {badTimer()}return removed
}

得益于在 timerproc中加了两次锁,删除小顶堆元素,不需要马上通知timerproc。
因为在计算时间的时候,是加锁的,中间执行是不加锁的,后面设置系统协程状态也是加锁的。
所以删除元素,要么发生在系统协程睡眠或暂停的时候,要么发生在 sendTime 的时候,不管那种,都不会影响触发的正确性。
因为可能删除小顶堆中任意位置的元素,所以需要从该节点出发,向上和向下平衡
在这里插入图片描述

8.3 资源泄露

对于不使用的Ticker需要显示的Stop,否则会产生资源泄露问题。

  • 首先,创建Ticker 的协程并不负责计时,只负责从Ticker的管道中获取事件
  • 其次,系统写成只负责定时器计时,向管道中发送事件,并不关心上层协程如何处理事件。

如果创建了Ticker,则系统协程将持续监控该Ticker的timer,定期触发事件。如果Ticker不在使用且没有Stop,那么系统协程的负担会越来越重,持续消耗CPU资源。

9. 性能优化 (go 1.14+)

上面的runtimeTimer的原理仅适用于Go 1.10 ~ 1.13 ,尽管定时器的性能已经能满足绝大多数场景,但在一些高度依赖定时器的业务场景中,
往往需要创建海量的定时器,这些场景中需要定时器能更精确、占用系统资源更少。
Go 1.14 中对定时器又做了一次大的性能优化,主要围绕如何管理runtimeTimer进行,包含如何存储runtimeTimer,如何检测以确保定时器能准时触发。

9.1 消除了timersBucket

在前面的版本中,NewTimer和NewTicker创建的runtimeTimer会存储到全局的timersBucket桶中,最多拥有64个timersBucket桶,如果GOMAXPROCS的值不超过64,timersBucket桶的数量等于GOMAXPROCS。
每个timersBucket桶中均包含一个堆用于保存runtimerTimer,此外每个timersBucket桶对应一个专门的协程(timerproc)来监控runtimeTimer
在这里插入图片描述

在Go 1.14中取消了timersBucket桶,直接把保存runtimeTimer的堆放到了处理器P中。
在处理器P的数据结构中,除了包含协程的队列,还直接包含了runtimeTimer。
在这里插入图片描述

消除timersBucket桶的同时,也不再需要timerproc来监控定时器了。

9.2 消除了timeproc

在Go 1.14之前的版本中,timerproc实际上专门监控定时器的协程执行体。
在Go 1.14的设计中取消了timerproc,因为runtimeTimer不在存储在timerBucket桶中,而是转移到每个处理器P中。
在这里插入图片描述

Go 1.14 中做的优化主要是为了取消timerproc,不在依赖timerproc来监控定时器,而是希望提供一种更搞笑的监控方式。

9.3 更少的锁竞争

在Go 1.14 之前,runtimeTimer存储在timersBucket桶中,runtimeTimer的添加、删除均需要加锁。
在处理器P的数据结构中,仍然有一把锁(timersLock)来限制timers的并发访问。实际上在Go 1.14 中,runtimer的添加、删除也需要加锁。
当协程发生系统调用时,当前的工作线程将释放持有的处理器P,当前工作线程专注于处理系统调用(被阻塞),然后启动一个新的工作线程来继续消费当前处理器P中的协程。当新的工作线程启动时,需要寻找空闲的处理器P,这是需要加锁的。
当程序中拥有大量的定时器时,在Go 1.14之前,每个timerproc处理完一个定时器都会休眠,即触发系统调用,从而释放处理器P,启动新的工作线程,多个新的工作线程在获取空闲处理器P时会争抢互斥锁。
从Go 1.14开始,处理器不在由timerproc处理,而是在每次协程调度时检查定时器是否需要触发,在协程调度时捎带检查定时器。
相较于之前的timerproc,定时器被关注的更加频繁,而且不会因为协程触发系统调用而产生新的工作线程,所以定时器触发的会更准时。

9.4 更少的上下文切换

在Go 1.14 之前,timerproc也是夹杂在系统其他的协程中被调度的,假设将timerproc标记为GT
在这里插入图片描述

由于timerproc夹杂在其他的协程中,当协程较多时,难以保证timerproc能被及时调度。假如程序中每1微妙就需要触发一个定时器,而timerproc每2微妙才被调度一次,那么定时器将产生1微妙的误差,从而不准时了。
在Go 1.14 中,由于每次调度协程时都会检查处理器,所以当有定时器需要触发时,先处理定时器,在调度协程,相当于每个协程都兼任了之前的timerproc的工作,但不会触发系统调用。
在这里插入图片描述

由于在设计上取消了timerproc,也避免了频繁的调度timerproc时产生的上下文切换,从而在一定程度上节省了系统资源。

9.5 优化效果

在github上有优化代码的性能测试结果
https://github.com/golang/go/commit/6becb033341602f2df9d7c55cc23e64b925bbee2
在这里插入图片描述

可以看到在多个涉及定时器的场景中,性能均有了较大程度的优化。

相关的好文:
https://studygolang.com/articles/26529
https://github.com/golang/go/commit/76f4fd8a5251b4f63ea14a3c1e2fe2e78eb74f81
https://xiaorui.cc/archives/6483
https://www.pengrl.com/p/20021/

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.rhkb.cn/news/429490.html

如若内容造成侵权/违法违规/事实不符,请联系长河编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

【Godot4.3】基于状态切换的游戏元素概论

提示 本文的设想性质比较大,只是探讨一种设计思路。完全理论阶段&#xff0c;不可行就当是闹了个笑话O(∩_∩)O哈哈~但很符合我瞎搞的气质。 概述 一些游戏元素&#xff0c;其实是拥有多个状态的。比如一个宝箱&#xff0c;有打开和关闭两个状态。那么只需要设定两个状态的图…

并发编程多线程

1.线程和进程的区别&#xff1f; 进程是正在运行程序的实例&#xff0c;进程中包含了线程&#xff0c;每个线程执行不同的任务不同的进程使用不同的内存空间&#xff0c;在当前进程下的所有线程可以共享内存空间线程更轻量&#xff0c;线程上下文切换成本一般上要比进程上下文…

axure的下载,激活,汉化全过程,多图

1.前言 下载地址&#xff1a;https://pan.baidu.com/s/12xo1mJer2hmBK7QrYM5v-Q?pwd0107#list/path%2Fcsdn%E5%85%B1%E4%BA%AB%E6%96%87%E4%BB%B6 源文章&#xff1a;https://blog.csdn.net/iwanttostudyc/article/details/123773796?ops_request_misc%257B%2522request%25…

STM32 单片机最小系统全解析

STM32 单片机最小系统全解析 本文详细介绍了 STM32 单片机最小系统&#xff0c;包括其各个组成部分及设计要点与注意事项。STM32 最小系统在嵌入式开发中至关重要&#xff0c;由电源、时钟、复位、调试接口和启动电路等组成。 在电源电路方面&#xff0c;采用 3.3V 直流电源供…

.Net网络通信组件 - TouchSocket

文章目录 .Net网络通信组件 - TouchSocket1、新建.Net8控制台项目2、Nuget安装TouchSocket组件3、编写服务端代码4、编写客户端代码5、编写Program代码6、运行效果7、日志组件&#xff08;NLog&#xff09;参考我的另一篇博客 .Net网络通信组件 - TouchSocket 1、新建.Net8控制…

PyCharm的使用

PyCharm的入门使用教程 下载和安装PyCharm&#xff1a; 首先&#xff0c;访问JetBrains官方网站&#xff08;https://www.jetbrains.com/pycharm/&#xff09;下载PyCharm的最新版本。根据您的操作系统选择合适的版本进行下载。 安装完成后&#xff0c;打开PyCharm。 创建新…

深度学习03-神经网络02-激活函数

可以使用这个进行跳转链接​​​​​​​http://playground.tensorflow.org/#activationrelu&batchSize11&datasetspiralDatasetreg-gauss&learningRate0.01ularizationRate0.1&noise0&networkShape7,5,4,3,2&seed0.54477&showTestDatafalse&d…

【Unity设计模式】Unity MVC/MVP架构介绍,及MVC/MVP框架的简单应用

文章目录 什么是MVC&#xff1f;MVC眼花缭乱设计图MVP和MVC最经典的MVC的业务流程Unity MVC 框架示例1. 创建项目结构2. 实现模型3. 实现视图4. 实现控制器5. 使用示例 总结参考完结 什么是MVC&#xff1f; MVC自1982年被设计出来&#xff0c;至今都有着很大比重的使用率&…

HCIA--实验十八:配置全局DCHP

一、实验内容 1.需求/要求&#xff1a; 使用一台5700交换机和一台PC,实现全局DHCP的配置&#xff0c;并且自定义配置网关&#xff0c;配置DNS。 二、实验过程 1.拓扑图&#xff1a; 2.步骤&#xff1a; 1.SW1激活DHCP服务&#xff0c;创建vlan10 2.SW1给vlan10添加ip地址 …

Transformer模型-7- Decoder

概述 Decoder也是N6层堆叠的结构&#xff0c;每层被分3层: 两个注意力层和前馈网络层&#xff0c;同Encoder一样在主层后都加有Add&Norm&#xff0c;负责残差连接和归一化操作。 Encoder与Decoder有三大主要的不同&#xff1a; 第一层 Masked Multi-Head Attention: 采用…

Linux 动静态库

目录 一.静态库 1.理解静态库 a.什么是静态库&#xff1f; b.创建静态库的理论&#xff1f; 2.打包静态库 3.静态库的使用方法 a.头文件找不着 b.链接报错——库函数文件找不着 4.将静态库文件写到系统目录下 a.直接拷贝 b.建立软链接 二.动态库 1.什么是动态库&am…

通过标签实现有序:优化你的 FastAPI 生成的 TypeScript 客户端

在软件开发的世界里&#xff0c;API 客户端代码的质量直接影响着应用程序的性能和可维护性。随着项目规模的扩大&#xff0c;自动化生成的代码往往变得臃肿且难以管理。但幸运的是&#xff0c;通过一系列的优化策略&#xff0c;我们可以显著提升这些代码的优雅与效能。在本文中…

C#如何把写好的类编译成dll文件

1 新建一个类库项目 2 直接改写这个Class1.cs文件 3 记得要添加Windows.Forms引用 4 我直接把在别的项目中做好的cs文件搞到这里来&#xff0c;连文件名也改了&#xff08;FilesDirectory.cs&#xff09;&#xff0c;这里using System.Windows.Forms不会报错&#xff0c;因为前…

用Qt 对接‌百度AI平台

很多同学想利用几大模型AI弄点东西&#xff0c;但又不知道如何去介入&#xff1f;&#xff1f;最近帮同学弄点东西&#xff0c;刚好要接入到AI平台&#xff0c;就顺便研究了一下&#xff0c;并记录下来。 首先我们选择的 AI模型是百度的&#xff0c;然后注册&#xff0c;申请密…

8. 尝试微调LLM大型语言模型,让它会写唐诗

这篇文章与03. 进阶指南&#xff1a;自定义 Prompt 提升大模型解题能力一样&#xff0c;本质上是专注于“用”而非“写”&#xff0c;你可以像之前一样&#xff0c;对整体的流程有了一个了解&#xff0c;尝试调整超参数部分来查看对微调的影响。 这里同样是生成式人工智能导论&…

13年计算机考研408-数据结构

解析&#xff1a; 这个降序链表不影响时间复杂度&#xff0c;因为是链表&#xff0c;所以你想要升序就使用头插法&#xff0c;你想要降序就使用尾插法。 然后我们来分析一下最坏的情况是什么样的。 因为m和n都是两个有序的升序序列。 如果刚好m的最大值小于n的最小值&#xff0…

消息中间件---Kafka

一、什么是Kafka&#xff1f; Kafka是一个分布式流处理平台,类似于消息队列或企业消息传递系统&#xff1b; 流处理事什么呢&#xff1f; 流处理就是数据处理工作流&#xff0c;本质上是一种计算机编程范例。流处理是对接收到的新数据事件的连续处理。‌它涉及对从生产者到消…

10年408考研真题-数据结构

23.[2010统考真题]若元素 a,b,c,d,e,f 依次进栈&#xff0c;允许进栈、退栈操作交替进行&#xff0c;但不允许连续3次进行退栈操作&#xff0c;不可能得到的出栈序列是(D)。 A.dcebfa B.cbdaef C.bcaefd D.afedcb 解析&#xff1a; 直接看D选项&#xff0…

Python | Leetcode Python题解之第420题强密码检验器

题目&#xff1a; 题解&#xff1a; class Solution:def strongPasswordChecker(self, password: str) -> int:n len(password)has_lower has_upper has_digit Falsefor ch in password:if ch.islower():has_lower Trueelif ch.isupper():has_upper Trueelif ch.isdi…

微服务保护之熔断降级

在微服务架构中&#xff0c;服务之间的调用是通过网络进行的&#xff0c;网络的不确定性和依赖服务的不可控性&#xff0c;可能导致某个服务出现异常或性能问题&#xff0c;进而引发整个系统的故障&#xff0c;这被称为 微服务雪崩。为了防止这种情况发生&#xff0c;常用的一些…