go 并发编程 Goroutines（一）

最新推荐文章于 2024-01-29 21:50:44 发布
最新推荐文章于 2024-01-29 21:50:44 发布
阅读量197 收藏
点赞数
文章标签： golang 开发语言 后端
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/aa2533004938/article/details/121122776
版权
文章目录前言 一、pandas是什么？ 二、使用步骤 1.引入库 2.读入数据 总结前言项目选择Go通常是因为它的并发特性。Go 团队已经花了很大的精力使 Go 中的并发性 变得廉价(就硬件资源而言)和高效，但是使用 Go 的并发特性来编写代码是可能的，这既不可靠也不可行。我想留给你一些建议，以避免Go的并发特性带来的一些陷阱提示：以下是本篇文章正文内容，下面案例可供参考一、让自己忙碌起来或者自己完成工作英文：Keep yourself busy or do.
摘要由CSDN通过智能技术生成

文章目录

前言

项目选择Go通常是因为它的并发特性。Go 团队已经花了很大的精力使 Go 中的并发性  变得廉价(就硬件资源而言)和高效，但是使用 Go 的并发特性来编写代码是可能的，这既不可靠也不可行。我想留给你一些建议，以避免Go的并发特性带来的一些陷阱

提示：以下是本篇文章正文内容，下面案例可供参考

一、让自己忙碌起来或者自己完成工作

英文：Keep yourself busy or do the work yourself

我们看一下第一个例子

package main

import (
	"fmt"
	"log"
	"net/http"
)

func main() {
	http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintln(w, "Hello")
	})

    //开启一个 协程 处理http的监听
	go func() {
		if err := http.ListenAndServe(":8080", nil); err != nil {
			log.Fatal(err) // 如果出现错误立即退出 
		}
	}()
    

    //for 死循环
	for {
	}
}

这是一个简单的http的服务器，for 循环 在无限的浪费 CPU的资源 

二、将并发 或者 （选择权）留给 调用者

1.例子 一


func debug(){

	go http.ListenAndServe("127.0.0.1:8001", http.DefaultServeMux)
}

func app(){
	
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/", func(resp http.ResponseWriter, req *http.Request) {
			fmt.Fprintln(resp, "Hello, QCon!")
		})
		http.ListenAndServe("0.0.0.0:8080", mux)
	}()
	
}

func main() {

	 debug()  // debug
	 app()    // app traffic

	select{}
}

看上面的这个例子

开起了两个监听服务，8080是线上访问，8001 的debug

问题1.线上出现事故想要调试结果 debug 不知道什么时候退出了。这个时候就傻x 了？

问题2.main 函数进行了 一个 select{} 是不是一直阻塞 跟个傻x 一样！

问题3.如果说这两个服务在你的其他包里，也不写注释，其他人会发现这是一个 协程吗？

   例子  二

func debug(){

	 http.ListenAndServe("127.0.0.1:8001", http.DefaultServeMux)
}

func app(){

	mux := http.NewServeMux()
	mux.HandleFunc("/", func(resp http.ResponseWriter, req *http.Request) {
		fmt.Fprintln(resp, "Hello, QCon!")
	})
	http.ListenAndServe("0.0.0.0:8080", mux)

}

func main() {

	 go debug()  // debug
	 go app()    // app traffic

	select{}
}

这个例子 遵循了 将并发留给调用者

正如 Go 中的函数将并发性留给调用方一样，应用程序应该将监视其状态的工作留给调用它们的程序，如果调用失败，应用程序应该重新启动它们。不要让您的应用程序自己负责重新启动，这是一个最好从应用程序外部处理的过程

问题1.线上出现事故想要调试结果 debug 不知道什么时候退出了。这个时候就傻x 了？

问题2.main 函数进行了 一个 select{} 是不是一直阻塞 会显得很尴尬

例子三

func debug(){

	 if err := http.ListenAndServe("127.0.0.1:8001", http.DefaultServeMux); err != nil{
		 log.Fatal(err)
	 }
}

func app(){

	mux := http.NewServeMux()
	mux.HandleFunc("/", func(resp http.ResponseWriter, req *http.Request) {
		fmt.Fprintln(resp, "Hello, QCon!")
	})
	if err := http.ListenAndServe("0.0.0.0:8080", mux); err != nil {
		log.Fatal(err)
	}

}

func main() {

	 go debug()  // debug
	 go app()    // app traffic

	select{}
}

这个例子 如果两个监听其他一个返回err 就立即终止了。

我们真正想要的是将发生的任何错误传递回 goroutine 的发起者，这样它就可以知道 goroutine 为什么停止，可以干净地关闭进程

存在的问题

1.log.fatal  无法被捕获到的,main 函数无从得知。

2.select 还是一直在等待

三.在不知道什么时候会停止的情况下，不要开始一个goroutine

例子三

func serve(addr string, handler http.Handler, stop <-chan struct{}) error {
	s := http.Server{
		Addr:    addr,
		Handler: handler,
	}
    
   //开启一个协程接受 关闭信号 进行关闭
	go func() {
		<-stop // wait for stop signal
		s.Shutdown(context.Background())
	}()

	return s.ListenAndServe()
}

func serveApp(stop <-chan struct{}) error {
	mux := http.NewServeMux()
	mux.HandleFunc("/", func(resp http.ResponseWriter, req *http.Request) {
		fmt.Fprintln(resp, "Hello, QCon!")
	})
	return serve("0.0.0.0:8080", mux, stop)
}

func serveDebug(stop <-chan struct{}) error {
	return serve("127.0.0.1:8001", http.DefaultServeMux, stop)
}

func main() {
    //done 记录返回的错误
	done := make(chan error, 2)
    //定义终止信号
	stop := make(chan struct{})
   //开启 debug
	go func() {
		done <- serveDebug(stop)
	}()
    //开启主程序
	go func() {
		done <- serveApp(stop)
	}()

	var stopped bool  //只记录1次
    
    //因为有两个协程 所有循环2
	for i := 0; i < cap(done); i++ {
        //当其中一个返回error 时 会打印错误
		if err := <-done; err != nil {
			fmt.Println("error: %v", err)
		}
        //并通知协助进行关闭
		if !stopped {
			stopped = true
			close(stop)
		}
	}
}

每次我们在 done 通道上接收到一个值，我们就关闭 stop 通道，这会导致所有 goroutine 等待该通道关闭它们的 http。这反过来会导致所有剩余的列表和服务 goroutine 返回。一旦我们启动的所有 goroutine 都停止了，main.main 返回并且进程完全停止。

这个代码还是有一些缺陷的，server 里没有进行 错误捕获 Shutdown的错误 还是有可能停止失败的

四 goroutine 泄露

例子一

package main

import (
	"context"
	"fmt"
	"net/http"
	"net/http/pprof"
)

func serve(addr string, handler http.Handler, stop <-chan struct{}) error {
	s := http.Server{
		Addr:    addr,
		Handler: handler,
	}

	//开启一个协程接受 关闭信号 进行关闭
	go func() {
		<-stop // wait for stop signal
		s.Shutdown(context.Background())
	}()

	return s.ListenAndServe()
}

func serveApp(stop <-chan struct{}) error {
	mux := http.NewServeMux()
	mux.HandleFunc("/", func(resp http.ResponseWriter, req *http.Request) {
		fmt.Fprintln(resp, "Hello, QCon!")
	})
	mux.HandleFunc("/received", func(resp http.ResponseWriter, req *http.Request) {
		
		//泄露代码
		ch := make(chan int)
		//这个协程一直在等待 ch 发送的值 但是没有人会发 造成泄露
		go func() {
			val := <-ch
			fmt.Println("We received a value:", val)
		}()
		
		//请求这个链接会直接返回
		fmt.Fprintln(resp, "Hello, received!")
	})
	return serve(":8080", mux, stop)
}

func serveDebug(stop <-chan struct{}) error {
	pprofHandler := http.NewServeMux()
	pprofHandler.Handle("/debug/pprof/", http.HandlerFunc(pprof.Index))
	return serve(":8001", pprofHandler, stop)
}

func main() {
	//done 记录返回的错误
	done := make(chan error, 2)
	//定义终止信号
	stop := make(chan struct{})
	//开启 debug
	go func() {
		done <- serveDebug(stop)
	}()
	//开启主程序
	go func() {
		done <- serveApp(stop)
	}()

	var stopped bool //只记录1次

	//因为有两个协程 所有循环2
	for i := 0; i < cap(done); i++ {
		//当其中一个返回error 时 会打印错误
		if err := <-done; err != nil {
			fmt.Println("error: %v", err)
		}
		//并通知协助进行关闭
		if !stopped {
			stopped = true
			close(stop)
		}
	}
}

/received 请求这个url 测试泄露

下面是，请求这个链接多次 和最初的对比

 没有请求这个url时的协程数量 只有8个

 但是多请求几次就会出现 很多 协程无法退出 造成泄露

确保创建出的 goroutine 的工作已经完成 

package main

import (
	"context"
	"fmt"
	"net/http"
	"net/http/pprof"
	"time"
)

func serve(addr string, handler http.Handler, stop <-chan struct{}) error {
	s := http.Server{
		Addr:    addr,
		Handler: handler,
	}

	//开启一个协程接受 关闭信号 进行关闭
	go func() {
		<-stop // wait for stop signal
		s.Shutdown(context.Background())
	}()

	return s.ListenAndServe()
}

func serveApp(stop <-chan struct{}) error {
	mux := http.NewServeMux()
	mux.HandleFunc("/", func(resp http.ResponseWriter, req *http.Request) {
		fmt.Fprintln(resp, "Hello, QCon!")
	})
	mux.HandleFunc("/received", func(resp http.ResponseWriter, req *http.Request) {

		//泄露代码
		ch := make(chan int)
		//这个协程一直在等待 ch 发送的值 但是没有人会发 造成泄露
		go func() {
			val := <-ch
			fmt.Println("We received a value:", val)
		}()

		//请求这个链接会直接返回
		fmt.Fprintln(resp, "Hello, received!")
	})

	mux.HandleFunc("/index", func(resp http.ResponseWriter, req *http.Request) {
		
		go func() {
			 time.Sleep(time.Second * 5)  //进行上报信息
			fmt.Println("请求上报信息")
		}()

		//请求这个链接会直接返回
		fmt.Fprintln(resp, "Hello, index!")
	})
	return serve(":8080", mux, stop)
}

func serveDebug(stop <-chan struct{}) error {
	pprofHandler := http.NewServeMux()
	pprofHandler.Handle("/debug/pprof/", http.HandlerFunc(pprof.Index))
	return serve(":8001", pprofHandler, stop)
}

func main() {
	//done 记录返回的错误
	done := make(chan error, 2)
	//定义终止信号
	stop := make(chan struct{})
	//开启 debug
	go func() {
		done <- serveDebug(stop)
	}()
	//开启主程序
	go func() {
		done <- serveApp(stop)
	}()

	var stopped bool //只记录1次

	//因为有两个协程 所有循环2
	for i := 0; i < cap(done); i++ {
		//当其中一个返回error 时 会打印错误
		if err := <-done; err != nil {
			fmt.Println("error: %v", err)
		}
		//并通知协助进行关闭
		if !stopped {
			stopped = true
			close(stop)
		}
	}
}

这个例子加了一个index 的url 里面进行的一些上报信息的操作

问题1.如果这个上报一直等待 就会造成泄露 

问题2.你永远也不知道什么时候停止


总结

  1. 请将是否并发调用的选择权交给调用者。
  2. 请你对开启的协程负责。2.1 永远不要开启一个你不知道什么时候退出的协程。2.2要管控这个协程的生命周期 知道什么嘛时候退出。不管是chen 还是 context 
  3. 尽量避免在请求中开启协程，上报的执行任务可以投递到消息队列或者自己定义worker里避免协程的泄露 

一些大佬的文献

Practical Go: Real world advice for writing maintainable Go programs

Concurrency Trap #2: Incomplete Work

https://www.ardanlabs.com/blog/2018/11/goroutine-leaks-the-forgotten-sender.html

https://www.ardanlabs.com/blog/2014/01/concurrency-goroutines-and-gomaxprocs.html

aa2533004938
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
golang chan总结
云上听风的博客
05-04 3122
goroutine和chan配合是golang的核心技术, 必须深入研究一下使用方法. 无缓冲chan 进和出都会阻塞. 例1: func main() { ch := make(chan error) fmt.Println("main1") go func() { fmt.Println("go1") ch &lt;...
老手也常误用！详解 Go channel 内存泄漏问题
九度新一的博客
08-08 1507
一说到 go channel，很多人会使用“优秀”“哲学”这些词汇来描述。殊不知，go channel 恐怕还是 golang 中最容易造成问题的特性之一。很多情况下，我们使用 go channel 时，常常以为可以关闭 channel，但实际上却没有关闭，这就是导致 go channel 内存泄漏的元凶。阅读本文前要求读者熟悉 go channel 的基本知识。如果你不够了解 go channel，那么可以先阅读。本文会默认你已经了解相关内容。...
【Go-Zero】Windows启动rpc服务报错panic:context deadline exceeded解决方案
寸铁的博客
01-29 2279
【Go-Zero】Windows启动rpc服务报错panic:context deadline exceeded解决方案
【问题解决】panic: qtls.ClientHelloInfo doesn‘t match goroutine 1 [running]: github.com/marten-seemann/qt
Kaimar的博客
11-01 2070
在跑Go代码的时候报错，如下问题 panic: qtls.ClientHelloInfo doesn't match goroutine 1 [running]: github.com/marten-seemann/qtls-go1-15.init.0() github.com/marten-seemann/qtls-go1-15@v0.1.1/unsafe.go:20 +0x168 原因 go的版本问题，这个qtls是在go1.15版本下build的项目，所以如果版本与它不匹配就.
背事故？分享 6 种常见的 Go 致命错误场景
weixin_64314555的博客
12-24 871
有一次事故现场，在紧急恢复后，他正在排查代码，查了好一会。我回头一看，这错误提醒很明显就是致命错误，较好定位。 但此时，他竟然在查 panic-recover 是不是哪里漏了，我表示大受震惊... 今天就由煎鱼给大家分享一下错误类型有哪几种，又在什么场景下会触发。 错误类型 error 第一种是 Go 中最标准的 error 错误，其真身是一个 interface{}。 如下： type error interface { Error() string } 复制代码 在日常工程中，
Go语言进阶：并发编程与goroutines详解
最新发布
06-29
Go语言进阶Go语言进阶Go语言进阶Go语言进阶Go语言进阶Go语言进阶Go语言进阶Go语言进阶Go语言进阶Go语言进阶Go语言进阶Go语言进阶Go语言进阶Go语言进阶Go语言进阶Go语言进阶Go语言进阶Go语言进阶Go语言进阶Go语言进阶...
go并发编程实践V2+源代码
03-27
2. **Channels**：Channels是Go语言中实现并发安全通信的关键工具，它们提供了一种安全的方式，让goroutines之间能够共享数据，避免了传统并发编程中的数据竞争问题。通过发送和接收操作，goroutines可以共享数据流...
Go 并发编程实战
12-11
在编程领域，Go 语言以其独特的并发模型和强大的性能吸引了众多开发者。并发编程是现代软件设计中的...《Go 并发编程实战》这本书将带你逐步探索 Go 语言并发编程的世界，通过实例和讲解，帮助你提升并发编程的能力。
桫哥-GOlang-13并发编程
06-12
"桫哥-GOlang-13并发编程"的主题深入探讨了Go语言的并发编程这一关键特性，这对于理解和编写高效、可扩展的Go程序至关重要。 并发编程是现代软件开发中的一个核心概念，它允许程序同时执行多个任务，从而提高系统...
golang 线程与通道
begeneral的专栏
01-21 5550
golang的线程和通道
kubenetes源码分析之DNS（六）
热门推荐
柳清风的专栏
04-17 5万+
上一篇介绍了kubends相关代码，但他并不是直接提供服务的，而是dnsmasq-nanny。nanny这个单词是保姆的意思，就是一个dns服务的保姆，挺形象的，那么我们看看这个保姆是如何服务的。 首先看服务启动：func main() { parseFlags() glog.V(0).Infof("opts: %v", opts) sync := config.NewFil
Go函数并发情况的错误处理
小僵尸打字员的博客
06-30 367
最近遇到了一个很有意思的问题, 感觉值得写一篇博客来记录一下, 也在大家遇到这种问题的时候可以有个参考; 下面这段代码大家都不陌生吧, 一个简单的多程处理, 大家可以看看有没有什么问题
golang chan make前后值比较
dayello的专栏
05-06 3779
package main import (     "fmt" ) func main() {     var chtest chan string     fmt.Println("no make:", chtest)     chtest = make(chan string, 10)     fmt.Println("make no value:", chtest
go随聊-chan使用的坑
九品神元师
10-24 817
Go中chan是分阻塞和非阻塞(带缓冲)的 创建非缓冲的chan ch:=make(chan int) ch&lt;-1 fmt.Println("run") 运行会报：fatal error: all goroutines are asleep - deadlock!  因为这种方式创建的是非缓冲的chan 创建带缓冲的chan ch:=make(chan int,1) ch&lt...
详解go语言 make(chan int, 1) 和 make (chan int) 的区别
qq_31406415的博客
12-03 6955
无缓冲区channel 用make(chan int) 创建的chan, 是无缓冲区的, send 数据到chan 时，在没有协程取出数据的情况下， 会阻塞当前协程的运行。ch <- 后面的代码就不会再运行，直到channel 的数据被接收，当前协程才会继续往下执行。 1 2 3 4 5 6 7 8 9 10 11 ch := make(chan int) // 创建无缓冲channel
go新手容易犯的三个致命错误
weixin_33921089的博客
01-20 270
前言 最近因为以前一些重要且古老的go项目基本没有人专职维护了，所以被安排去熟悉这些项目的代码，所以看了大量go的代码。历史原因，这些代码中或多或少有一些刚刚从PHPer转过来的Gopher去设计和开发的，自然有不少是在php(fpm模式下)码代码思路下埋藏的一些坑。今天我就来和大家一起分享一下最近发现的比较不容易发现和出现比率比较高的三...
『每周译Go』Go 语言的 goroutine 性能分析
Go中国
10-27 967
本文档最后一次更新时所用的 Go 版本是 1.15.6，但是大多数情况下，新老版本都适用。描述Go 运行时在一个称为 allgs 简单切片追踪所有的 goroutines。这里面包含了活跃...
一看就懂系列之Golang的goroutine和通道
咖啡色的羊驼
07-24 3万+
前言 10s后，以下知识点即将靠近： 1.从并发模型说起 2.goroutine的简介 3.goroutine的使用姿势 4.通道(channel)的简介 5.重要的四种通道使用 6.goroutine死锁与处理 7.select的多路复用 8.select死锁 正文 1.从并发模型说起 看过很多大神简介，各种研究高并发，那么就通俗的说下并发。 并发目前来看比较主流的...
Go语言并发编程：goroutine与并发控制
Go语言并发是其设计中的一个核心特性，使得编写高效的多任务程序变得更加简单。goroutine是Go语言中实现并发的基本单元，类似于轻量级线程。每个Go程序至少有一个main goroutine，它是程序启动时自动创建并执行的。...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值