Go语言上下文context底层原理

目录
  • 1. context 介绍
  • 2. 基本介绍
  • 3. 源码分析
    • 3.1 Context 接口
    • 3.2 emptyCtx
    • 3.3 cancelCtx
    • 3.4 timerCtx
    • 3.5 valueCtx
  • 4. 使用建议

1. context 介绍

很多时候,我们会遇到这样的情况,上层与下层的goroutine需要同时取消,这样就涉及到了goroutine间的通信。在Go中,推荐我们以通信的方式共享内存,而不是以共享内存的方式通信。所以,就需要用到channl,但是,在上述场景中,如果需要自己去处理channl的业务逻辑,就会有很多费时费力的重复工作,因此,context出现了。

context是Go中用来进程通信的一种方式,其底层是借助channlsnyc.Mutex实现的。

2. 基本介绍

context的底层设计,我们可以概括为1个接口,4种实现与6个方法。

1 个接口

  • Context 规定了context的四个基本方法

4 种实现

  • emptyCtx 实现了一个空的context,可以用作根节点
  • cancelCtx 实现一个带cancel功能的context,可以主动取消
  • timerCtx 实现一个通过定时器timer和截止时间deadline定时取消的context
  • valueCtx 实现一个可以通过 key、val 两个字段来存数据的context

6 个方法:

  • Background 返回一个emptyCtx作为根节点
  • TODO 返回一个emptyCtx作为未知节点
  • WithCancel 返回一个cancelCtx
  • WithDeadline 返回一个timerCtx
  • WithTimeout 返回一个timerCtx
  • WithValue 返回一个valueCtx

3. 源码分析

3.1 Context 接口

type Context interface {
    Deadline() (deadline time.Time, ok bool)
    Done() <-chan struct{}
    Err() error
    Value(key interface{}) interface{}
}
  • Deadline() :返回一个time.Time,表示当前Context应该结束的时间,ok则表示有结束时间
  • Done():返回一个只读chan,如果可以从该 chan 中读取到数据,则说明 ctx 被取消了
  • Err():返回 Context 被取消的原因
  • Value(key):返回key对应的value,是协程安全的

3.2 emptyCtx

type emptyCtx int

func (*emptyCtx) Deadline() (deadline time.Time, ok bool) {
	return
}

func (*emptyCtx) Done() <-chan struct{} {
	return nil
}

func (*emptyCtx) Err() error {
	return nil
}

func (*emptyCtx) Value(key interface{}) interface{} {
	return nil
}

emptyCtx实现了空的Context接口,其主要作用是为BackgroundTODO这两个方法都会返回预先初始化好的私有变量 background 和 todo,它们会在同一个 Go 程序中被复用:

var (
    background = new(emptyCtx)
    todo       = new(emptyCtx)
)

func Background() Context {
    return background
}
func TODO() Context {
	return todo
}

BackgroundTODO在实现上没有区别,只是在使用语义上有所差异:

  • Background是上下文的根节点;
  • TODO应该仅在不确定应该使用哪种上下文时使用;

3.3 cancelCtx

cancelCtx实现了canceler接口与Context接口:

type canceler interface {
	cancel(removeFromParent bool, err error)
	Done() <-chan struct{}
}

其结构体如下:

type cancelCtx struct {
    // 直接嵌入了一个 Context,那么可以把 cancelCtx 看做是一个 Context
	Context

	mu       sync.Mutex            // protects following fields
	done     atomic.Value          // of chan struct{}, created lazily, closed by first cancel call
	children map[canceler]struct{} // set to nil by the first cancel call
	err      error                 // set to non-nil by the first cancel call
}

我们可以使用WithCancel的方法来创建一个cancelCtx:

func WithCancel(parent Context) (ctx Context, cancel CancelFunc) {
	if parent == nil {
		panic("cannot create context from nil parent")
	}
	c := newCancelCtx(parent)
	propagateCancel(parent, &c)
	return &c, func() { c.cancel(true, Canceled) }
}
func newCancelCtx(parent Context) cancelCtx {
	return cancelCtx{Context: parent}
}

上面的方法,我们传入一个父 Context(这通常是一个 background,作为根节点),返回新建的 context,并通过闭包的形式,返回了一个 cancel 方法。

newCancelCtx将传入的上下文包装成私有结构体context.cancelCtx

propagateCancel则会构建父子上下文之间的关联,形成树结构,当父上下文被取消时,子上下文也会被取消:

func propagateCancel(parent Context, child canceler) {
    // 1.如果 parent ctx 是不可取消的 ctx,则直接返回 不进行关联
	done := parent.Done()
	if done == nil {
		return // parent is never canceled
	}
    // 2.接着判断一下 父ctx 是否已经被取消
	select {
	case <-done:
        // 2.1 如果 父ctx 已经被取消了,那就没必要关联了
        // 然后这里也要顺便把子ctx给取消了,因为父ctx取消了 子ctx就应该被取消
        // 这里是因为还没有关联上,所以需要手动触发取消
		// parent is already canceled
		child.cancel(false, parent.Err())
		return
	default:
	}
    // 3. 从父 ctx 中提取出 cancelCtx 并将子ctx加入到父ctx 的 children 里面
	if p, ok := parentCancelCtx(parent); ok {
		p.mu.Lock()
        // double check 一下,确认父 ctx 是否被取消
		if p.err != nil {
            // 取消了就直接把当前这个子ctx给取消了
			// parent has already been canceled
			child.cancel(false, p.err)
		} else {
            // 否则就添加到 children 里面
			if p.children == nil {
				p.children = make(map[canceler]struct{})
			}
			p.children[child] = struct{}{}
		}
		p.mu.Unlock()
	} else {
        // 如果没有找到可取消的父 context。新启动一个协程监控父节点或子节点取消信号
		atomic.AddInt32(&goroutines, +1)
		go func() {
			select {
			case <-parent.Done():
				child.cancel(false, parent.Err())
			case <-child.Done():
			}
		}()
	}
}

上面的方法可能遇到以下几种情况:

  • 当 parent.Done() == nil,也就是 parent 不会触发取消事件时,当前函数会直接返回;
  • 当 child 的继承链包含可以取消的上下文时,会判断 parent 是否已经触发了取消信号;
    • 如果已经被取消,child 会立刻被取消;
    • 如果没有被取消,child 会被加入 parent 的 children 列表中,等待 parent 释放取消信号;
  • 当父上下文是开发者自定义的类型、实现了 context.Context 接口并在 Done() 方法中返回了非空的管道时;
    • 运行一个新的 Goroutine 同时监听 parent.Done() 和 child.Done() 两个 Channel;
    • 在 parent.Done() 关闭时调用 child.cancel 取消子上下文;

propagateCancel 的作用是在 parent 和 child 之间同步取消和结束的信号,保证在 parent 被取消时,child 也会收到对应的信号,不会出现状态不一致的情况。

func parentCancelCtx(parent Context) (*cancelCtx, bool) {
	done := parent.Done()
    // 如果 done 为 nil 说明这个ctx是不可取消的
    // 如果 done == closedchan 说明这个ctx不是标准的 cancelCtx,可能是自定义的
	if  done == closedchan || done == nil {
		return nil, false
	}
    // 然后调用 value 方法从ctx中提取出 cancelCtx
	p, ok := parent.Value(&cancelCtxKey).(*cancelCtx)
	if !ok {
		return nil, false
	}
    // 最后再判断一下cancelCtx 里存的 done 和 父ctx里的done是否一致
    // 如果不一致说明parent不是一个 cancelCtx
	pdone, _ := p.done.Load().(chan struct{})
	if pdone != done {
		return nil, false
	}
	return p, true
}

ancelCtx 的 done 方法会返回一个 chan struct{}

func (c *cancelCtx) Done() <-chan struct{} {
	d := c.done.Load()
	if d != nil {
		return d.(chan struct{})
	}
	c.mu.Lock()
	defer c.mu.Unlock()
	d = c.done.Load()
	if d == nil {
		d = make(chan struct{})
		c.done.Store(d)
	}
	return d.(chan struct{})
}
var closedchan = make(chan struct{})

parentCancelCtx 其实就是判断 parent context 里面有没有一个 cancelCtx,有就返回,让子context可以“挂靠”到parent context 上,如果不是就返回false,不进行挂靠,自己新开一个 goroutine 来监听。

3.4 timerCtx

timerCtx 内部不仅通过嵌入 cancelCtx 的方式承了相关的变量和方法,还通过持有的定时器 timer 和截止时间 deadline 实现了定时取消的功能:

type timerCtx struct {
	cancelCtx
	timer *time.Timer // Under cancelCtx.mu.

	deadline time.Time
}
func (c *timerCtx) Deadline() (deadline time.Time, ok bool) {
	return c.deadline, true
}
func (c *timerCtx) cancel(removeFromParent bool, err error) {
	c.cancelCtx.cancel(false, err)
	if removeFromParent {
		removeChild(c.cancelCtx.Context, c)
	}
	c.mu.Lock()
	if c.timer != nil {
		c.timer.Stop()
		c.timer = nil
	}
	c.mu.Unlock()
}

3.5 valueCtx

valueCtx 是多了 key、val 两个字段来存数据:

type valueCtx struct {
	Context
	key, val interface{}
}

取值查找的过程,实际上是一个递归查找的过程:

func (c *valueCtx) Value(key interface{}) interface{} {
	if c.key == key {
		return c.val
	}
	return c.Context.Value(key)
}

如果 key 和当前 ctx 中存的 value 一致就直接返回,没有就去 parent 中找。最终找到根节点(一般是 emptyCtx),直接返回一个 nil。所以用 Value 方法的时候要判断结果是否为 nil,类似于一个链表,效率是很低的,不建议用来传参数。

4. 使用建议

在官方博客里,对于使用 context 提出了几点建议:

  • 不要将 Context 塞到结构体里。直接将 Context 类型作为函数的第一参数,而且一般都命名为 ctx。
  • 不要向函数传入一个 nil 的 context,如果你实在不知道传什么,标准库给你准备好了一个 context:todo。
  • 不要把本应该作为函数参数的类型塞到 context 中,context 存储的应该是一些共同的数据。例如:登陆的 session、cookie 等。
  • 同一个 context 可能会被传递到多个 goroutine,别担心,context 是并发安全的。

到此这篇关于Go语言上下文context底层原理的文章就介绍到这了,更多相关Go context 内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • Go语言context上下文管理的使用

    目录 context有什么作用 传递共享的数据 取消goroutine 防止goroutine泄漏 context.Value的查找过程是怎样的 context 有什么作用 context 主要用来在goroutine 之间传递上下文信息,包括:取消信号.超时时间.截止时间.k-v 等. Go 常用来写后台服务,通常只需要几行代码,就可以搭建一个 http server. 在 Go 的 server 里,通常每来一个请求都会启动若干个 goroutine 同时工作:有些去数据库拿数据,有些调用下

  • GoLang之使用Context控制请求超时的实现

    起因   之前接触了一个需求:提供一个接口,这个接口有一个超时时间,如果超时了返回超时异常:这个接口中调用其他的接口,如果调用超时了,所有请求全部结束.   在这个接口中,我使用了go协程去调用其他接口,所以不仅涉及到请求的超时控制,而且还涉及到父协程对子协程的控制问题.在翻阅了一些资料之后,了解到了Context的基本知识. Context   Context是golang.org.pkg下的一个包,类型是接口类型.主要功能有 父协程控制所有的子协程   Context可以通过context.

  • Go中groutine通信与context控制实例详解

    目录 需求背景: Groutine的并发控制: Context: 看看代码: 总结 需求背景: 项目中需要定期执行任务A来做一些辅助的工作,A的执行需要在超时时间内完成,如果本次执行超时了,那就不对本次的执行结果进行处理(即放弃这次执行).同时A又依赖B,C两个子任务的执行结果.B, C之间相互独立,可以并行的执行.但无论B,C哪一个执行失败或超时都会导致本次任务执行失败. Groutine的并发控制: go中对于groutine的并发控制有三种解决方案: 通过channel控制. 父grout

  • 详解Go语言的context包从放弃到入门

    一.Context包到底是干嘛用的 我们会在用到很多东西的时候都看到context的影子,比如gin框架,比如grpc,这东西到底是做啥的? 大家都在用,没几个知道这是干嘛的,知其然而不知其所以然, 谁都在CRUD,谁都觉得if else就完了,有代码能copy我也行,原理啥啥不懂不重要,反正就是一把梭 原理说白了就是: 当前协程取消了,可以通知所有由它创建的子协程退出 当前协程取消了,不会影响到创建它的父级协程的状态 扩展了额外的功能:超时取消.定时取消.可以给子协程共享数据 二.主协程退出通

  • go语言context包功能及操作使用详解

    目录 Context包到底是干嘛用的? context原理 什么时候应该使用 Context? 如何创建 Context? 主协程通知有子协程,子协程又有多个子协程 context核心接口 emptyCtx结构体 Backgroud TODO valueCtx结构体 WithValue向context添加值 Value向context取值 示例 WithCancel可取消的context cancelCtx结构体 WithDeadline-超时取消context WithTimeout-超时取消

  • Go语言context test源码分析详情

    目录 1.测试例子分析 2.单元测试 1.测试例子分析 example_test.go,展示了With-系列的4个例子 func ExampleWithCancel() {   gen := func(ctx context.Context) <-chan int {     dst := make(chan int)     n := 1     go func() {       for {         select {         case <-ctx.Done():      

  • 使用Golang的Context管理上下文的方法

    golang 1.7版本中context库被很多标准库的模块所使用,比如net/http和os的一些模块中,利用这些原生模块,我们就不需要自己再写上下文的管理器了,直接调用函数接口即可实现,利用context我们可以实现一些比如请求的声明周期内的变量管理,执行一些操作的超时等等. 保存上下文对象 这里我们通过一个简单的例子来看一下如何使用context的特性来实现上下文的对象保存,这里我们写了一个简单的http server,具有登录和退出,状态检查路由(检查用户是否登录) func main(

  • golang中context的作用详解

    当一个goroutine可以启动其他goroutine,而这些goroutine可以启动其他goroutine,依此类推,则第一个goroutine应该能够向所有其它goroutine发送取消信号. 上下文包的唯一目的是在goroutine之间执行取消信号,而不管它们如何生成.上下文的接口定义为: type Context interface { Deadline() (deadline time.Time, ok bool) Done() <- chan struct{} Err() erro

  • 对Go语言中的context包源码分析

    目录 一.包说明分析 二.包结构分析 三.Context接口类型分析 四.后续分析规划 五.基于实现类型到常用函数 六.With-系列函数 七.扩展功能以及如何扩展 八.补充 一.包说明分析 context包:这个包分析的是1.15 context包定义了一个Context类型(接口类型),通过这个Context接口类型, 就可以跨api边界/跨进程传递一些deadline/cancel信号/request-scoped值. 发给server的请求中需要包含Context,server需要接收C

  • Go语言上下文context底层原理

    目录 1. context 介绍 2. 基本介绍 3. 源码分析 3.1 Context 接口 3.2 emptyCtx 3.3 cancelCtx 3.4 timerCtx 3.5 valueCtx 4. 使用建议 1. context 介绍 很多时候,我们会遇到这样的情况,上层与下层的goroutine需要同时取消,这样就涉及到了goroutine间的通信.在Go中,推荐我们以通信的方式共享内存,而不是以共享内存的方式通信.所以,就需要用到channl,但是,在上述场景中,如果需要自己去处理

  • Go语言中的并发goroutine底层原理

    目录 一.基本概念 ①并发.并行区分 ②从用户态线程,内核态线程阐述go与java并发的优劣 ②高并发为什么是Go语言强项? ③Go语言实现高并发底层GMP模型原理解析 二.上代码学会Go语言并发 ①.开启一个简单的线程 ②.动态的关闭线程 一.基本概念 ①并发.并行区分 1.概念 并发:同一时间段内一个对象执行多个任务,充分利用时间 并行:同一时刻,多个对象执行多个任务 2.图解 类似于超市柜台结账,并行是多个柜台结多个队列,在计算机中是多核cpu处理多个go语言开启的线程,并发是一个柜台结账

  • Go语言底层原理互斥锁的实现原理

    目录 Go 互斥锁的实现原理? 概念 使用场景 底层实现结构 操作 加锁 解锁 Go 互斥锁正常模式和饥饿模式的区别? 正常模式(非公平锁) 饥饿模式(公平锁) Go 互斥锁允许自旋的条件? Go 互斥锁的实现原理? Go sync包提供了两种锁类型:互斥锁sync.Mutex 和 读写互斥锁sync.RWMutex,都属于悲观锁. 概念 Mutex是互斥锁,当一个 goroutine 获得了锁后,其他 goroutine 不能获取锁(只能存在一个写者或读者,不能同时读和写) 使用场景 多个线程

  • 详解Golang中Context的原理和使用技巧

    目录 Context 背景 和 适用场景 Context 的背景 Context 的功能和目的 Context 的基本使用 Context 的同步控制设计 Context 的定义和实现 Context interface 接口定义 parent Context 的具体实现 Context 的继承和各种 With 系列函数 Context 的常用方法实例 1. 调用 Context Done方法取消 2. 通过 context.WithValue 来传值 3. 超时取消 context.WithT

  • Java并发编程深入理解之Synchronized的使用及底层原理详解 下

    目录 一.synchronized锁优化 1.自旋锁与自适应自旋 2.锁消除 逃逸分析: 3.锁粗化 二.对象头内存布局 三.synchronized锁的膨胀升级过程 1.偏向锁 2.轻量级锁 3.重量级锁 4.各种锁的优缺点 接着上文<Java并发编程深入理解之Synchronized的使用及底层原理详解 上>继续介绍synchronized 一.synchronized锁优化 高效并发是从JDK 5升级到JDK 6后一项重要的改进项,HotSpot虚拟机开发团队在这个版本上花费了大量的资源

  • Java 8 动态类型语言Lambda表达式实现原理解析

    Java 8支持动态语言,看到了很酷的Lambda表达式,对一直以静态类型语言自居的Java,让人看到了Java虚拟机可以支持动态语言的目标. import java.util.function.Consumer; public class Lambda { public static void main(String[] args) { Consumer<String> c = s -> System.out.println(s); c.accept("hello lambd

  • Go 并发控制context实现原理剖析(小结)

    1. 前言 Golang context是Golang应用开发常用的并发控制技术,它与WaitGroup最大的不同点是context对于派生goroutine有更强的控制力,它可以控制多级的goroutine. context翻译成中文是"上下文",即它可以控制一组呈树状结构的goroutine,每个goroutine拥有相同的上下文. 典型的使用场景如下图所示: 上图中由于goroutine派生出子goroutine,而子goroutine又继续派生新的goroutine,这种情况下

  • Compare And Swap底层原理及代码示例详解

    概念 CAS的全称是Compare-And-Swap,它是cpu并发原语 它的功能是判断内存某个位置的值是否为预期值.如果是则更改为新的值,这个过程是原子的 CAS并发原语体现在java语言中就是sun.misc.Unsafe类的各个方法.调用UnSafe类中的CAS方法,JVM会帮我们实现出CAS汇编指令,这是一种完全依赖于硬件的功能,通过它实现了原子操作,再次强调,由于CAS是一种系统原语,原语属于操作系统用于范畴,是由若干条指令组成,用于完成某个功能的一个过程,并且原语的执行必须是连续的,

  • Activiti工作流学习笔记之自动生成28张数据库表的底层原理解析

    网上关于工作流引擎Activiti生成表的机制大多仅限于四种策略模式,但其底层是如何实现的,相关文章还是比较少,因此,觉得撸一撸其生成表机制的底层原理. 我接触工作流引擎Activiti已有两年之久,但一直都只限于熟悉其各类API的使用,对底层的实现,则存在较大的盲区. Activiti这个开源框架在设计上,其实存在不少值得学习和思考的地方,例如,框架用到以命令模式.责任链模式.模板模式等优秀的设计模式来进行框架的设计. 故而,是值得好好研究下Activiti这个框架的底层实现. 我在工作当中现

随机推荐