Go并发编程之goroutine使用正确方法

目录
  • 1. 对创建的gorouting负载
    • 1.1 不要创建一个你不知道何时退出的 goroutine
    • 1.2 不要帮别人做选择
    • 1.3 不要作为一个旁观者
    • 1.4 不要创建不知道什么时候退出的 goroutine
    • 1.5 不要创建都无法退出的 goroutine
    • 1.6 确保创建出的goroutine工作已经完成
  • 2. 总结
  • 3. 参考

并发(concurrency): 指在同一时刻只能有一条指令执行,但多个进程指令被快速的轮换执行,使得在宏观上具有多个进程同时执行的效果,但在微观上并不是同时执行的,只是把时间分成若干段,通过cpu时间片轮转使多个进程快速交替的执行。

1. 对创建的gorouting负载

1.1 不要创建一个你不知道何时退出的 goroutine

下面的代码有什么问题? 是不是在我们的程序种经常写类似的代码?

// Week03/blog/01/01.go
package main

import (
	"log"
	"net/http"
	_ "net/http/pprof"
)

// 初始化函数
func setup() {
	// 这里面有一些初始化的操作
}

// 入口函数
func main() {
	setup()

	// 主服务
	server()

	// for debug
	pprof()

	select {}
}

// http api server
func server() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/ping", func(w http.ResponseWriter, r *http.Request) {
			w.Write([]byte("pong"))
		})

		// 主服务
		if err := http.ListenAndServe(":8080", mux); err != nil {
			log.Panicf("http server err: %+v", err)
			return
		}
	}()
}

// 辅助服务,用来debug性能测试
func pprof() {
	// 辅助服务,监听了其他端口,这里是 pprof 服务,用于 debug
	go http.ListenAndServe(":8081", nil)
}

以上代码有几个问题,是否想到过?

  • 如果server 是在其他的包里面, 如果没有特殊的说明, 调用者是否知道这是一个异步调用?
  • main 函数种,最后使用select {} 使整个程序处于阻塞状态,也就是空转, 会不会存在浪费?
  • 如果线上出现事故,debug服务已经突出,你想要debug这时是否很茫然?
  • 如果某一天服务突然重启, 你却找不到事故日志, 是否能想到起的这个8801端口的服务呢?

1.2 不要帮别人做选择

把是否 并发 的选择权交给你的调用者,而不是自己就直接悄悄的用上了 goroutine

下面做如下改变,将两个函数是否并发操作的选择权留给main函数

package main

import (
    "log"
    "net/http"
    _ "net/http/pprof"
)

func setup(){
    // 初始化操作
}

func main(){

    setup()

    // for debug
    go pprof()

    // 主服务,http api
    go server()

    select{}
}

func server(){

    mux := http.NewServerMux()
    mux.HandleFunc("ping", func(w http.ResponseWriter, r * http.Request){
        w.Write([]byte("pong"))
    }

    // 主服务
    if err := http.ListerAndServer(":8080",mux); err != nil{
        log.panic("http server launch error: %v", err)
        return
    }

}

func pprof(){
    // 辅助服务 监听其他端口,这里是pprof服务,拥有debug
    http.ListerAndServer(":8081",nil)
}

1.3 不要作为一个旁观者

一般情况下,不要让 主进程称为一个无所事事的旁观者, 明明可以干活,但是最后使用一个select在那儿空跑,而且这种看着也怪,在没有特殊场景下尽量不要使用这种阻塞的方式

package main

import (
	"log"
	"net/http"
	_ "net/http/pprof"
)

func setup() {
	// 这里面有一些初始化的操作
}

func main() {
	setup()

	// for debug
	go pprof()

	// 主服务, http本来就是一个阻塞的服务
	server()
}

func server() {
	mux := http.NewServeMux()
	mux.HandleFunc("/ping", func(w http.ResponseWriter, r *http.Request) {
		w.Write([]byte("pong"))
	})

	// 主服务
	if err := http.ListenAndServe(":8080", mux); err != nil {
		log.Panicf("http server err: %+v", err)
		return
	}
}

func pprof() {
	// 辅助服务,监听了其他端口,这里是 pprof 服务,用于 debug
	http.ListenAndServe(":8081", nil)
}

1.4 不要创建不知道什么时候退出的 goroutine

很多时候我们在创建一个 协程(goroutine)后就放任不管了,如果程序永远运行下去,可能不会有什么问题,但实际情况并非如此, 我们的产品需要迭代,需要修复bug,需要不停进行构建,发布, 所以当程序退出后(主程序),运行的某些子程序并不会完全退出,比如这个 pprof, 他自身本来就是一个后台服务,但是当 main退出后,实际 pprof这个服务并不会退出,这样 pprof就会称为一个孤魂野鬼,称为一个 zombie, 导致goroutine泄漏。

所以再一次对程序进行修改, 保证 goroutine能正常退出

package main

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

func setup() {
	// 这里面有一些初始化的操作
}

func main() {
	setup()

	// 用于监听服务退出, 这里使用了两个 goroutine,所以 cap 为2
	done := make(chan error, 2)

	// 无缓冲的通道,用于控制服务退出,传入同一个 stop,做到只要有一个服务退出了那么另外一个服务也会随之退出
	stop := make(chan struct{}, 0)

	// for debug
	go func() {
		//  pprof 传递一个 channel
		fmt.Println("pprof start...")
		done <- pprof(stop)
		fmt.Printf("err1:%v\n", done)

	}()

	// 主服务
	go func() {
		fmt.Println("app start...")
		done <- app(stop)
		fmt.Printf("err2:%v\n", done)
	}()

	// stopped 用于判断当前 stop 的状态
	var stopped bool

	// 这里循环读取 done 这个 channel
	// 只要有一个退出了,我们就关闭 stop channel
	for i := 0; i < cap(done); i++ {

		// 对于有缓冲的chan, chan中无值会一直处于阻塞状态
	    // 对于app 服务会一直阻塞状态,不会有 数据写入到done 通道,只有在5s后,模拟的 pprof会有err写入chan,此时才会触发以下逻辑
		if err := <-done; err != nil {
			log.Printf("server exit err: %+v", err)
		}

		if !stopped {
			stopped = true
			// 通过关闭 无缓冲的channel 来通知所有的 读 stop相关的goroutine退出
			close(stop)
		}
	}
}

// http 服务
func app(stop <-chan struct{}) error {
	mux := http.NewServeMux()
	mux.HandleFunc("/ping", func(w http.ResponseWriter, r *http.Request) {
		w.Write([]byte("pong"))
	})

	return server(mux, ":8080", stop)
}

func pprof(stop <-chan struct{}) error {
	// 注意这里主要是为了模拟服务意外退出,用于验证一个服务退出,其他服务同时退出的场景
	// 因为这里没有返回err, 所以done chan中无法接收到值, 主程序中会一直阻塞住
	go func() {
		server(http.DefaultServeMux, ":8081", stop)
	}()

	time.Sleep(5 * time.Second)
	// 模拟出错
	return fmt.Errorf("mock pprof exit")
}

// 启动一个服务
func server(handler http.Handler, addr string, stop <-chan struct{}) error {

	s := http.Server{
		Handler: handler,
		Addr:    addr,
	}

	// 这个 goroutine 控制退出,因为 stop channel 只要close或者是写入数据,这里就会退出
	go func() {
		// 无缓冲channel等待,写入或者关闭
		<-stop
		log.Printf("server will exiting, addr: %s", addr)
		// 此时 httpApi 服务就会优雅的退出
		s.Shutdown(context.Background())
	}()

	// 没有触发异常的话,会一直处于阻塞
	return s.ListenAndServe()
}

查看以下运行结果

D:\gopath\controlGoExit>go run demo.go
app start...
pprof start...
err1:0xc00004c720
2021/09/12 22:48:37 server exit err: mock pprof exit
2021/09/12 22:48:37 server will exiting, addr: :8080
2021/09/12 22:48:37 server will exiting, addr: :8081
err2:0xc00004c720
2021/09/12 22:48:37 server exit err: http: Server closed

虽然我们已经经过了三轮优化,但是这里还是有一些需要注意的地方:

  1. 虽然我们调用了 Shutdown 方法,但是我们其实并没有实现优雅退出
  2. 在 server 方法中我们并没有处理 panic的逻辑,这里需要处理么?如果需要那该如何处理呢?

1.5 不要创建都无法退出的 goroutine

永远无法退出的 goroutine, 即 goroutine 泄漏

下面是一个例子,可能在不知不觉中会用到

package main

import (
    "log"
    _ "net/http/pprof"
    "net/http"

)

func setup() {
	// 这里面有一些初始化的操作
	log.Print("服务启动初始化...")
}

func main() {
	setup()

	// for debug
	go pprof()

	// 主服务, http本来就是一个阻塞的服务
	server()
}

func server() {
	mux := http.NewServeMux()
	mux.HandleFunc("/ping", func(w http.ResponseWriter, r *http.Request) {
		w.Write([]byte("pong"))
	})

	mux.HandleFunc("/leak", LeakHandle)

	// 主服务
	if err := http.ListenAndServe(":8080", mux); err != nil {
		log.Panicf("http server err: %+v", err)
		return
	}
}

func pprof() {
	// 辅助服务,监听了其他端口,这里是 pprof 服务,用于 debug
	http.ListenAndServe(":8081", nil)
}

func LeakHandle(w http.ResponseWriter, r *http.Request) {
	ch := make(chan bool, 0)
	go func() {
		fmt.Println("异步任务做一些操作")
		<-ch
	}()

	w.Write([]byte("will leak"))
}

复用一下上面的 server 代码,我们经常会写出这种类似的代码

  • http 请求来了,我们启动一个 goroutine 去做一些耗时一点的工作
  • 然后返回了
  • 然后之前创建的那个 goroutine 阻塞了(对于一个无缓冲的chan,如果没有接收或关闭操作会永远阻塞下去)
  • 然后就泄漏了

绝大部分的 goroutine 泄漏都是因为 goroutine 当中因为各种原因阻塞了,我们在外面也没有控制它退出的方式,所以就泄漏了

接下来我们验证一下是不是真的泄漏了

服务启动之后,访问debug访问网址,http://localhost:8081/debug/pprof/goroutine?debug=1.
当请求两次 http://127.0.0.1/leak后查看 goroutine数量,如图

继续请求三次后,如图

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

这个其实就是优雅退出的问题,程序中可能启动了很多的 goroutine 去处理一些问题,但是服务退出的时候我们并没有考虑到就直接退出了。例如退出前日志没有 flush 到磁盘,我们的请求还没完全关闭,异步 worker 中还有 job 在执行等等。

看一个例子,假设现在有一个埋点服务,每次请求我们都会上报一些信息到埋点服务上

// Reporter 埋点服务上报
type Reporter struct {
}

var reporter Reporter

// 模拟耗时
func (r Reporter) report(data string) {
	time.Sleep(time.Second)
	fmt.Printf("report: %s\n", data)
}

mux.HandleFunc("/ping", func(w http.ResponseWriter, r *http.Request) {
    // 在请求中异步调用
    // 这里并没有满足一致性
    go reporter.report("ping pong")
    fmt.Println("ping")
    w.Write([]byte("pong"))
})

在发送一次请后之后就直接退出了, 异步上报的逻辑是没有执行的

$ go tun demo.go
ping
^C signal:interrupt

有两种改法:

  • 一种是给 reporter 加上 shutdown 方法,类似 http 的 shutdown,等待所有的异步上报完成之后,再退出
  • 另外一种是我们直接使用 一些 worker 来执行,在当然这个 worker 也要实现类似 shutdown 的方法。

一般推荐后一种,因为这样可以避免请求量比较大时,创建大量 goroutine,当然如果请求量比较小,不会很大,用第一种也是可以的。

第二种方法代码如下:

// 埋点上报
package main

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

// Reporter 埋点服务上报
type Reporter struct {
	worker   int
	messages chan string
	wg       sync.WaitGroup
	closed   chan struct{}
	once     sync.Once
}

// NewReporter NewReporter
func NewReporter(worker, buffer int) *Reporter {
	return &Reporter{
		worker:   worker,
		messages: make(chan string, buffer),
		closed:   make(chan struct{}),
	}
}

// 执行上报
func (r *Reporter) Run(stop <-chan struct{}) {
	// 用于执行错误
	go func() {
		// 没有错误时
		<-stop
		fmt.Println("stop...")
		r.shutdown()
	}()

	for i := 0; i < r.worker; i++ {
		r.wg.Add(1)

		go func() {
			defer r.wg.Done()
			for {
				select {
				case <-r.closed:
					return
				case msg := <-r.messages:
					fmt.Printf("report: %s\n", msg)
				}
			}
		}()
	}

	r.wg.Wait()
	fmt.Println("report workers exit...")
}

// 这里不必关闭 messages
// 因为 closed 关闭之后,发送端会直接丢弃数据不再发送
// Run 方法中的消费者也会退出
// Run 方法会随之退出
func (r *Reporter) shutdown() {
	r.once.Do(func() { close(r.closed) })
}

// 模拟耗时
func (r *Reporter) Report(data string) {
	// 这个是为了及早退出
	// 并且为了避免我们消费者能力很强,发送者这边一直不阻塞,可能还会一直写数据
	select {
	case <-r.closed:
		fmt.Printf("reporter is closed, data will be discarded: %s \n", data)
	default:
	}

	select {
	case <-r.closed:
		fmt.Printf("reporter is closed, data will be discarded: %s \n", data)
	case r.messages <- data:
	}
}

func setup3() {
	// 初始化一些操作
	fmt.Println("程序启动...")
}

func main() {
	setup3()

	// 用于监听服务完成时退出
	done := make(chan error, 3)

	// 实例化一个 reporter
	reporter := NewReporter(2, 100)

	// 用于控制服务退出,传入同一个 stop,做到只要有一个服务退出了那么另外一个服务也会随之退出
	stop := make(chan struct{}, 0)

	// for debug
	go func() {
		done <- pprof3(stop)
	}()

	// http主服务
	go func() {
		done <- app3(reporter, stop)
	}()

	// 上报服务,接收一个监控停止的 chan
	go func() {
		reporter.Run(stop)
		done <- nil
	}()

	// 这里循环读取 done 这个 channel
	// 只要有一个退出了,我们就关闭 stop channel
	for i := 0; i < cap(done); i++ {

		// 对于有缓冲的chan, chan中无值会一直处于阻塞状态
		// 对于app 服务会一直阻塞状态,不会有 数据写入到done 通道,只有在5s后,模拟的 pprof会有err写入chan,此时才会触发以下逻辑
		if err := <-done; err != nil {
			log.Printf("server exit err: %+v", err)
		}
		// 通过关闭 无缓冲的channel 来通知所有的 读 stop相关的goroutine退出
		close(stop)
	}
}

func pprof3(stop <-chan struct{}) error {

	// 辅助服务,监听了其他端口,这里是 pprof 服务,用于 debug
	err := server3(http.DefaultServeMux, ":8081", stop)
	return err
}

func app3(report *Reporter, stop <-chan struct{}) error {

	mux := http.NewServeMux()
	mux.HandleFunc("/ping", func(w http.ResponseWriter, r *http.Request) {
		// 在请求中异步调用
		// 这里并没有满足一致性
		go report.Report("ping pong")
		fmt.Println("ping")

		_, err := w.Write([]byte("pong"))
		if err != nil {
			log.Println("response err")
		}
	})

	return server3(mux, ":8080", stop)
}

// 启动一个服务
func server3(handler http.Handler, addr string, stop <-chan struct{}) error {

	s := http.Server{
		Handler: handler,
		Addr:    addr,
	}

	// 这个 goroutine 控制退出,因为 stop channel 只要close 或者是写入数据,这里就会退出
	go func() {
		// 无缓冲channel等待,写入或者关闭
		<-stop
		log.Printf("server will exiting, addr: %s", addr)
		// 此时 httpApi 服务就会优雅的退出
		err := s.Shutdown(context.Background())
		if err != nil {
			log.Printf("server exiting occur error, %s", err.Error())
		}
	}()

	// 没有触发异常的化,会一直处于阻塞
	return s.ListenAndServe()
}

上面代码应该还有问题,等日后再做优化

第一种方法参考:reporter 添加shutdown方法

2. 总结

在使用go语言初期, 使用一个go关键字轻松开启一个异步协程,再加上chan很容易实现 生产者---》消费者 设计模型,但是在使用过程中往往忽略了 程序退出时资源回收的问题,也很容易写成一个数据使用一个go来处理,虽然官方说明了 创建一个goroutine的占用资源很小,但是再小的 占用空间也敌不过一个死循环啊。 所以在使用gorouine创建协程除了注意正确规定线程数以为,也要注意以下几点。

  • 将是否异步调用的选择泉交给调用者, 不然很有可能使用者不知道所调用的函数立使用了go
  • 如果要启动一个goroutine, 要对他负责

不用启动一个无法控制他退出或者无法知道何时退出的goroutine

启动goroutine时加上 panic recovery机制,避免服务直接不可用,可以使用如下代码

// DeferRecover defer recover from panic.
func DeferRecover(tag string, handlePanic func(error)) func() {
	return func() {
		if err := recover(); err != nil {
			log.Errorf("%s, recover from: %v\n%s\n", tag, err, debug.Stack())
			if handlePanic != nil {
				handlePanic(fmt.Errorf("%v", err))
			}
		}
	}
}

// WithRecover recover from panic.
func WithRecover(tag string, f func(), handlePanic func(error)) {
	defer DeferRecover(tag, handlePanic)()

	f()
}

// Go is a wrapper of goroutine with recover.
func Go(name string, f func(), handlePanic func(error)) {
	go WithRecover(fmt.Sprintf("goroutine %s", name), f, handlePanic)
}
  • 造成 goroutine 泄漏的主要原因就是 goroutine 中造成了阻塞,并且没有外部手段控制它退出

尽量避免在请求中直接启动 goroutine 来处理问题,而应该通过启动 worker 来进行消费,这样可以避免由于请求量过大,而导致大量创建 goroutine 从而导致 oom,当然如果请求量本身非常小,那当我没说

3. 参考

https://dave.cheney.net/practical-go/presentations/qcon-china.html

https://lailin.xyz/post/go-training-week3-goroutine.html#总结

https://www.ardanlabs.com/blog/2019/04/concurrency-trap-2-incomplete-work.html

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

到此这篇关于Go并发编程之正确使用goroutine的方法的文章就介绍到这了,更多相关Go并发编程goroutine内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

时间: 2021-09-13

Go语言学习之goroutine详解

什么是goroutine? Goroutine是建立在线程之上的轻量级的抽象.它允许我们以非常低的代价在同一个地址空间中并行地执行多个函数或者方法.相比于线程,它的创建和销毁的代价要小很多,并且它的调度是独立于线程的.在golang中创建一个goroutine非常简单,使用"go"关键字即可: package mainimport ( "fmt" "time")func learning() { fmt.Println("My firs

GO语言并发编程之互斥锁、读写锁详解

在本节,我们对Go语言所提供的与锁有关的API进行说明.这包括了互斥锁和读写锁.我们在第6章描述过互斥锁,但却没有提到过读写锁.这两种锁对于传统的并发程序来说都是非常常用和重要的. 一.互斥锁 互斥锁是传统的并发程序对共享资源进行访问控制的主要手段.它由标准库代码包sync中的Mutex结构体类型代表.sync.Mutex类型(确切地说,是*sync.Mutex类型)只有两个公开方法--Lock和Unlock.顾名思义,前者被用于锁定当前的互斥量,而后者则被用来对当前的互斥量进行解锁. 类型sy

golang并发编程的实现

go main函数的执行本身就是一个协程,当使用go关键字的时候,就会创建一个新的协程 channel channel 管道,用于在多个协程之间传递信号 无缓存管道 当对无缓冲通道写的时候,会一直阻塞等到某个协程对这个缓冲通道读 阻塞场景: 通道中无数据,但执行读通道. 通道中无数据,向通道写数据,但无协程读取. 综上,无缓存通道的读写必须同时存在,且读写分别在两个不同的协程 func main(){ ch := make(chan int) go func(ch chan int){ ch <

Go并发编程实践

前言 并发编程一直是Golang区别与其他语言的很大优势,也是实际工作场景中经常遇到的.近日笔者在组内分享了我们常见的并发场景,及代码示例,以期望大家能在遇到相同场景下,能快速的想到解决方案,或者是拿这些方案与自己实现的比较,取长补短.现整理出来与大家共享. 简单并发场景 很多时候,我们只想并发的做一件事情,比如测试某个接口的是否支持并发.那么我们就可以这么做: func RunScenario1() { count := 10 var wg sync.WaitGroup for i := 0;

golang 并发编程之生产者消费者详解

golang 最吸引人的地方可能就是并发了,无论代码的编写上,还是性能上面,golang 都有绝对的优势 学习一个语言的并发特性,我喜欢实现一个生产者消费者模型,这个模型非常经典,适用于很多的并发场景,下面我通过这个模型,来简单介绍一下 golang 的并发编程 go 并发语法 协程 go 协程是 golang 并发的最小单元,类似于其他语言的线程,只不过线程的实现借助了操作系统的实现,每次线程的调度都是一次系统调用,需要从用户态切换到内核态,这是一项非常耗时的操作,因此一般的程序里面线程太多会

Golang Goroutine的使用

什么是 Goroutine goroutine 是 Go 并行设计的核心.goroutine 说到底其实就是协程,它比线程更小,十几个 goroutine 可能体现在底层就是五六个线程,Go 语言内部帮你实现了这些 goroutine 之间的内存共享. 执行 goroutine 只需极少的栈内存(大概是4~5KB),当然会根据相应的数据伸缩.也正因为如此,可同时运行成千上万个并发任务.goroutine 比 thread 更易用.更高效.更轻便. 一般情况下,一个普通计算机跑几十个线程就有点负载

Golang 探索对Goroutine的控制方法(详解)

前言 在golang中,只需要在函数调用前加上关键字go即可创建一个并发任务单元,而这个新建的任务会被放入队列中,等待调度器安排.相比系统的MB级别线程栈,goroutine的自定义栈只有2KB,这使得我们能够轻易创建上万个并发任务,如此对性能提升不少.但随之而来的有以下几个问题: 如何等待所有goroutine的退出 如何限制创建goroutine的数量(信号量实现) 怎么让goroutine主动退出 探索--如何从外部杀死goroutine 本文记录了笔者就以上几个问题进行探究的过程,文中给

关于Golang中for-loop与goroutine的问题详解

背景 最近在学习MIT的分布式课程6.824的过程中,使用Go实现Raft协议时遇到了一些问题.分享出来供大家参考学习,下面话不多说了,来一起看看详细的介绍吧. 参见如下代码: for i := 0; i < len(rf.peers); i++ { DPrintf("i = %d", i) if i == rf.me { DPrintf("skipping myself #%d", rf.me) continue } go func() { DPrintf(

GOLANG使用Context管理关联goroutine的方法

一般一个业务很少不用到goroutine的,因为很多方法是需要等待的,例如http.Server.ListenAndServe这个就是等待的,除非关闭了Server或Listener,否则是不会返回的.除非是一个API服务器,否则肯定需要另外起goroutine发起其他的服务,而且对于API服务器来说,在http.Handler的处理函数中一般也需要起goroutine,如何管理这些goroutine,在GOLANG1.7提供context.Context. 先看一个简单的,如果启动两个goro

如何利用Golang写出高并发代码详解

前言 之前一直对Golang如何处理高并发http请求的一头雾水,这几天也查了很多相关博客,似懂非懂,不知道具体代码怎么写 下午偶然在开发者头条APP上看到一篇国外技术人员的一篇文章用Golang处理每分钟百万级请求,看完文章中的代码,自己写了一遍代码,下面自己写下自己的体会 核心要点 将请求放入队列,通过一定数量(例如CPU核心数)goroutine组成一个worker池(pool),workder池中的worker读取队列执行任务 实例代码 以下代码笔者根据自己的理解进行了简化,主要是表达出

利用Golang实现TCP连接的双向拷贝详解

前言 本文主要给大家介绍了关于Golang实现TCP连接的双向拷贝的相关内容,分享出来供大家参考学习,下面话不多说了,来一起看看详细的介绍吧. 最简单的实现 每次来一个Server的连接,就新开一个Client的连接.用一个goroutine从server拷贝到client,再用另外一个goroutine从client拷贝到server.任何一方断开连接,双向都断开连接. func main() { runtime.GOMAXPROCS(1) listener, err := net.Liste

golang将多路复异步io转成阻塞io的方法详解

前言 本文主要给大家介绍了关于golang 如何将多路复异步io转变成阻塞io的相关内容,分享出来供大家参考学习,下面话不多说了,来一起看看详细的介绍: package main import ( "net" ) func handleConnection(c net.Conn) { //读写数据 buffer := make([]byte, 1024) c.Read(buffer) c.Write([]byte("Hello from server")) } fu

golang模拟实现带超时的信号量示例代码

前言 最近在写项目,需要用到信号量等待一些资源完成,但是最多等待N毫秒.在看本文的正文之前,我们先来看下C语言里的实现方法. 在C语言里,有如下的API来实现带超时的信号量等待: SYNOPSIS #include <pthread.h> int pthread_cond_timedwait(pthread_cond_t *cond, pthread_mutex_t *mutex, const struct timespec *abstime); 然后在查看golang的document后,发

Golang中的sync.WaitGroup用法实例

WaitGroup的用途:它能够一直等到所有的goroutine执行完成,并且阻塞主线程的执行,直到所有的goroutine执行完成. 官方对它的说明如下: A WaitGroup waits for a collection of goroutines to finish. The main goroutine calls Add to set the number of goroutines to wait for. Then each of the goroutines runs and

详解Golang互斥锁内部实现

go语言提供了一种开箱即用的共享资源的方式,互斥锁(sync.Mutex), sync.Mutex的零值表示一个没有被锁的,可以直接使用的,一个goroutine获得互斥锁后其他的goroutine只能等到这个gorutine释放该互斥锁,在Mutex结构中只公开了两个函数,分别是Lock和Unlock,在使用互斥锁的时候非常简单,本文并不阐述使用. 在使用sync.Mutex的时候千万不要做值拷贝,因为这样可能会导致锁失效.当我们打开我们的IDE时候跳到我们的sync.Mutex 代码中会发现