一文教你看懂Golang协程调度【GMP设计思想】

傷城~ 2024-03-23 19:01 93阅读 0赞

## 一文教你看懂Golang协程调度【GMP设计思想】 ##

### 1 Golang调度器的由来 ###

#### 1.1 单进程的问题：进程阻塞、CPU浪费时间 ####

> 1.  单一执行程序、计算机只能一个任务一个任务来进行处理
> 2.  进程阻塞所带来的CPU浪费时间

#### 1.2 多进程、多线程问题：设计复杂、高内存、CPU占用 ####

> 1.  设计变得复杂：
>     
>      *  进程/线程的数量越多，切换成本就越大，也就越浪费
>      *  多线程往往伴随着同步竞争（如：锁、资源冲突等）
> 2.  多进程、多线程的壁垒
>     
>      *  高内存占用：  
>         \- 进程占用内存（虚拟内存：4GB 32bitOS）  
>         \- 线程占用内存（约4MB）
>      *  高CPU调度消耗

#### 1.3 协程co-routine的模式（M:N，依赖调度器的性能） ####

![在这里插入图片描述][a8cba0c8c36e4412a4ad9de1adcc264b.png]

![在这里插入图片描述][deb09535155146f780be19cba4823991.png]  
`CPU本质是操控一个线程，只不过我们逻辑意义上将线程划分为了协程和内核空间的线程。然后我们通过编程语言来操控用户空间上的线程（协程）`

> ①N:1方式：
> 
>  *  无法利用多个CPU
>  *  出现阻塞的瓶颈  
>     ②1:1方式：
>  *  跟多线程/多进程模型无异
>  *  切换协程成本代价昂贵  
>     ③M:N方式：
>  *  能够利用多核
>  *  过于以来协程调度器的优化和算法

#### 1.4 调度的优化 ####

> Goroutine的优化：
> 
>  *  内存占用，几KB，可以大量开辟
>  *  灵活调度，切换成本低

早期Go调度器的弊端：

> 基于全局的Go队列和比较传统的轮询，利用多个thread去调度  
> 弊端：
> 
> 1.  创建、销毁、调度G（goroutine）都需要每个M获取锁，形成了激烈的资源竞争
> 2.  M（thread）转移G会曹成延迟和额外的系统负载
> 3.  系统调用（CPU在M之间的切换）导致频繁的线程阻塞和取消阻塞

### 2 GMP模型的设计思想 ###

![在这里插入图片描述][a266a10758d344898e25240c784f1f35.png]

> `在Go中，线程是运行goroutine的实体，调度器的功能是把可运行的goroutine分配到工作线程上。`

#### 2.1 GMP模型简介 ####

##### ①GMP：goroutine-processor-thread #####

> G：goroutine 协程  
> P：processor 处理器  
> M：thread 内核线程

##### ②全局队列：存放等待运行的G #####

> 存放等待运行的goroutine

##### ③P的本地队列：存放等待运行的G #####

> processer的本地队列：
> 
>  *  存放等待运行的goroutine
>  *  数量限制：不超过256G
>  *  优先将新创建的goroutine放在P的本地队列中，如果本地队列放满了才会放在全局队列中

##### ④P列表：程序启动时创建 #####

>  *  程序启动时创建
>  *  最多有GOMAXPROCS个（可配置）

##### ⑤M列表：当前OS分配到Go程序的内核线程数 #####

> 当前操作系统分配到当前Go程序的内核线程数

##### ⑥P和M的数量 #####

> 1.  P的数量：
>     
>      *  环境变量$GOMAXPROCS配置
>      *  在程序中通过runtime.GOMAXPROCS()来设置
> 2.  M的数量：
>     
>      *  Go语言本身限定M最多1W
>      *  runtime/debug包中的SetMaxThreads函数来设置
>      *  如果有一个M阻塞，会创建一个新的M
>      *  如果有M空闲，那么就会回收或者睡眠一个M

#### 2.2 调度器的设计策略 ####

##### ①复用线程：work stealing、hand off机制 #####

> 避免频繁的创建、销毁线程，而是线程进行复用
> 
>  *  work stealing机制：当本线程无可运行的G时，会尝试从全局G中偷取G，如果全局队列为空，那么从其他线程绑定的P偷取G，而不是销毁空闲的线程【本地队列-全局队列-其他队列】
>  *  hand off机制：当本线程因为G进行系统调用阻塞时，线程释放绑定的P，把P转移给其他空闲的线程执行。

##### ②利用并行 #####

> GOMAXPROCS设置P的数量，最多有GOMAXPROCS个线程分布在多个CPU上同时运行

##### ③抢占 #####

> 在co-routine中要等待一个协程主动让出CPU才执行下一个协程，`在Go中，一个goroutine最多占用CPU 10ms，防止其他goroutine被饿死`

##### ④全局G队列 #####

> 当M执行work stealing它可以从全局G的队列获取G
> 
>  *  本地队列没有可运行的goroutine,会有steal机制,从从其他P里获取可运行的G ,本地队列运行顺序为 先从本地队列查询,全局队列查询,然后再从其他P里偷取,具体源码在runtime的proc.go  
>     ![在这里插入图片描述][002faf145b70416daee751101fa97c28.png]

#### 2.3 go func()经历了哪些过程 ####

![在这里插入图片描述][7bca3c4a463440c8aa66354f825ab5dc.png]

> 1.  我们通过go func()来创建一个goroutine
> 2.  有两个存储G的队列，一个是局部调度器P的本地队列、一个是全局G队列。新创建的G会先保存在P的本地队列中，如果P的本地队列已经满了就会保存在全局的队列中。
> 3.  G只能运行在M中，一个M必须持有一个P，M与P是1:1的关系。M会从P的本地队列弹出一个可执行状态的G来执行，如果P的本地队列为空，就会向其他的MP组合或者全局队列中偷取一个可执行的G来执行。【`本地-全局-其他队列`】
> 4.  一个M调度G执行的过程是一个循环机制
> 5.  当M执行某一个G时候如果发生了syscall或者其他阻塞操作，M会阻塞，如果当前有一些G在执行，runtime会把这个线程M从P中摘除（detach），然后再创建一个新的操作系统的线程（如果有空闲的线程可复用空闲线程）来服务于这个P。
> 6.  当M系统调用结束的时候，这个G会尝试获取一个空闲的P执行，并放入到这个P的本地队列。如果获取不到P，那么这个线程M会变成休眠状态，加入到空闲线程中，然后这个G会被放入全局队列中。

#### 2.4 调度器调度的生命周期：M0、G0 ####

![在这里插入图片描述][72b0b1608f244782b7d27f4e0551ea7a.png]

package main
    
    import "fmt"
    
    func main() {
        
        fmt.Println("Hello world")
    }

下面我们分析代码流程：

> 1.  runtime创建最初的线程M0和G0，并把二者关联
> 2.  调度器初始化：初始化M0、栈、垃圾回收，以及创建和初始化由GOMAXPROCS个P构成的P列表
> 3.  示例代码中的main函数是**main.main**，runtime中也有一个main函数-runtime.main，代码经过编译后，`runtime.main会调用main.main`，程序启动时会为runtime.main创建Goroutine，称它为main goroutine，然后吧main goroutine加入到P的本地队列。
> 4.  启动M0，M0已经绑定了P，会从P的本地队列获取G，获取到main goroutine
> 5.  G拥有栈，M根据G中的栈信息和调度信息设置运行环境
> 6.  M运行G
> 7.  G退出，再次回到M获取可运行的G，这样重复下去，直到main.main退出，runtime.main执行defer 和panic处理，或者调用runtime.exit退出程序。

调度器的生命周期几乎占满了一个Go程序的一生，runtime.main的goroutine执行之前都是为调度器做准备工作，`runtime.main的goroutine运行，才是调度器的真正开始`，直到runtime.main的结束而结束。

##### ①M0：启动go程序后创建的第一个主线程 #####

> M0是启动程序后的编号为0的主线程，这个M对应的实例会在全局变量runtime.m0中，不需要在heap上分配，M0负责执行初始化操作和启动第一个G，再之后的M0就和其他M一样了

##### ②G0：每个M启动后创建的第一个goroutine #####

> G0是每次启动一个M都会第一个创建的goroutine，G0仅用于负责调度G，G0不指向任何可执行的函数，每个M都会有一个自己的G0.在调度或系统调用时会使用G0的栈空间，全局变量的G0是M0的G0

#### 2.5 GMP可视化调试（trace编程） ####

##### ① 基本的trace编程 #####

1.  创建trace文件 f,err := os.Create(“trace.out”)
2.  启动trace trace.Start(f)
3.  停止trace trace.Stop()
4.  go build运行之后，会得到一个trace.out文件

trace/main.go:

package main
    
    import (
    	"fmt"
    	"os"
    	"runtime/trace"
    )
    
    func main() {
        
    	//1. 创建trace文件
    	file, err := os.Create("trace.out")
    	if err != nil {
        
    		panic(err)
    	}
    	defer file.Close()
    	//2. 开启trace
    	trace.Start(file)
    	//执行业务逻辑
    	fmt.Println("do something...")
    	//3. 暂停trace
    	trace.Stop()
    }

运行上面的程序之后会得到一个trace.out文件：  
![在这里插入图片描述][162d4cb6996a4ccc8d33cecb8a63e267.png]

##### ②通过go tool trace工具打开trace文件 #####

1.  go tool trace trace.out
2.  通过http://127.0.0.1:xxxx进行访问(端口是随机的)

![在这里插入图片描述][2abb924e2f34485c8c1d8ea0373c8f17.png]

> 点击页面上的view trace：

![在这里插入图片描述][975a5bd4805f450b9e276427bcc23f95.png]  
查看效果：  
![在这里插入图片描述][34d05737723d4a4083ee8c67940418b4.png]

> 点击图表中不同的未知，查看左下方的值

![在这里插入图片描述][45bf90054c4b4140ba410c863f89f41d.png]

##### 1. G信息 #####

> 点击Goroutines那一行可视化的数据条，我们会看到一些详细的信息。

![在这里插入图片描述][166205248aea4cb29462a6b666402e21.png]

> 一共有两个G在程序中，一个是特殊的G0，是每个M必须有的一个初始化的G，这个我们不必讨论。

其中G1应该就是main goroutine(执行main函数的协程)，在一段时间内处于可运行和运行的状态。

##### 2. M信息 #####

> 点击Threads那一行可视化的数据条，我们会看到一些详细的信息。

![在这里插入图片描述][eca2b8abfa7749ad955c1505249a6b32.png]  
一共有两个M在程序中，一个是特殊的M0，用于初始化使用，这个我们不必讨论。

##### 3. P信息 #####

![在这里插入图片描述][67872cb0c0134b4491a8461e0e51d29f.png]

G1中调用了main.main，创建了trace goroutine g18。G1运行在P1上，G18运行在P0上。

这里有两个P，我们知道，一个P必须绑定一个M才能调度G。

##### 4. M信息 #####

![在这里插入图片描述][199c599fcc094a69950633496efa8d46.png]  
我们会发现，确实G18在P0上被运行的时候，确实在Threads行多了一个M的数据，点击查看如下：  
![在这里插入图片描述][954755fa82a6447987fb14e72221082b.png]  
多了一个M2应该就是P0为了执行G18而动态创建的M2.

##### ③通过Debug trace方式 #####

main.go

package main
    
    import (
        "fmt"
        "time"
    )
    
    func main() {
        
        for i := 0; i < 5; i++ {
        
            time.Sleep(time.Second)
            fmt.Println("Hello World")
        }
    }

# 编写
    go build main.go
    # 执行编译好的可执行文件
    GODEBUG=schedtrace=1000 ./main

# 查看输出结果
    SCHED 0ms: gomaxprocs=2 idleprocs=0 threads=4 spinningthreads=1 idlethreads=1 runqueue=0 [0 0]
    Hello World
    SCHED 1003ms: gomaxprocs=2 idleprocs=2 threads=4 spinningthreads=0 idlethreads=2 runqueue=0 [0 0]
    Hello World
    SCHED 2014ms: gomaxprocs=2 idleprocs=2 threads=4 spinningthreads=0 idlethreads=2 runqueue=0 [0 0]
    Hello World
    SCHED 3015ms: gomaxprocs=2 idleprocs=2 threads=4 spinningthreads=0 idlethreads=2 runqueue=0 [0 0]
    Hello World
    SCHED 4023ms: gomaxprocs=2 idleprocs=2 threads=4 spinningthreads=0 idlethreads=2 runqueue=0 [0 0]
    Hello World

● SCHED：调试信息输出标志字符串，代表本行是goroutine调度器的输出；  
● 0ms：即从程序启动到输出这行日志的时间；  
● gomaxprocs: P的数量，本例有2个P, 因为默认的P的属性是和cpu核心数量默认一致，当然也可以通过GOMAXPROCS来设置；  
● idleprocs: 处于idle状态的P的数量；通过gomaxprocs和idleprocs的差值，我们就可知道执行go代码的P的数量；  
● threads: os threads/M的数量，包含scheduler使用的m数量，加上runtime自用的类似sysmon这样的thread的数量；  
● spinningthreads: 处于自旋状态的os thread数量；  
● idlethread: 处于idle状态的os thread的数量；  
● runqueue=0： Scheduler全局队列中G的数量；  
● \[0 0\]: 分别为2个P的local queue中的G的数量。

### 3 GMP场景分析合集 ###

#### 3.1 G1创建G2：优先入本地队列 ####

> `正在执行的G创建的其他G优先加入本地队列。`  
> P拥有G1，M1获取P后开始运行G1，G1使用go func()创建了G2，为了局部性G2优先加入到P1的本地队列。

![在这里插入图片描述][a8562e1fa6114ee4bebf6148b236590e.png]

#### 3.2 G1执行完毕调用G2：G0负责调度 ####

> `G1执行完毕之后，由G0调度从队列中获取G2，然后让P来执行G2.`  
> G1运行完成后(函数：goexit)，M上运行的goroutine切换为G0，G0负责调度时协程的切换（函数：schedule）。从P的本地队列取G2，从G0切换到G2，并开始运行G2(函数：execute)。实现了线程M1的复用。

![在这里插入图片描述][9e0d63d5d42e445fa7e708525a831317.png]

#### 3.3 G2开辟过多G ####

> 假设每个P的本地队列只能存3个G。G2要创建了6个G，前3个G（G3, G4, G5）已经加入p1的本地队列，p1本地队列满了

![在这里插入图片描述][376be7b99e1f443f9484a6f035c6b642.png]

#### 3.4 G2本地已经满继续创建G：打乱放全局队列 ####

> `G2所绑定的队列已经满了，但此时又创建了新的G，则打乱本地队列的前半部分G和新创建的G一起放入全局队列。（保证：随机，避免新G饥饿。）`  
> G2在创建G7的时候，发现P1的本地队列已满，需要执行负载均衡(把P1中本地队列中前一半的G，还有新创建G转移到全局队列)
> 
>  *  （实现中并不一定是新的G，如果G是G2之后就执行的，会被保存在本地队列，利用某个老的G替换新G加入全局队列）
>  *  这些G被转移到全局队列时，会被打乱顺序。所以G3,G4,G7被转移到全局队列。

![在这里插入图片描述][9e0865dede6e453c82189b30ec7266d7.png]

#### 3.5 G2本地未满创G8：放入本地队列 ####

> `如果在创建新G之后本地队列未满，则先放本地队列。`  
> G2创建G8时，P1的本地队列未满，所以G8会被加入到P1的本地队列。
> 
>  *  G8加入到P1点本地队列的原因还是因为P1此时在与M1绑定，而G2此时是M1在执行。所以G2创建的新的G会优先放置到自己的M绑定的P上。

![在这里插入图片描述][c2f70d590e594566a97e8e6445315337.png]

#### 3.6 创建G时会尝试环境其他空闲的M和P去消费新G ####

> `创建新G成功后，会尝试换唤醒M和P，让其组合来消费新G。`  
> 规定：在创建G时，运行的G会尝试唤醒其他空闲的P和M组合去执行。
> 
>  *  假定G2唤醒了M2，M2绑定了P2，并运行G0，但P2本地队列没有G，M2此时为自旋线程（没有G但为运行状态的线程，不断寻找G）。

![在这里插入图片描述][03816ea40b014c8baeeee9e5ee0ab92b.png]

#### 3.7 从全局队列到P本地队列的LB（负载均衡） ####

> `自旋线程根据LB来从全局队列拉取G进行消费。`  
> M2尝试从全局队列(简称“GQ”)取一批G放到P2的本地队列（函数：findrunnable()）。M2从全局队列取的G数量符合下面的公式

n =  min(len(GQ) / GOMAXPROCS +  1,  cap(LQ) / 2 )

![在这里插入图片描述][cdf47f4e4f934628a6c526c754cf266f.png]

至少从全局队列取1个g，但每次不要从全局队列移动太多的g到p本地队列，给其他p留点。这是从全局队列到P本地队列的负载均衡。

#### 3.8 M2从M1偷取G ####

> `如果M2队列为空，则从M1的本地队列中偷取后半部分G进行消费。（好不容易偷一次）`  
> 假设G2一直在M1上运行，经过2轮后，M2已经把G7、G4从全局队列获取到了P2的本地队列并完成运行，全局队列和P2的本地队列都空了,如场景8图的左半部分。

![在这里插入图片描述][ff32f99a08a54b7d9403687e73cf4e64.png]  
全局队列已经没有G，那m就要执行work stealing(偷取)：从其他有G的P哪里偷取一半G过来，放到自己的P本地队列。P2从P1的本地队列尾部取一半的G，本例中一半则只有1个G8，放到P2的本地队列并执行。

#### 3.9 自旋线程的最大限制:自旋+运行<=GOMAXPROCS ####

> `正在运行的线程+自旋的线程 <= GOMAXPROCS。`  
> G1本地队列G5、G6已经被其他M偷走并运行完成，当前M1和M2分别在运行G2和G8，M3和M4没有goroutine可以运行，M3和M4处于自旋状态，它们不断寻找goroutine。

![在这里插入图片描述][5fb2114620eb4f818a706cef67e26ca9.png]

> 为什么要让m3和m4自旋，自旋本质是在运行，线程在运行却没有执行G，就变成了浪费CPU. 为什么不销毁现场，来节约CPU资源。因为创建和销毁CPU也会浪费时间，我们希望当有新goroutine创建时，立刻能有M运行它，如果销毁再新建就增加了时延，降低了效率。当然也考虑了过多的自旋线程是浪费CPU，所以系统中最多有GOMAXPROCS个自旋的线程(当前例子中的GOMAXPROCS=4，所以一共4个P)，多余的没事做线程会让他们休眠。

#### 3.10 G发生系统调用或阻塞 ####

> `P与阻塞的M解绑，去唤醒休眠中的M进行组合。`  
> 假定当前除了M3和M4为自旋线程，还有M5和M6为空闲的线程(没有得到P的绑定，注意我们这里最多就只能够存在4个P，所以P的数量应该永远是M>=P, 大部分都是M在抢占需要运行的P)，G8创建了G9，G8进行了阻塞的系统调用，M2和P2立即解绑，P2会执行以下判断：如果P2本地队列有G、全局队列有G或有空闲的M，P2都会立马唤醒1个M和它绑定，否则P2则会加入到空闲P列表，等待M来获取可用的p。本场景中，P2本地队列有G9，可以和其他空闲的线程M5绑定

![在这里插入图片描述][91ef52ab34cb48628b74f6130b681b33.png]

#### 3.11 G发生系统调用或非阻塞 ####

> `尝试获取之前解绑的P，如果之前的P已经与其他M组合，则尝试从空闲的P队列中获取新P。如果获取失败，则将阻塞结束的G放入全局队列`  
> G8创建了G9，假如G8进行了非阻塞系统调用。

![在这里插入图片描述][f5f16d3a4020410fbd3b414ff33d87d3.png]

> M2和P2会解绑，但M2会记住P2，然后G8和M2进入系统调用状态。当G8和M2退出系统调用时，会尝试获取P2，如果无法获取，则获取空闲的P，如果依然没有，G8会被记为可运行状态，并加入到全局队列,M2因为没有P的绑定而变成休眠状态(长时间休眠等待GC回收销毁)。

总结：Go调度器很轻量也很简单，足以撑起goroutine的调度工作，并且让Go具有了原生（强大）并发的能力。Go调度本质是把大量的goroutine分配到少量线程上去执行，并利用多核并行，实现更强大的并发。

参考：https://www.yuque.com/aceld/golang/srxd6d

[a8cba0c8c36e4412a4ad9de1adcc264b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/5df0fd5ad71f4ab2834daef7ae0ca8fa.png
[deb09535155146f780be19cba4823991.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/07477cad39824df89bbb9bff2928b5ff.png
[a266a10758d344898e25240c784f1f35.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/b9fc5c1479324d6ca891dd118fb53f7e.png
[002faf145b70416daee751101fa97c28.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/ba00cce9e3c24fa4b8e6bbacb34d7ac6.png
[7bca3c4a463440c8aa66354f825ab5dc.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/c3968cf18f2d40069fac87a6131b7351.png
[72b0b1608f244782b7d27f4e0551ea7a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/d0bc559e06724e68b8a66e6f8633fc08.png
[162d4cb6996a4ccc8d33cecb8a63e267.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/b7131d0f321b414cbb82df0c3d6e7d4a.png
[2abb924e2f34485c8c1d8ea0373c8f17.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/1d42ab3a97d74f66b265e257d2508a66.png
[975a5bd4805f450b9e276427bcc23f95.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/8e17286e475348689e3c0e349da4227d.png
[34d05737723d4a4083ee8c67940418b4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/e230cae135e14278a20ae6c4716d3b6c.png
[45bf90054c4b4140ba410c863f89f41d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/5bc512b982b14bc99471ab32616fde05.png
[166205248aea4cb29462a6b666402e21.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/812258301cb64e06908429b24b28ef8f.png
[eca2b8abfa7749ad955c1505249a6b32.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/954fcaae7cb7472eb42d0b2987f73301.png
[67872cb0c0134b4491a8461e0e51d29f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/0cf8716dbea640678b4e842c6e5a449a.png
[199c599fcc094a69950633496efa8d46.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/769de5555c624fc88cec3bfd02be0acd.png
[954755fa82a6447987fb14e72221082b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/36bfcdb03141495e87075a08a665ac55.png
[a8562e1fa6114ee4bebf6148b236590e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/e10440d691634b3a9a276c40af85780c.png
[9e0d63d5d42e445fa7e708525a831317.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/2285a1223f784d9ca8c63022c05bbd07.png
[376be7b99e1f443f9484a6f035c6b642.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/c46b93085eb5449a8205eaeaa92e2cf4.png
[9e0865dede6e453c82189b30ec7266d7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/04194f51701548988656fa429d6cd159.png
[c2f70d590e594566a97e8e6445315337.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/1c8f2912d2dd4a39952119d7565c80f3.png
[03816ea40b014c8baeeee9e5ee0ab92b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/0230986317f64a5387d7029d22ec6602.png
[cdf47f4e4f934628a6c526c754cf266f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/77a4c899a95f476aa22d5ade423f5e16.png
[ff32f99a08a54b7d9403687e73cf4e64.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/ca5d788200f449fcbeda01bd95e6e863.png
[5fb2114620eb4f818a706cef67e26ca9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/091abada86c347638a6cb99ce74e4c26.png
[91ef52ab34cb48628b74f6130b681b33.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/4b8a93a065d24ec192c34cf41c07c715.png
[f5f16d3a4020410fbd3b414ff33d87d3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/38d4f15d4f4d4662874c96a6f8d5cb83.png