Go源码解析——Channel篇

已于 2022-07-14 10:11:28 修改
阅读量399 收藏 2
点赞数 1
CC 4.0 BY-SA版权
分类专栏： golang源码解析 文章标签： golang
于 2022-07-13 17:57:48 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/ZXISABOY/article/details/125763224
本文深入剖析了Go语言中的核心三剑客——Channel、Map和Slice的源码实现。重点讲解了Channel的创建、发送、接收和关闭的详细过程，包括合法性验证、内存分配、阻塞逻辑以及并发安全。同时，概述了Map的内部结构和Slice的扩展策略。通过对这些关键数据结构的理解，有助于更好地利用Go语言的并发特性。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

channel、map、slice作为golang的核心三剑客，对于使用golang作为主语言完成开发工作的程序猿来说是非常重要的。了解其设计和源码是使用的基础，因此笔者本专题会对这三种数据结构的源码进行详细的介绍和解析…（算是集大家所长，加上自己的一点见解），若有帮助，求点赞关注。

Go源码分析专栏

Go源码解析——Channel篇

Go源码分析——Map篇

Go源码分析——Slice篇

文章目录

1.hchan

  • channel的底层数据结构是hchan struct
  • recvq 是读操作阻塞在 channel 的 goroutine 列表，sendq 是写操作阻塞在 channel 的 goroutine 列表（双向链表 ，FIFO ，使用双端队列是为了FIFO时入队出队方便）
  • buf使用ring buffer（环形缓存区）优点包括
  • 适合FIFO式的固定长度队列
  • 可以预先分配固定大小的数组
  • 允许高效的内存访问模式
  • 所有的缓存区操作都是O(1)，包括消耗一个元素，因为不需要移动元素
  • 本质上就是一个带有头尾指针的固定长度数组，实现参考Go的数据结构与实现【Ring Buffer】 - 掘金
  • sudog 是等待goroutine以及数据的封装，是核心数据结构

hchan部分源码如下：

type hchan struct {
    qcount   uint           // 队列中数据个数
    dataqsiz uint           // buf 大小
    buf      unsafe.Pointer // 存放数据的环形数组
    elemsize uint16         // channel 中数据类型的大小
    closed   uint32         // 表示 channel 是否关闭
    elemtype *_type // 元素数据类型
    sendx    uint   // send 的数组索引
    recvx    uint   // recv 的数组索引
    recvq    waitq  // 由 recv 行为（也就是 <-ch）阻塞在 channel 上的 goroutine 队列
    sendq    waitq  // 由 send 行为 (也就是 ch<-) 阻塞在 channel 上的 goroutine 队列

    // lock protects all fields in hchan, as well as several
    // fields in sudogs blocked on this channel.
    //
    // Do not change another G's status while holding this lock
    // (in particular, do not ready a G), as this can deadlock
    // with stack shrinking.
    lock mutex
}
type waitq struct {
    first *sudog
    last  *sudog
}
type sudog struct {
    // The following fields are protected by the hchan.lock of the
    // channel this sudog is blocking on. shrinkstack depends on
    // this for sudogs involved in channel ops.

    g          *g
    selectdone *uint32 // CAS to 1 to win select race (may point to stack)
    next       *sudog
    prev       *sudog
    elem       unsafe.Pointer // data element (may point to stack)

    // The following fields are never accessed concurrently.
    // For channels, waitlink is only accessed by g.
    // For semaphores, all fields (including the ones above)
    // are only accessed when holding a semaRoot lock.

    acquiretime int64
    releasetime int64
    ticket      uint32
    parent      *sudog // semaRoot binary tree
    waitlink    *sudog // g.waiting list or semaRoot
    waittail    *sudog // semaRoot
    c           *hchan // channel
}

2.make

Go 语言中所有 Channel 的创建都会使用 make 关键字。编译器会将 make(chan int, 10) 表达式转换成 OMAKE 类型的节点，并在类型检查阶段将 OMAKE 类型的节点转换成 OMAKECHAN 类型：

func typecheck1(n *Node, top int) (res *Node) {
        switch n.Op {
        case OMAKE:
                ...
                switch t.Etype {
                case TCHAN:
                        l = nil
                        if i < len(args) { // 带缓冲区的异步 Channel
                                ...
                                n.Left = l
                        } else { // 不带缓冲区的同步 Channel
                                n.Left = nodintconst(0)
                        }
                        n.Op = OMAKECHAN
                }
        }
}

这一阶段会对传入 make 关键字的缓冲区大小进行检查，如果我们不向 make 传递表示缓冲区大小的参数，那么就会设置一个默认值 0，也就是当前的 Channel 不存在缓冲区。
OMAKECHAN 类型的节点最终都会在 SSA 中间代码生成阶段之前被转换成调用 runtime.makechan 或者 runtime.makechan64 的函数：

func walkexpr(n *Node, init *Nodes) *Node {
        switch n.Op {
        case OMAKECHAN:
                size := n.Left
                fnname := "makechan64"
                argtype := types.Types[TINT64]

                if size.Type.IsKind(TIDEAL) || maxintval[size.Type.Etype].Cmp(maxintval[TUINT]) <= 0 {
                        fnname = "makechan"
                        argtype = types.Types[TINT]
                }
                n = mkcall1(chanfn(fnname, 1, n.Type), n.Type, init, typename(n.Type), conv(size, argtype))
        }
}

runtime.makechan 和 runtime.makechan64 会根据传入的参数类型和缓冲区大小创建一个新的 Channel 结构，其中后者用于处理缓冲区大小大于 2 的 32 次方的情况，因为这在 Channel 中并不常见，所以我们重点关注 runtime.makechan：

func makechan(t *chantype, size int) *hchan {
   elem := t.elem

   // compiler checks this but be safe.
   if elem.size >= 1<<16 {
      throw("makechan: invalid channel element type")
   }
   if hchanSize%maxAlign != 0 || elem.align > maxAlign {
      throw("makechan: bad alignment")
   }

   mem, overflow := math.MulUintptr(elem.size, uintptr(size))
   if overflow || mem > maxAlloc-hchanSize || size < 0 {
      panic(plainError("makechan: size out of range"))
   }

   // Hchan does not contain pointers interesting for GC when elements stored in buf do not contain pointers.
   // buf points into the same allocation, elemtype is persistent.
   // SudoG's are referenced from their owning thread so they can't be collected.
   // TODO(dvyukov,rlh): Rethink when collector can move allocated objects.
   var c *hchan
   switch {
   case mem == 0:
      // Queue or element size is zero.
      c = (*hchan)(mallocgc(hchanSize, nil, true))
      // Race detector uses this location for synchronization.
      c.buf = c.raceaddr()
   case elem.ptrdata == 0:
      // Elements do not contain pointers.
      // Allocate hchan and buf in one call.
      c = (*hchan)(mallocgc(hchanSize+mem, nil, true))
      c.buf = add(unsafe.Pointer(c), hchanSize)
   default:
      // Elements contain pointers.
      c = new(hchan)
      c.buf = mallocgc(mem, elem, true)
   }

   c.elemsize = uint16(elem.size)
   c.elemtype = elem
   c.dataqsiz = uint(size)
   lockInit(&c.lock, lockRankHchan)

   if debugChan {
      print("makechan: chan=", c, "; elemsize=", elem.size, "; dataqsiz=", size, "\n")
   }
   return c
}

runtime.makechan主要分为两个部分：合法性验证 和分配地址空间

2.1 合法性验证

  • 数据类型大小，大于1<<16时异常​
  • 内存对齐（降低寻址次数），大于最大的内存8字节数时异常​
  • 传入的size大小，大于堆可分配的最大内存时异常
if elem.size >= 1<<16 {​
      throw("makechan: invalid channel element type")​
}​

if hchanSize%maxAlign != 0 || elem.align > maxAlign {​
      throw("makechan: bad alignment")​
}​
​
mem, overflow := math.MulUintptr(elem.size, uintptr(size))​
if overflow || mem > maxAlloc-hchanSize || size < 0 {​
      panic(plainError("makechan: size out of range"))​
}

2.2 分配地址空间

根据 channel 中收发元素的类型和缓冲区的大小初始化 runtime.hchan 和缓冲区

  • 如果 channel 不存在缓冲区，分配 hchan 结构体空间，即无缓存 channel
  • 如果 channel 存储的类型不是指针类型，分配连续地址空间，包括 hchan 结构体 + 数据
  • 默认情况包括指针，为 hchan 和 buf 单独分配数据地址空间
var c *hchan
switch {
case mem == 0:
   // Queue or element size is zero.
   c = (*hchan)(mallocgc(hchanSize, nil, true))
   // Race detector uses this location for synchronization.
   c.buf = c.raceaddr()
case elem.ptrdata == 0:
   // Elements do not contain pointers.
   // Allocate hchan and buf in one call.
   c = (*hchan)(mallocgc(hchanSize+mem, nil, true))
   c.buf = add(unsafe.Pointer(c), hchanSize)
default:
   // Elements contain pointers.
   c = new(hchan)
   c.buf = mallocgc(mem, elem, true)
}

更新 hchan 结构体的数据，包括 elemsize elemtype 和 dataqsiz

c.elemsize = uint16(elem.size)
c.elemtype = elem
c.dataqsiz = uint(size)
lockInit(&c.lock, lockRankHchan)

3.send

当我们想要向 Channel 发送数据时，就需要使用 ch <- i 语句，编译器会将它解析成 OSEND 节点并在 cmd/compile/internal/gc.walkexpr 中转换成 runtime.chansend1：

case OSEND:
   n1 := n.Right
   n1 = assignconv(n1, n.Left.Type.Elem(), "chan send")
   n1 = walkexpr(n1, init)
   n1 = nod(OADDR, n1, nil)
   n = mkcall1(chanfn("chansend1", 2, n.Left.Type), nil, init, n.Left, n1)

runtime.chansend1 只是调用了 runtime.chansend 并传入 Channel 和需要发送的数据runtime.chansend 是向 Channel 中发送数据时一定会调用的函数，该函数包含了发送数据的全部逻辑，如果我们在调用时将 block 参数设置成 true，那么表示当前发送操作是阻塞的：

func chansend1(c *hchan, elem unsafe.Pointer) {
   chansend(c, elem, true, getcallerpc())//阻塞发送
}
  • ch <- x时阻塞发送
  • x := <- ch时阻塞接收

3.1 chansend函数

func chansend(c *hchan, ep unsafe.Pointer, block bool, callerpc uintptr) bool {
   if c == nil {//向nil chan发送数据会发生阻塞
      if !block {
         return false
      }
      gopark(nil, nil, waitReasonChanSendNilChan, traceEvGoStop, 2)//休眠
      throw("unreachable")
   }

   if debugChan {
      print("chansend: chan=", c, "\n")
   }

   if raceenabled {
      racereadpc(c.raceaddr(), callerpc, funcPC(chansend))
   }

   // Fast path: check for failed non-blocking operation without acquiring the lock.
   //
   // After observing that the channel is not closed, we observe that the channel is
   // not ready for sending. Each of these observations is a single word-sized read
   // (first c.closed and second full()).
   // Because a closed channel cannot transition from 'ready for sending' to
   // 'not ready for sending', even if the channel is closed between the two observations,
   // they imply a moment between the two when the channel was both not yet closed
   // and not ready for sending. We behave as if we observed the channel at that moment,
   // and report that the send cannot proceed.
   //
   // It is okay if the reads are reordered here: if we observe that the channel is not
   // ready for sending and then observe that it is not closed, that implies that the
   // channel wasn't closed during the first observation. However, nothing here
   // guarantees forward progress. We rely on the side effects of lock release in
   // chanrecv() and closechan() to update this thread's view of c.closed and full().
   if !block && c.closed == 0 && full(c) {//full为ture的两种情况1）无缓存通道，recvq为空2）缓存通道，但是buffer已满
      return false
   }

   var t0 int64
   if blockprofilerate > 0 {
      t0 = cputicks()
   }

   lock(&c.lock)

   if c.closed != 0 {//再次检查channel是否关闭，向已关闭的chan发送元素会引起panic
      unlock(&c.lock)
      panic(plainError("send on closed channel"))
   }

   if sg := c.recvq.dequeue(); sg != nil {//取出第一个非空并且未被选择过的的sudog
      // Found a waiting receiver. We pass the value we want to send
      // directly to the receiver, bypassing the channel buffer (if any).
      send(c, sg, ep, func() { unlock(&c.lock) }, 3)
      return true
   }

   if c.qcount < c.dataqsiz {
      // Space is available in the channel buffer. Enqueue the element to send.
      qp := chanbuf(c, c.sendx)
      if raceenabled {
         racenotify(c, c.sendx, nil)
      }
      typedmemmove(c.elemtype, qp, ep)
      c.sendx++
      if c.sendx == c.dataqsiz {
         c.sendx = 0
      }
      c.qcount++
      unlock(&c.lock)
      return true
   }

   if !block {
      unlock(&c.lock)
      return false
   }

   // Block on the channel. Some receiver will complete our operation for us.
   gp := getg()
   mysg := acquireSudog()
   mysg.releasetime = 0
   if t0 != 0 {
      mysg.releasetime = -1
   }
   // No stack splits between assigning elem and enqueuing mysg
   // on gp.waiting where copystack can find it.
   mysg.elem = ep
   mysg.waitlink = nil
   mysg.g = gp
   mysg.isSelect = false
   mysg.c = c
   gp.waiting = mysg
   gp.param = nil
   c.sendq.enqueue(mysg)
   // Signal to anyone trying to shrink our stack that we're about
   // to park on a channel. The window between when this G's status
   // changes and when we set gp.activeStackChans is not safe for
   // stack shrinking.
   atomic.Store8(&gp.parkingOnChan, 1)
   gopark(chanparkcommit, unsafe.Pointer(&c.lock), waitReasonChanSend, traceEvGoBlockSend, 2)
   // Ensure the value being sent is kept alive until the
   // receiver copies it out. The sudog has a pointer to the
   // stack object, but sudogs aren't considered as roots of the
   // stack tracer.
   KeepAlive(ep)

   // someone woke us up.
   if mysg != gp.waiting {
      throw("G waiting list is corrupted")
   }
   gp.waiting = nil
   gp.activeStackChans = false
   closed := !mysg.success
   gp.param = nil
   if mysg.releasetime > 0 {
      blockevent(mysg.releasetime-t0, 2)
   }
   mysg.c = nil
   releaseSudog(mysg)
   if closed {
      if c.closed == 0 {
         throw("chansend: spurious wakeup")
      }
      panic(plainError("send on closed channel"))
   }
   return true
}

chansend函数主要可以归纳为三部分：​

  • 当存在等待的接收者时，也就是在 recvq 可以获得 waitq，通过 send 方法直接将数据发送给等待的接收者​
  • 当缓冲区存在空余空间时，将发送的数据写入 Channel 的缓冲区​
  • 当不存在缓冲区或者缓冲区已满时，阻塞等待其他 Goroutine 从Channel 接收数据，将goroutine和数据打包成sudog存入sendq

未初始化时为nil，向nil channel发送数据会阻塞
从nil channel读取数据同样会阻塞

if c == nil {//向nil chan发送数据会发生阻塞
   if !block {
      return false
   }
   gopark(nil, nil, waitReasonChanSendNilChan, traceEvGoStop, 2)//休眠
   throw("unreachable")
}

向已经关闭的channel发送数据会引起panic

 if c.closed != 0 {//再次检查channel是否关闭，向已关闭的chan发送元素会引起panic
      unlock(&c.lock)
      panic(plainError("send on closed channel"))
   }

如果有等待的接受者，也就是recvq队列中有waitq，通过send方法直接将数据发送给等待的接受者

if sg := c.recvq.dequeue(); sg != nil {//取出第一个非空并且未被选择过的的sudog​
      // Found a waiting receiver. We pass the value we want to send​
      // directly to the receiver, bypassing the channel buffer (if any).​
      send(c, sg, ep, func() { unlock(&c.lock) }, 3)​
      return true​
   }

如果缓存区存在空余空间，写入buffer

if c.qcount < c.dataqsiz {
      // Space is available in the channel buffer. Enqueue the element to send.
      qp := chanbuf(c, c.sendx)//获取缓存区index地址
      if raceenabled {
         racenotify(c, c.sendx, nil)
      }
      typedmemmove(c.elemtype, qp, ep)//数据写入buffer
      c.sendx++
      if c.sendx == c.dataqsiz {
         c.sendx = 0
      }
      c.qcount++
      unlock(&c.lock)
      return true
   }

缓存区已满或无缓存channel，阻塞发送

  • getg 获取发送数据的 Goroutine
  • acquireSudog 获取 sudog 结构
  • 将创建并初始化的 sudog 加入sendq，并设置到当前 Goroutine 的 waiting上，表示 Goroutine 正在等待该 sudog 准备就绪
  • gopark 将当前的 Goroutine 陷入沉睡等待唤醒
  • 被调度器唤醒后会将一些属性置零并且释放 runtime.sudog 结构体
// Block on the channel. Some receiver will complete our operation for us.​
   gp := getg()​
   mysg := acquireSudog()​
   mysg.releasetime = 0​
   if t0 != 0 {​
      mysg.releasetime = -1​
   }​
   // No stack splits between assigning elem and enqueuing mysg​
   // on gp.waiting where copystack can find it.​
   mysg.elem = ep​
   mysg.waitlink = nil​
   mysg.g = gp​
   mysg.isSelect = false​
   mysg.c = c​
   gp.waiting = mysg​
   gp.param = nil​
   c.sendq.enqueue(mysg)​
   // Signal to anyone trying to shrink our stack that we're about​
   // to park on a channel. The window between when this G's status​
   // changes and when we set gp.activeStackChans is not safe for​
   // stack shrinking.​
   
   // 把 goroutine 相关的线索结构入队，等待条件满足的唤醒；
   atomic.Store8(&gp.parkingOnChan, 1)​
   // goroutine 切走，让出 cpu 执行权限；
   gopark(chanparkcommit, unsafe.Pointer(&c.lock), waitReasonChanSend, traceEvGoBlockSend, 2)​
   // Ensure the value being sent is kept alive until the​
   // receiver copies it out. The sudog has a pointer to the​
   // stack object, but sudogs aren't considered as roots of the​
   // stack tracer.​
   KeepAlive(ep)​
​
   // someone woke us up.​
   // 之后就是唤醒之后的逻辑了，只有被唤醒，这个goroutine才会执行到这里
   if mysg != gp.waiting {​
      throw("G waiting list is corrupted")​
   }​
   gp.waiting = nil​
   gp.activeStackChans = false​
   closed := !mysg.success​
   gp.param = nil​
   if mysg.releasetime > 0 {​
      blockevent(mysg.releasetime-t0, 2)​
   }​
   mysg.c = nil​
   releaseSudog(mysg)​
   if closed {​
      if c.closed == 0 {​
         throw("chansend: spurious wakeup")​
      }​
      panic(plainError("send on closed channel"))​
   }​
   return true

3.2 send函数

  • 调用 sendDirect 将发送的数据直接拷贝到接收方 sg 中
  • 调用 goready 将等待接收数据的 Goroutine 标记成可运行状态 Grunnable， 并把该 Goroutine 放到发送方所在的处理器的 runnext 上，该处理器调度时会唤醒接收方。
// send processes a send operation on an empty channel c.
// The value ep sent by the sender is copied to the receiver sg.
// The receiver is then woken up to go on its merry way.
// Channel c must be empty and locked.  send unlocks c with unlockf.
// sg must already be dequeued from c.
// ep must be non-nil and point to the heap or the caller's stack.
func send(c *hchan, sg *sudog, ep unsafe.Pointer, unlockf func(), skip int) {
 
        if sg.elem != nil {
                sendDirect(c.elemtype, sg, ep)
                sg.elem = nil
        }
        gp := sg.g
        unlockf()
        gp.param = unsafe.Pointer(sg)
        sg.success = true
        if sg.releasetime != 0 {
                sg.releasetime = cputicks()
        }
        goready(gp, skip+1)
}

4.recv

Go 语言中可以使用两种不同的方式去接收 Channel 中的数据：

i <- ch
i, ok <- ch

这两种不同的方法经过编译器的处理都会变成 ORECV 类型的节点，后者会在类型检查阶段被转换成 OAS2RECV 类型。数据的接收操作遵循以下的路线图：
在这里插入图片描述
虽然不同的接收方式会被转换成 runtime.chanrecv1 和 runtime.chanrecv2 两种不同函数的调用，但是这两个函数最终还是会调用 runtime.chanrecv。

func chanrecv1(c *hchan, elem unsafe.Pointer) {
   chanrecv(c, elem, true)
}

func chanrecv2(c *hchan, elem unsafe.Pointer) (received bool) {
   _, received = chanrecv(c, elem, true)
   return
}

划重点：

  • 不管是chanrecv1还是chanrecv2，最后都是阻塞的调用chanrev
  • 不管是send还是recv，都是阻塞的调用
  • 只有 select 的时候，block 才会是 false

4.1 chanrecv函数

func chanrecv(c *hchan, ep unsafe.Pointer, block bool) (selected, received bool) {
   // raceenabled: don't need to check ep, as it is always on the stack
   // or is new memory allocated by reflect.

   if debugChan {
      print("chanrecv: chan=", c, "\n")
   }

   if c == nil {
      if !block {
         return
      }
      gopark(nil, nil, waitReasonChanReceiveNilChan, traceEvGoStop, 2)
      throw("unreachable")
   }

   // Fast path: check for failed non-blocking operation without acquiring the lock.
   if !block && empty(c) {
      // After observing that the channel is not ready for receiving, we observe whether the
      // channel is closed.
      //
      // Reordering of these checks could lead to incorrect behavior when racing with a close.
      // For example, if the channel was open and not empty, was closed, and then drained,
      // reordered reads could incorrectly indicate "open and empty". To prevent reordering,
      // we use atomic loads for both checks, and rely on emptying and closing to happen in
      // separate critical sections under the same lock.  This assumption fails when closing
      // an unbuffered channel with a blocked send, but that is an error condition anyway.
      if atomic.Load(&c.closed) == 0 {
         // Because a channel cannot be reopened, the later observation of the channel
         // being not closed implies that it was also not closed at the moment of the
         // first observation. We behave as if we observed the channel at that moment
         // and report that the receive cannot proceed.
         return
      }
      // The channel is irreversibly closed. Re-check whether the channel has any pending data
      // to receive, which could have arrived between the empty and closed checks above.
      // Sequential consistency is also required here, when racing with such a send.
      if empty(c) {
         // The channel is irreversibly closed and empty.
         if raceenabled {
            raceacquire(c.raceaddr())
         }
         if ep != nil {
            typedmemclr(c.elemtype, ep)
         }
         return true, false
      }
   }

   var t0 int64
   if blockprofilerate > 0 {
      t0 = cputicks()
   }

   lock(&c.lock)

   if c.closed != 0 && c.qcount == 0 {
      if raceenabled {
         raceacquire(c.raceaddr())
      }
      unlock(&c.lock)
      if ep != nil {
         typedmemclr(c.elemtype, ep)
      }
      return true, false
   }

   if sg := c.sendq.dequeue(); sg != nil {
      // Found a waiting sender. If buffer is size 0, receive value
      // directly from sender. Otherwise, receive from head of queue
      // and add sender's value to the tail of the queue (both map to
      // the same buffer slot because the queue is full).
      recv(c, sg, ep, func() { unlock(&c.lock) }, 3)
      return true, true
   }

   if c.qcount > 0 {
      // Receive directly from queue
      qp := chanbuf(c, c.recvx)
      if raceenabled {
         racenotify(c, c.recvx, nil)
      }
      if ep != nil {
         typedmemmove(c.elemtype, ep, qp)
      }
      typedmemclr(c.elemtype, qp)
      c.recvx++
      if c.recvx == c.dataqsiz {
         c.recvx = 0
      }
      c.qcount--
      unlock(&c.lock)
      return true, true
   }

   if !block {
      unlock(&c.lock)
      return false, false
   }

   // no sender available: block on this channel.
   gp := getg()
   mysg := acquireSudog()
   mysg.releasetime = 0
   if t0 != 0 {
      mysg.releasetime = -1
   }
   // No stack splits between assigning elem and enqueuing mysg
   // on gp.waiting where copystack can find it.
   mysg.elem = ep
   mysg.waitlink = nil
   gp.waiting = mysg
   mysg.g = gp
   mysg.isSelect = false
   mysg.c = c
   gp.param = nil
   c.recvq.enqueue(mysg)
   // Signal to anyone trying to shrink our stack that we're about
   // to park on a channel. The window between when this G's status
   // changes and when we set gp.activeStackChans is not safe for
   // stack shrinking.
   atomic.Store8(&gp.parkingOnChan, 1)
   gopark(chanparkcommit, unsafe.Pointer(&c.lock), waitReasonChanReceive, traceEvGoBlockRecv, 2)

   // someone woke us up
   if mysg != gp.waiting {
      throw("G waiting list is corrupted")
   }
   gp.waiting = nil
   gp.activeStackChans = false
   if mysg.releasetime > 0 {
      blockevent(mysg.releasetime-t0, 2)
   }
   success := mysg.success
   gp.param = nil
   mysg.c = nil
   releaseSudog(mysg)
   return true, success
}

chanrecv函数同样可以归纳为三部分：

  • 当存在等待的发送者时，也就是在 sendv 可以获得 waitq，通过 recv 方法直接将等待的发送者的数据复制到接收者的地址空间
  • 当缓冲区中存在数据时，将缓存区中的数据写入接收者的地址空间
  • 缓存区无数据或者无缓存channel时，阻塞等待其他goroutine发送数据，将goroutine和数据打包成sudog存入sendq
  • 向nil channel接收数据会引起阻塞
  • runtime.gopark让出处理器的使用权
func chanrecv(c *hchan, ep unsafe.Pointer, block bool) (selected, received bool) {
    if c == nil {
        if !block {
            return
        }
        gopark(nil, nil, "chan receive (nil chan)", traceEvGoStop, 2)
        throw("unreachable")
    }
    ...
}

从 closed channel 接收数据，如果 channel 中还有数据，接着走下面的流程。如果已经没有数据了，则返回默认值。使用 ok-idiom 方式读取的时候，第二个参数返回 false。

lock(&c.lock)

if c.closed != 0 && c.qcount == 0 {
   if raceenabled {
      raceacquire(c.raceaddr())
   }
   unlock(&c.lock)
   if ep != nil {
      typedmemclr(c.elemtype, ep)
   }
   return true, false
}
  • 当前有发送的 goroutine 阻塞在 channel 上，说明buf 已满或无buf channel​
  • 如果是无缓存channel，就直接找到一个在等待的sender，接收它的数据​
  • 如果是有缓存channel，从buf头部拿出值，之后将等待的sender的数据入buf​
  • 也就是说FIFO原则
if sg := c.sendq.dequeue(); sg != nil {
   // Found a waiting sender. If buffer is size 0, receive value
   // directly from sender. Otherwise, receive from head of queue
   // and add sender's value to the tail of the queue (both map to
   // the same buffer slot because the queue is full).
   recv(c, sg, ep, func() { unlock(&c.lock) }, 3)
   return true, true
}
  • 如果没有sender在等待，看buf中是否有数据
  • 如果有数据，直接从buf中接收数据，相应数据从buf中出队
if c.qcount > 0 {
   // Receive directly from queue
   qp := chanbuf(c, c.recvx)
   if raceenabled {
      racenotify(c, c.recvx, nil)
   }
   if ep != nil {
      typedmemmove(c.elemtype, ep, qp)
   }
   typedmemclr(c.elemtype, qp)
   c.recvx++
   if c.recvx == c.dataqsiz {
      c.recvx = 0
   }
   c.qcount--
   unlock(&c.lock)
   return true, true
}
  • 判断是否为阻塞接收
  • 正常的channel发送和接收，都是阻塞的，调用的底层函数为chansend1，chanrecv1，chanrecv2
  • 与select结合使用时，底层调用的函数selectnbsend，selectnbrecv
if !block {
   unlock(&c.lock)
   return false, false
}
  • buf为空时，阻塞等待，将goroutine休眠与数据等封装为sudog入recvq队列
    • getg 获取发送数据的 Goroutine
    • acquireSudog 获取 sudog 结构
    • 将创建并初始化的 sudog 加入recvq，并设置到当前 Goroutine 的 waiting上，表示 Goroutine 正在等待该 sudog 准备就绪
    • gopark 将当前的 Goroutine 陷入沉睡等待唤醒
    • 被调度器唤醒后会将一些属性置零并且释放 runtime.sudog 结构体
// no sender available: block on this channel.
gp := getg()
mysg := acquireSudog()
mysg.releasetime = 0
if t0 != 0 {
    mysg.releasetime = -1
}
// No stack splits between assigning elem and enqueuing mysg
// on gp.waiting where copystack can find it.
mysg.elem = ep
mysg.waitlink = nil
gp.waiting = mysg
mysg.g = gp
mysg.selectdone = nil
mysg.c = c
gp.param = nil
c.recvq.enqueue(mysg)
goparkunlock(&c.lock, "chan receive", traceEvGoBlockRecv, 3)

4.2 recv函数

  • 如果buf大小为0即无buf channel，调用 recvdirect 直接从等待的sender中接收数据​
  • 如果有缓存槽，说明缓存槽满了，并且产生了等待发送的队列​
  • 从缓存槽中获取数据，将等待的发送数据入sendq等待队列​
  • 调用 goready将等待接收数据的 Goroutine 标记成可运行状态 Grunnable， 并把该 Goroutine 放到发送方所在的处理器的
    runnext 上，该处理器调度时会唤醒接收方​
  • 将阻塞的发送goroutine唤醒
func recv(c *hchan, sg *sudog, ep unsafe.Pointer, unlockf func(), skip int) {
       //如果没有缓存槽,那么直接拷贝发送队列的值
       if c.dataqsiz == 0 {
               if ep != nil {
                       // copy data from sender
                       recvDirect(c.elemtype, sg, ep)
               }
       } else {
               //如果有缓冲槽，说明缓存槽满了并且产生了等待发送的队列
               //从缓冲槽中获取数据,并且将发送队列的头节点保存的数据写入缓冲槽中
               qp := chanbuf(c, c.recvx)
               
               //将缓冲槽的数据拷贝到接收者目标地址
               if ep != nil {
                       typedmemmove(c.elemtype, ep, qp)
               }
               //将发送队列的头节点拷贝到当前缓存槽位置
               typedmemmove(c.elemtype, qp, sg.elem)
               c.recvx++ //接收索引增加
               if c.recvx == c.dataqsiz {
                       c.recvx = 0
               }
               //缓冲槽满了的情况是缓冲槽发送索引等于接收的索引值
               c.sendx = c.recvx // c.sendx = (c.sendx+1) % c.dataqsiz
       }
       sg.elem = nil
       gp := sg.g
       unlockf()
       gp.param = unsafe.Pointer(sg)
       if sg.releasetime != 0 {
               sg.releasetime = cputicks()
       }
       //将阻塞的发送方头节点goroutine唤醒
       goready(gp, skip+1)
}

5.close

关闭channel主要涉及到的函数是closechan

5.1 closechan函数

close channel 的工作除了将 c.closed 设置为 1。还需要：

  • 唤醒 recvq 队列里面的阻塞 goroutine
  • 唤醒 sendq 队列里面的阻塞 goroutine
  • 处理方式是分别遍历 recvq 和 sendq 队列，将所有的 goroutine 放到 glist 队列中，最后唤醒 glist 队列中的 goroutine。
  • 关闭一个已经关闭的channel会引起panic
func closechan(c *hchan) {
   if c == nil {
      panic(plainError("close of nil channel"))
   }

   lock(&c.lock)
   if c.closed != 0 {
      unlock(&c.lock)
      panic(plainError("close of closed channel"))
   }

   if raceenabled {
      callerpc := getcallerpc()
      racewritepc(c.raceaddr(), callerpc, funcPC(closechan))
      racerelease(c.raceaddr())
   }

   c.closed = 1

   var glist gList

   // release all readers
   for {
      sg := c.recvq.dequeue()
      if sg == nil {
         break
      }
      if sg.elem != nil {
         typedmemclr(c.elemtype, sg.elem)
         sg.elem = nil
      }
      if sg.releasetime != 0 {
         sg.releasetime = cputicks()
      }
      gp := sg.g
      gp.param = unsafe.Pointer(sg)
      sg.success = false
      if raceenabled {
         raceacquireg(gp, c.raceaddr())
      }
      glist.push(gp)
   }

   // release all writers (they will panic)
   for {
      sg := c.sendq.dequeue()
      if sg == nil {
         break
      }
      sg.elem = nil
      if sg.releasetime != 0 {
         sg.releasetime = cputicks()
      }
      gp := sg.g
      gp.param = unsafe.Pointer(sg)
      sg.success = false
      if raceenabled {
         raceacquireg(gp, c.raceaddr())
      }
      glist.push(gp)
   }
   unlock(&c.lock)

   // Ready all Gs now that we've dropped the channel lock.
   for !glist.empty() {
      gp := glist.pop()
      gp.schedlink = 0
      goready(gp, 3)
   }
}

typedmemclr 的作用是将 ep 指向的类型为 elemtype 的内存块置为 0 值

6.select

golang 中的 select 语句的实现，在 runtime/select.go 文件中，这篇文章并不打算看 select 的实现。我们要看的是 select 和 channel 一起用的时候。

  • channel与select语句结合使用时，底层调用的还是chansend和chanrecv函数
  • 不同的是非阻塞 send和recv，而常规channel的send和recv都是阻塞的

6.1 向channel中发送数据

select {
case c <- x:
    ... foo
default:
    ... bar
}

会被编译为:

if selectnbsend(c, v) {
    ... foo
} else {
    ... bar
}

对应 selectnbsend 函数如下:

func selectnbsend(c *hchan, elem unsafe.Pointer) (selected bool) {
    return chansend(c, elem, false, getcallerpc(unsafe.Pointer(&c)))
}

6.2 从channel中接收数据

select {
case v = <-c
    ... foo
default:
    ... bar
}

会被编译为:

if selectnbrecv(&v, c) {
    ... foo
} else {
    ... bar
}

对应 selectnbrecv 函数如下:

func selectnbrecv(elem unsafe.Pointer, c *hchan) (selected bool) {
    selected, _ = chanrecv(c, elem, false)
    return
}

另一种接收数据的方式：

select {
case v, ok = <-c:
    ... foo
default:
    ... bar
}

会被编译为:

if c != nil && selectnbrecv2(&v, &ok, c) {
    ... foo
} else {
    ... bar
}

对应 selectnbrecv2 函数如下:

func selectnbrecv2(elem unsafe.Pointer, received *bool, c *hchan) (selected bool) {
    // TODO(khr): just return 2 values from this function, now that it is in Go.
    selected, *received = chanrecv(c, elem, false)
    return
}

对应函数以上都已讲解，此处不再赘述。

参考文档

- Golang channel源码深度剖析
- golang channel 最详细的源码剖析
- Go语言并发模型：使用 select
- Golang的select/非缓冲的Channel实例详解
- 图解Golang channel源码
- Go Channel 源码剖析
- golang channel 源码剖析
- 深入 Go 并发原语 — Channel 底层实现
- Go的数据结构与实现【Ring Buffer】 - 掘金
- Go语言设计与实现-Channel

扩展阅读

- Dmitry Vyukov. Oct, 2014.“runtime: lock-free channels”
- Concurrency in Golang
- Communicating sequential processes
- lock-free channel
- 实现无限缓存的channel

Fabric v2.0 源码解析——典型的业务流程
cactusblossom
04-04 2773
根据Fabric中典型的业务流程，简单地分析相关的代码，包括创建通道(channel)、加入通道(channel)、安装智能合约(chaincode)、认可智能合约(chaincode)定义、提交智能合约(chaincode)定义、调用智能合约(chaincode)。
Fabric v2.0 源码解析——排序节点（Orderer）运行机制
cactusblossom
04-05 3983
Orderer在Fabric网络中的作用主要是原子广播（Atomic Broadcast）和全排序（Total Order ）。 - orderer通过`broadcast`接口，接受client发送的交易，然后将这些Tx进行排序；排序的的原则为FIFS（First In First Served），但是区块内交易的顺序不一定与实际顺序一样，而是由到达Orderer的时间来决定的。 - 排序后的交易根据一定的规则打包成区块，通过`deliver`接口将区块发送给Peer或client；保证所有Orderer
Go源码剖析
04-04
雨痕的Go源码剖析，很详细。 深入学习go的底层，gc。 基于go 1.5.
Go编程源码分析channel
apple_56973763的博客
10-01 920
在go中经常谈到的一句话是：不要通过共享内存的方式进行通信，而是应该通过通信的方式共享内存。在Goroutine之间通过channel传递数据，作为Go语言的核心数据结构和Goroutine之间的通信方式，channel是支撑Go语言高性能并发编程模型的重要结构。channel在运行时的内部表示是runtime.hchan，该结构体中包含了用于保护成员变量的互斥锁，从某种程度上说，channel是一个用于同步和通信的有锁队列。
Golang源码分析 - scan.go
最新发布
gopher123的博客
05-06 728
scan.go 是 Go 标准库 text/scanner 包的核心文件，实现了一个高效的文本扫描器，用于将输入文本分解为一系列 token（标记）。这个扫描器被广泛用于 Go 语言工具链中，如 go/parser 等。
golang源码剖析
11-12
golang 的源码剖析pdf高清，雨痕大神的分析笔记！！！
go 源码分析
ailinyingai的博客
11-08 1291
Python等解释性语言采用的是多进程并发模型，进程的上下文是最大的，所以切换耗费巨大，同时由于多进程通信只能用socket通讯，或者专门设置共享内存，给编程带来了极大的困扰与不便； C++等语言通常会采用多线程并发模型，相比进程，线程的上下文要小很多，而且多个线程之间本来就是共享内存的，所以编程相比要轻松很多。但是线程的启动和销毁，切换依然要耗费大量CPU时间；于是出现了线程池技术，将线程先储存...
nsq源码阅读笔记之nsqd（四）——Channel
RayXXZhang的专栏
02-29 8686
Topic/Channel是发布/订阅模型的一种实现。Topic对应于发布，Channel对应于订阅。 消费者通过在Topic下生成不同的Channel来接收来自该Topic的消息。 通过生成相同的Channel来实现消费者负载均衡。 Channel本身在投递消息给消费者时维护两个队列，一个是inFlight队列，该队列存储正在投递，但还没被标记为投递成功的消息。 另一个是deferred队列，用来存储需要被延时投
2019KCTF：《挖宝》解析——栈溢出、Go线程堵塞与编译技巧
这篇资源主要讨论的是一个基于Go语言的CTF（Capture The Flag）挑战赛的问题，题目名为《挖宝》。该题目由小雪出题，战队“pizzatpl”的成员BPG参与了解答。题目设计的目的是测试参赛者的安全分析和破解能力，尤其是...
zinx —— golang —— MMO游戏服务器开发对应客户端
06-01
《Zinx：Golang构建MMO游戏服务器及客户端解析》 在现代网络游戏开发中，后端服务器扮演着至关重要的角色，它们负责处理玩家交互、游戏逻辑、数据存储等一系列任务。Zinx是一个用Golang编写的轻量级网络框架，特别...
golang channel源码解析
leegyoungfree的博客
07-16 657
go channel源码分析 不要通过共享内存来通信，而要通过通信来实现内存共享。 一、通道是什么? 通道是可以让一个goroutine发送特定值到另一个goroutine的通信机制 无缓冲通道： 也称同步通道，无缓冲通道上的发送操作将会阻塞，直到另一个goroutine在对应的通道上执行接收操作，此时传送完成，两个goroutine才能继续执行。反之亦然。 缓冲通道： 缓冲队列有一个缓冲队列，队列的最大长度在创建的时候通过make的容量参数来设置。 缓冲通道上的发送操作在队列的尾部插入一个元
Go源码解析——Map篇
ZXISABOY的博客
07-13 549
channel、map、slice作为golang的核心三剑客，对于使用golang作为主语言完成开发工作的程序猿来说是非常重要的。了解其设计和源码是使用的基础，因此笔者本专题会对这三种数据结构的源码进行详细的介绍和解析…（算是集大家所长，加上自己的一点见解）.........
golang channel 源码分析
wwhhff11
05-27 774
参考链接 Ring Buffer相关理解
深入理解GO语言：GC原理及源码分析
cyq6239075的博客
05-28 4559
Go 中的runtime 类似 Java的虚拟机，它负责管理包括内存分配、垃圾回收、栈处理、goroutine、channel、切片（slice）、map 和反射（reflection）等。Go 的可执行文件都比相对应的源代码文件要大很多，这是因为 Go 的 runtime 嵌入到了每一个可执行文件当中。 常见的几种gc算法： 引用计数：对每个对象维护一个引用计数，当引用该对象的对象被销毁时，引用计数减1，当引用计数器为0是回收该对象。 优点：对象可以很快的被回收，不会出现内存耗尽或达到某个阀值时才回
【基础知识】Go源码文件解析
Mr_SCX的博客
07-16 1307
Go 语言源码的组织方式就是以环境变量 GOPATH、工作区、src 目录和代码包为主线的。环境变量 GOPATH 指向的是一个或多个工作区，每个工作区中都会有以代码包为基本组织形式的源码文件。源码文件又分为三种，即：命令源码文件、库源码文件和测试源码文件，它们都有着不同的用途和编写规则。 命令源码文件 命令源码文件是每个可独立运行的程序的运行入口，属于main包，包含一个无参数声明且无结果声明的main函数，可通过go run命令运行，可接收命令行参数。我们可以通过构建或安装，生成与其对应的可执行文件，这
Golang channel 源码分析
MandyOu
10-23 847
研究 channel 的底层结构，channel 的创建，channel 的发送和接收流程
Go语言 Channel管道的源码分析及图解
qq_24447809的博客
04-05 1781
文章目录Channel概述Channel结构体信息Channel创建chansend发送1. 直接发送流程图2. 写入缓冲区流程图3. 发送阻塞挂起chanrecv接收1. 直接接收流程图（无缓冲区）2. 直接接收流程图（带缓冲区）3. 从缓冲区接收4. 接收阻塞挂起 Channel概述 Channel通过通信的方式在goroutine之间共享内存，是支撑Go语言高性能并发编程模型的重要结构，本文将分析Channel相关的创建、发送、接收、关闭函数的源代码。 ps：源代码只给出了重要逻辑核心部分 Chann
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值