并发性

众所周知并发特性是Go的一个核心特性。

为了实现并发性，Go 有两个重要的组件：¹

channel 的性质

Channel有几种令人感兴趣的性质

那么channel是如何达成这些性质的呢？ 我将在接下来从3个方面来帮助各位理解channel是如何工作的。

分析

构建Channel

在我们进行别的分析之前，我们先来介绍一下如何创建一个Channel以及它的结构。

众所周知，channel有两种不同的类型：有缓存的和无缓存，在这里我们主要把注意力集中在有缓存的channel。

根据前面提到的特性，channel是goroutine安全的，我们很容易想到用一个带锁的队列来实现。现实也确实如此，channel的底层是一个叫做hchan的结构体，从chan.go的源代码中，我们很容易了解到 hcan的结构如下²：

type hchan struct {
    // chan 里元素数量
    qcount   uint
    // chan 底层循环数组的长度
    dataqsiz uint
    // 指向底层循环数组的指针
    // 只针对有缓冲的 channel
    buf      unsafe.Pointer
    // chan 中元素大小
    elemsize uint16
    // chan 是否被关闭的标志
    closed   uint32
    // chan 中元素类型
    elemtype *_type // element type
    // 已发送元素在循环数组中的索引
    sendx    uint   // send index
    // 已接收元素在循环数组中的索引
    recvx    uint   // receive index
    // 等待接收的 goroutine 队列
    recvq    waitq  // list of recv waiters
    // 等待发送的 goroutine 队列
    sendq    waitq  // list of send waiters

    // 保护 hchan 中所有字段
    lock mutex
}

我们先把目光带到buf, buf是一个指向环形队列的指针。 然后sendx与recvx这两个变量则是用于记录已发送的元素在队列中的位置，以及已经接受的元素在队列中的位置。 同时lock 是一个互斥锁，来确保没有竞争。

当我们调用make chan的时候，我们会把创建hchan结构，并分配在堆上，然后返回一个指向该hchan的指针。因为chan本身是一个指向hchan的指针，所以我们才可以在函数间直接的传递他，而不是使用&chan等形式， 因为值传递传递的是地址，都指向同一个内存空间。。

Goroutiine如何使用Channel发送和接收

简单的聊完了chan的创建，那么在这一个部分我们来聊一下，我们如何在不同的goroutine之间，向chan发送，接受数据。

这里我们简单的举几个例子，用G1代表一个发送者，用G2代表一个接受者。

G1

func mai() {
    ...

    for _, task := range tasks {
        taskCh <- task 
    }
    ...
}

G2

func worker() {
    for {
        task := <- taskCh  
        process(task
    }
}

这里的taskCh 是一个长度为3的有缓存的chan。

在这里首先给大家介绍一个简单的说明，我们是如何的发送和接收。

我们可以看到，我们都是通过简单的内存复制来完成数据的传输，这养的过程非常的安全。同时，我们通过mutex保证了没有数据被共享。在上述的步骤中，我们唯一共享的内存就是hchan, 这符合我们的原则, "Do not communication by sharing memory; instead, share memory by communciation"。

阻塞与恢复

现在，我们考虑一个新的情况，G2在调用process()函数的时候需要长时间的处理，但在此期间，我们的G1还是在不断的像channel发送任务：

当我们有三个任务的时候，我们的大小为三的带缓存的channel就已经满了。这时候，G1 又发送了第四个任务：

ch <- task4

由于ch的缓存已满，G1就会被阻塞，直到有人从ch中取走一个任务，G1才能重新的恢复过来。那么这些操作是如何做到的呢？

在这里我们要引入Go的调度器。Go的调度器是一个M：N的调度模型，换句话说就是有N个goroutine 运行在 M个系统线程上，两者不是一一对应的关系。 Go的调度器是一个非常复杂的组件，也是我们随意使用goroutine的保证，因为这篇是讲channel，关于调度器这里我就不过多赘述。

当ch <- task 4 执行的时候，由于channel已经满员，我们需要阻塞G1。 这时，

我们可以看到在这个过程中，G1虽然被阻塞了，但我们的系统线程并没有。

既然我们停止了G1的运行， 那么我们如何将它恢复呢？

我们把目光重新转到hchan这个在channel底层的结构，我们知道他有两个队列：sendq和recvq，而这两个变量就时让goroutine恢复的功臣。

type hchan struct {
    ...
    // 等待接收的 goroutine 队列
    recvq    waitq  // list of recv waiters
    // 等待发送的 goroutine 队列
    sendq    waitq  // list of send waiters
    ...
}

waitq是一个双向链表，其底层结构是sudog。sudog可以大致看成对goroutine的封装，其结构如下：

type sudog struct {
g *g // 指向groutine的指针 
    ..，
    elem unsafe.Pointer //指向元素的指针(可能指向栈空间内)
    ...
}

在之前阻塞的时候，

我们上面提到的这些过程都在调用调度器之前。

那么，我们究竟是如何恢复的？

当G2调用t := <-ch 的时候，执行了一下的操作

上面我们讲的阻塞与恢复是发送者先向channel发送信息，那么当接受者先到达呢？

大致的过程与前面相似：

但在这之后G1开始发送数据流程，与之前部分不同。

G1在开始运行的时候，会直接把数据通过内存复制，复制给G2对应的sudog的t。大家可能会很奇怪，这样goroutine不是互相访问内存了嘛？说好的不访问别人的栈内数据呢？但其实你考虑一下，当G2 停止运行的时候，这个操作肯定是安全的。且当我们这么操作之后，当G2恢复的时候，它不需要再去获取锁，访问buf队列。从而，我们能够节省出内存复制和锁操作的开销。

非阻塞模式的channel的读写 （使用select）

这个部分是talk讲述不多的一个部分，我在这里做一些简单的补充。

slect操作³：

对于非阻塞模式下（select）下的channel， 我们其实是和会阻塞的不同的。对于会阻塞的channel来说，当读取不到数据时候，我们只需调用gopark来让线程阻塞，但非阻塞这样是不可以的。有下面几点不同⁴：

关闭channel