golang 协程关闭——谁敢说没踩过坑

news2024/11/20 12:33:56

Go语言中，协程创建和启动非常简单，但是如何才能正确关闭协程呢，和开车一样，前进总是很容易，但是如何正确的把车停在指定的地方总是不容易的。生产实践中，go常常遇到未能正确关闭协程而影响程序运行的场景，轻则协程泄漏资源浪费，重则程序崩溃。
本文，总结协程关闭的三大原则，结合实际场景让你彻底搞定协程关闭，保证又快又稳！

场景

结合如下典型场景，主进程中起多个协程，这些协程会
1.共同消费一个数据通道 data channel
2.也可能共享一个退出通道channel或context
image.png

那么，应该如何正确关闭呢

原则1-协程接受通知主动关闭

并不推荐强制停止，更多的时候我们希望在停止时，干一点事比如资源清理/连接清理等，这时候最好的方式就是通知协程退出，具体何时退出和退出前做什么完全由当前要关闭的协程控制。

通知一般有三种方式

data channel关闭通知退出

适用简单任务，复杂的更推荐context单独通知

// cancelFn 数据通道关闭通知退出
func cancelFn(dataChan chan int) {
	for {
		select {
		case val, ok := <-dataChan:
			// 关闭data通道时，通知退出
			// 一个可选是判断data=指定值时退出
			if !ok {
				log.Printf("Channel closed ！！！")
				return
			}

			log.Printf("Revice dataChan %d\n", val)
		}
	}
}

exit channel关闭通知退出

部分简单场景适用

// exitChannelFn 单独退出通道关闭通知退出
func exitChannelFn(wg *sync.WaitGroup, taskNo int, dataChan chan int, exitChan chan struct{}) {
	defer wg.Done()

	for {
		select {
		case val, ok := <-dataChan:
			if !ok {
				log.Printf("Task %d channel closed ！！！", taskNo)
				return
			}

			log.Printf("Task %d  revice dataChan %d\n", taskNo, val)

			// 关闭exit通道时，通知退出
		case <-exitChan:
			log.Printf("Task %d  revice exitChan signal!\n", taskNo)
			return
		}
	}

}

context超时或取消通知退出

主流推荐

// contextCancelFn context取消或超时通知退出
func contextCancelFn(wg *sync.WaitGroup, taskNo int, dataChan chan int, ctx context.Context) {
	defer wg.Done()

	for {
		select {
		case val, ok := <-dataChan:
			if !ok {
				log.Printf("Task %d channel closed ！！！", taskNo)
				return
			}

			log.Printf("Task %d  revice dataChan %d\n", taskNo, val)

		// ctx取消或超时，通知退出
		case <-ctx.Done():
			log.Printf("Task %d  revice exit signal!\n", taskNo)
			return
		}
	}

}

原则2-谁负责创建协程谁负责关闭协程

go func可以立即创建一个协程，因此常常遇到我们可能在任何一个地方创建协程，但是在哪里关闭呢，是需要统一管理吗？官方推荐的最佳实践就是，谁负责创建协程谁负责关闭协程。

参考如下，每次调用execDataTaskFunc函数执行都会起一个协程异步执行，协程关闭通过监控外层函数context参数来实现。

func execDataTaskFunc(ctx context.Context, dataChan chan int, taskName string) chan int {
	out := make(chan int)

	log.Printf("Task %s start!\n", taskName)

	go func() {
		defer close(out)

		for {
			select {
			case data, ok := <-dataChan:
				if !ok {
					log.Printf("Task %s  revice data channel close signal!\n", taskName)
					return
				}

                // do something
				out <- data
			case <-ctx.Done():
				log.Printf("Task %s  revice exit signal!\n", taskName)
				return
			}
		}
	}()

	return out
}

原则3-等待所有协程关闭再退出

通常对于正在运行的协程，发出退出通知后，具体程序何时才能退出呢？一般如下三种方式

WaitGroup/ErrGroup判断所有协程关闭后退出

最常用，参考如下

// 多个任务并行控制，等待所有任务完成
func TestTaskControl(t *testing.T) {
	dataChan := make(chan int)

	taskNum := 3

	wg := sync.WaitGroup{}
	wg.Add(taskNum)

	// 起多个协程，data关闭时退出
	for i := 0; i < taskNum; i++ {
		go func(taskNo int) {
			defer wg.Done()
			t.Logf("Task %d run\n", taskNo)

			for {
				select {
				case _, ok := <-dataChan:
					if !ok {
						t.Logf("Task %d notify to stop\n", taskNo)
						return
					}
				}
			}
		}(i)
	}

	// 通知退出
	go func() {
		time.Sleep(3 * time.Second)
		close(dataChan)
	}()

	// 等待退出完成
	wg.Wait()
}

等待channel关闭后退出

参考如下，对于部分任务场景，协程数据输出到新建的channel中，可以在此channel上阻塞等待，直到协程通知关闭时，关闭此channel然后程序退出。

// 多个任务并行控制，等待所有任务完成
func TestTaskControl2(t *testing.T) {
	dataChan := make(chan int)

	// 起协程返回新chan，在输出chan等待判断完成
	out := make(chan int)
	go func() {
		defer close(out) // 结束则自动关闭

		for {
			select {
			case _, ok := <-dataChan:
				if !ok {
					t.Logf("Task notify to stop\n")
					return
				}
			}
		}
	}()

	// 通知退出
	go func() {
		time.Sleep(3 * time.Second)
		close(dataChan)
	}()

	dataChan <- 1

	// 等待退出完成
	for data := range out {
		t.Logf("%d\n", data)
	}
}

等待足够长时间后关闭

对于部分任务，能够估算从通知关闭到实际关闭时间，则可等待足够长时间来保证协程关闭然后退出，实际场景并不推荐，带有一定不确定性，很容易出错。

func TestTaskControl3(t *testing.T) {
	dataChan := make(chan int)

	// 起协程返回新chan
	out := make(chan int)
	go func() {
		defer close(out) // 结束则自动关闭

		for {
			select {
			case _, ok := <-dataChan:
				if !ok {
					t.Logf("Task notify to stop\n")
					return
				}
			}
		}
	}()

	// 通知退出
	go func() {
		time.Sleep(3 * time.Second)
		close(dataChan)
	}()

	dataChan <- 1

	// 等待足够长时间，退出完成
	time.Sleep(10 * time.Second)
}

复杂退出场景

结合三大原则，这里展示部分复杂场景的协程关闭方案。

嵌套协程，同时关闭

如下是多个任务执行，每个任务一个协程，现在考虑如下目标
支持多级嵌套，父任务停止后，子任务自动停止
image.png
方案：使用context通知，WaitGroup等待所有任务关闭后退出
任务运行代码

type TaskFunc func(ctx context.Context)

func runTaskFunc(wg *sync.WaitGroup, ctx context.Context, taskName string, f TaskFunc) {
	defer wg.Done()

	log.Printf("Task %s start!\n", taskName)
	f(ctx)

	for {
		select {

		case <-ctx.Done():
			log.Printf("Task %s  revice exit signal!\n", taskName)
			return
		}
	}

}

整体实现代码

// 简单并行任务-同时停止
func TestStop(t *testing.T) {
	ctx, cancel := context.WithCancel(context.Background())

	var wg = sync.WaitGroup{}

	// 起多个任务
	wg.Add(1)
	go runTaskFunc(&wg, ctx, "A", func(ctx context.Context) {
		wg.Add(1)
		go runTaskFunc(&wg, ctx, "B", func(ctx context.Context) {
			wg.Add(1)
			go runTaskFunc(&wg, ctx, "C", func(ctx context.Context) {
				wg.Add(1)
				go runTaskFunc(&wg, ctx, "D", func(ctx context.Context) {})
			})
		})

		wg.Add(1)
		go runTaskFunc(&wg, ctx, "E", func(ctx context.Context) {
			wg.Add(1)
			go runTaskFunc(&wg, ctx, "F", func(ctx context.Context) {
				wg.Add(1)
				go runTaskFunc(&wg, ctx, "G", func(ctx context.Context) {})
			})
		})
	})

	// 通知关闭
	go func() {
		time.Sleep(3 * time.Second)
		cancel()
	}()

	// 等待全部关闭后退出
	wg.Wait()
}

协程关闭是无序的，如下

2023/01/07 22:40:09 Task A start!
2023/01/07 22:40:09 Task E start!
2023/01/07 22:40:09 Task F start!
2023/01/07 22:40:09 Task G start!
2023/01/07 22:40:09 Task B start!
2023/01/07 22:40:09 Task C start!
2023/01/07 22:40:09 Task D start!
2023/01/07 22:40:12 Task A revice exit signal!
2023/01/07 22:40:12 Task G revice exit signal!
2023/01/07 22:40:12 Task B revice exit signal!
2023/01/07 22:40:12 Task F revice exit signal!
2023/01/07 22:40:12 Task D revice exit signal!
2023/01/07 22:40:12 Task C revice exit signal!
2023/01/07 22:40:12 Task E revice exit signal!

嵌套协程，指定顺序关闭

还是上述场景，现在需求是：控制停止顺序，先停EFG 再停BCD 最后停A
image.png
方案：借助context通知，指定多个cancel点，WaitGroup等待所有任务关闭后退出

// 简单并行任务-控制停止顺序
func TestStop2(t *testing.T) {
	ctx, cancel := context.WithCancel(context.Background())
	ctxb, cancelb := context.WithCancel(ctx)
	ctxe, cancele := context.WithCancel(ctx)

	var wg = sync.WaitGroup{}

	// 起多个任务
	wg.Add(1)
	go runTaskFunc(&wg, ctx, "A", func(ctx context.Context) {
		wg.Add(1)
		go runTaskFunc(&wg, ctxb, "B", func(ctx context.Context) {
			wg.Add(1)
			go runTaskFunc(&wg, ctx, "C", func(ctx context.Context) {
				wg.Add(1)
				go runTaskFunc(&wg, ctx, "D", func(ctx context.Context) {})
			})
		})

		wg.Add(1)
		go runTaskFunc(&wg, ctxe, "E", func(ctx context.Context) {
			wg.Add(1)
			go runTaskFunc(&wg, ctx, "F", func(ctx context.Context) {
				wg.Add(1)
				go runTaskFunc(&wg, ctx, "G", func(ctx context.Context) {})
			})
		})
	})

	// 通知关闭
	go func() {
		time.Sleep(3 * time.Second)
		cancele()
		time.Sleep(3 * time.Second)
		cancelb()
		time.Sleep(3 * time.Second)
		cancel()
	}()

	// 等待全部关闭后退出
	wg.Wait()
}

运行如下，协程按照指定顺序关闭

2023/01/07 22:40:40 Task A start!
2023/01/07 22:40:40 Task E start!
2023/01/07 22:40:40 Task F start!
2023/01/07 22:40:40 Task G start!
2023/01/07 22:40:40 Task B start!
2023/01/07 22:40:40 Task C start!
2023/01/07 22:40:40 Task D start!
2023/01/07 22:40:43 Task E revice exit signal!
2023/01/07 22:40:43 Task F revice exit signal!
2023/01/07 22:40:43 Task G revice exit signal!
2023/01/07 22:40:46 Task B revice exit signal!
2023/01/07 22:40:46 Task D revice exit signal!
2023/01/07 22:40:46 Task C revice exit signal!
2023/01/07 22:40:49 Task A revice exit signal!

嵌套协程，逐级关闭

考虑如下场景，A->B->C嵌套起协程，每个协程创建新的channel传输数据给下游
image.png
如下起任务，每个任务可以通过context或者data channel关闭来通知退出

func execDataTaskFunc(ctx context.Context, dataChan chan int, taskName string) chan int {
	out := make(chan int)
	//out := make(chan int, 100)

	log.Printf("Task %s start!\n", taskName)

	go func() {
		defer close(out)

		for {
			select {
			case data, ok := <-dataChan:
				if !ok {
					log.Printf("Task %s  revice data channel close signal!\n", taskName)
					return
				}

				time.Sleep(2 * time.Second)
				out <- data
			case <-ctx.Done():
				log.Printf("Task %s  revice exit signal!\n", taskName)
				return
			}
		}
	}()

	return out
}

整体流程如下

func TestDataTaskStop(t *testing.T) {
	ctx, cancel := context.WithCancel(context.Background())
	defer cancel()

	dataChanInput := make(chan int)

	// 嵌套运行协程
	taskChanA := execDataTaskFunc(ctx, dataChanInput, "A")
	taskChanB := execDataTaskFunc(ctx, taskChanA, "B")
	taskChanC := execDataTaskFunc(ctx, taskChanB, "C")

	// 通知退出
	go func() {
		i := 0
		for {
			select {
			case <-time.After(time.Second):
				i = i + 1
				if i == 10 {
					t.Logf("Notify to stop!!!")
					close(dataChanInput)
					//cancel()
					return
				}

				dataChanInput <- i
			}
		}
	}()

	//  等待退出
	for data := range taskChanC {
		t.Logf("Out->%d", data)
	}
}

这里数据每条数据产生间隔1秒，每个任务处理时长为2秒，也就是说通知关闭时，可能上游任务处理中，下游还没来得及处理，因此期望的是逐级依次关闭A/B/C，确保上游数据处理完成传给下游，不要丢失数据。

对比context通知退出和data channel关闭通知退出，对比如下。可以看到如果我们是有中间处理和逐级关闭需求的还是要依赖close关闭协程来通知，context全局通知退出是无序的，无法保证数据不丢失。

  • cancel()-context通知退出

执行如下，A/B/C同时退出，数据出现丢失

2023/01/07 23:23:59 Task A start!
2023/01/07 23:23:59 Task B start!
2023/01/07 23:23:59 Task C start!
complex_test.go:174: Out->1
complex_test.go:174: Out->2
complex_test.go:174: Out->3
complex_test.go:174: Out->4
complex_test.go:174: Out->5
complex_test.go:174: Out->6
complex_test.go:161: Notify to stop!!!
2023/01/07 23:24:18 Task C revice exit signal!
complex_test.go:174: Out->7

  • close(dataChanInput)通知退出

执行如下，A/B/C逐级依次关闭，数据没有丢失

2023/01/07 23:20:18 Task A start!
2023/01/07 23:20:18 Task B start!
2023/01/07 23:20:18 Task C start!
complex_test.go:174: Out->1
complex_test.go:174: Out->2
complex_test.go:174: Out->3
complex_test.go:174: Out->4
complex_test.go:174: Out->5
complex_test.go:174: Out->6
complex_test.go:161: Notify to stop!!!
complex_test.go:174: Out->7
2023/01/07 23:20:37 Task A revice data channel close signal!
complex_test.go:174: Out->8
2023/01/07 23:20:39 Task B revice data channel close signal!
2023/01/07 23:20:41 Task C revice data channel close signal!
complex_test.go:174: Out->9

参考

演示代码 https://gitee.com/wenzhou1219/go-in-prod/tree/master/task_stop

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

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

Unity - TextMeshPro

Unity - TextMeshPro

TextMeshPro TextMeshPro 是 Unity 的终极文本解决方案。它是 Unity 的 UI 文本和旧版文本网格的完美替代品。 TextMeshPro&#xff08;也称为 TMP&#xff09;功能强大且易于使用&#xff0c;它使用高级文本渲染技术以及一组自定义着色器&#xff1b;提供显着的视觉质量改进&…
阅读更多...
C++分文件编写VS Code和CMakeLists使用详解

C++分文件编写VS Code和CMakeLists使用详解

目录一、示例代码1.1 主函数main.cpp1.2 子函数源文件1.3 子函数头文件二、VS Code编译2.1 报错2.2解决方法三、CMakeLists编译Windows 10 Ubuntu 20.04 VS Code 一、示例代码 1.1 主函数main.cpp 要用双引号包含子函数的头文件&#xff0c;第二行 #include<iostream&g…
阅读更多...
项目经理必备的5种项目管理工具，让你的项目迅速上手

项目经理必备的5种项目管理工具，让你的项目迅速上手

做项目管理是一条漫漫长路&#xff0c;所有的本事&#xff0c;都是靠一个个项目&#xff0c;一点点积累而来的&#xff0c;并不存在“迅速上手”的方法。 一名普通项目经理的成长&#xff0c;都要经过一定时间的修炼&#xff0c;并且要灵活使用项目管理工具&#xff0c;这里给…
阅读更多...
跑步的人如何选择耳机、最好的跑步蓝牙耳机排名清单

跑步的人如何选择耳机、最好的跑步蓝牙耳机排名清单

相信很多人和小编一样&#xff0c;在跑步健身的时候也喜欢听点音乐&#xff0c;特别是节奏感强的音乐能让运动更加有激情。但是如果佩戴传统的有线耳机容易扯到线&#xff0c;在现代化的今天&#xff0c;当然要选择蓝牙耳机。今天就为大家介绍一下跑步用什么蓝牙耳机好&#xf…
阅读更多...
看完这篇文章，我再也不用担心线上出现CPU性能问题了（下）

看完这篇文章，我再也不用担心线上出现CPU性能问题了（下）

目录平均负载CPU 使用率进程上下文切换补充总结在 《看完这篇文章&#xff0c;我再也不用担心线上出现CPU性能问题了&#xff08;上&#xff09;》中&#xff0c;咸鱼给大家介绍了 CPU 常见的性能指标&#xff0c;当生产环境出现 CPU 性能瓶颈的时候&#xff0c;优先观察这些指…
阅读更多...
论文投稿指南——中文核心期刊推荐（食品工业 2）

论文投稿指南——中文核心期刊推荐（食品工业 2）

【前言】 &#x1f680; 想发论文怎么办&#xff1f;手把手教你论文如何投稿&#xff01;那么&#xff0c;首先要搞懂投稿目标——论文期刊 &#x1f384; 在期刊论文的分布中&#xff0c;存在一种普遍现象&#xff1a;即对于某一特定的学科或专业来说&#xff0c;少数期刊所含…
阅读更多...
写IB EE(Extended Essay)时最容易犯的五大错误

写IB EE(Extended Essay)时最容易犯的五大错误

【第一大忌】用随意找来的文章做Sources&#xff01; 同学们都知道EE写作一定要做好citation&#xff0c;在文中、文末都要列出参考资料。但不是什么文章都”有资格“成为bibliography的一部分&#xff0c;选取质量高的sources是很重要的。那些百度上搜到的作者不详、自己都没有…
阅读更多...
教你使用 Petalinux 定制 Linux

教你使用 Petalinux 定制 Linux

测试平台&#xff1a;黑金 Zynq7035 开发板 芯片型号&#xff1a;XC7Z035-2FFG676I 开发环境&#xff1a;Ubuntu 16.04 开发工具&#xff1a;Petalinux 2017.4 Step1 创建 Petalinux 工程 1.1 将 Vivado 工程目录下*.sdk文件夹中的*.hdf文件复制到新建的proj文件夹中 1.2 …
阅读更多...
串级PID控制原理-2

串级PID控制原理-2

按串级控制的基本原理&#xff0c;采用Simulink进行编程&#xff0c;在连续方式下进行仿真。在串级控制中&#xff0c;主调节器采用PI控制&#xff0c;取kp 50&#xff0c;k i5&#xff0c;副调节器采用Р控制&#xff0c;kp 200。外加干扰为正弦信号sin(50t)&#xff0c;通过切…
阅读更多...
报表控件Stimulsoft技术答疑：如何在二维码中编码数据？

报表控件Stimulsoft技术答疑：如何在二维码中编码数据？

Stimulsoft Reports是一款报告编写器&#xff0c;主要用于在桌面和Web上从头开始创建任何复杂的报告。可以在大多数平台上轻松实现部署&#xff0c;如ASP.NET, WinForms, .NET Core, JavaScript, WPF, Angular, Blazor, PHP, Java等&#xff0c;在你的应用程序中嵌入报告设计器…
阅读更多...
深度学习网络各种激活函数 Sigmoid、Tanh、ReLU、Leaky_ReLU、SiLU、Mish

深度学习网络各种激活函数 Sigmoid、Tanh、ReLU、Leaky_ReLU、SiLU、Mish

激活函数的目的就是为网络提供非线性化 梯度消失&#xff1a;梯度为0&#xff0c; 无法反向传播&#xff0c;导致参数得不到更新 梯度饱和&#xff1a;随着数据的变化&#xff0c;梯度没有明显变化 梯度爆炸&#xff1a;梯度越来越大&#xff0c;无法收敛 梯度消失问题&#…
阅读更多...
JavaWeb1-计算机是如何工作的？

JavaWeb1-计算机是如何工作的？

目录 1.计算机的构成 1.1.计算机二进制 1.2.冯诺依曼体系结构 1.2.1.CPU&#xff08;加工厂&#xff09; 1.2.2.存储器&#xff08;仓库&#xff09; 1.2.3.输⼊设备&#xff08;原材料&#xff09; 1.2.4.输出设备&#xff08;产品&#xff09; PS&#xff1a;关于存…
阅读更多...
Jmeter 并发业务场景如何控制接口只执行一次

Jmeter 并发业务场景如何控制接口只执行一次

今天在做并发测试&#xff0c;执行后会发现登录接口执行多次&#xff0c;实际只需执行一次就可以。 刚开始用了网上推荐的仅一次控制器&#xff0c;但是发现仅一次控制器对线程组无效。 其实只要对元件熟悉&#xff0c;这个问题很简单&#xff0c;只需要用吞吐量控制器&#xf…
阅读更多...
CDH数仓项目(四) —— 集群性能测试/资源管理/清理CDH集群

CDH数仓项目(四) —— 集群性能测试/资源管理/清理CDH集群

0 说明 本文基于《CDH数仓项目(一) —— CDH安装部署搭建详细流程》《CDH数仓项目(二) —— 用户行为数仓和业务数仓搭建》和《CDH数仓项目(三) —— Kerberos安全认证和Sentry权限管理》章节&#xff0c;本篇介绍些常见的性能测试和资源管理功能&#xff0c;及最后提供详细的…
阅读更多...
SpringMVC之五种类型参数传递

SpringMVC之五种类型参数传递

目录 一&#xff1a;普通参数 二&#xff1a;POJO数据类型 三&#xff1a;嵌套POJO类型参数 四&#xff1a;数组类型参数 五&#xff1a;集合类型参数 知识点1&#xff1a;RequestParam 前面我们已经能够使用GET或POST来发送请求和数据&#xff0c;所携带的数据都是比较简…
阅读更多...
深度学习中的attention机制

深度学习中的attention机制

SE 文章 https://openaccess.thecvf.com/content_cvpr_2018/papers/Hu_Squeeze-and-Excitation_Networks_CVPR_2018_paper.pdfhttps://openaccess.thecvf.com/content_cvpr_2018/papers/Hu_Squeeze-and-Excitation_Networks_CVPR_2018_paper.pdf class SELayer(nn.Module):…
阅读更多...
Java工具包类

Java工具包类

java.util包有很多实用的类、接口和异常。 向量类&#xff0c;堆栈类&#xff0c;哈希表&#xff0c;枚举接口&#xff0c;日历类&#xff0c;随机函数类&#xff0c;映射接口和属性类。 Vector类 vector是异构的&#xff0c;可以存储不同的对象&#xff0c;同时可以动态增加…
阅读更多...
【工具】国内苹果市场已上架 新一代社交产品 damus

【工具】国内苹果市场已上架 新一代社交产品 damus

国内苹果市场可下载 2月1日&#xff0c;Twitter 联合创始人 Jack Dorsey 发布推文表示&#xff0c;基于分布式社交媒体协议 Nostr 的社交产品 Damus 和 Amethyst 正式在苹果 App Store 和谷歌 Google Play Store 上线。 目前为止&#xff0c;Damus 在国内苹果应用市场是可以直…
阅读更多...
远程超大功率森林防火喊话与应急广播系统方案

远程超大功率森林防火喊话与应急广播系统方案

北京恒星科通发布于2023-2-2 一、引言 随着消灭宜林荒山和实现全面绿化&#xff0c;造林事业不断发展&#xff0c;林地面积、林业蓄积量逐年增加&#xff0c;如何加强森林防火、保护环境&#xff0c;是全国当前面临的一项重大任务。 森林火灾是一种突发性和破坏性极强的自然…
阅读更多...
Spring Security（新版本）实现权限认证与授权

Spring Security（新版本）实现权限认证与授权

学习新版SpringSecurity详细配置一、Spring Security介绍1、Spring Security简介2、历史3、同款产品对比3.1、Spring Security3.2、 Shiro二、Spring Security实现权限1、SpringSecurity入门1.1 添加依赖1.2、启动项目测试2、用户认证2.1、用户认证核心组件2.2、用户认证2.2.1、…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023