go语言cas go语言cap函数

Go语言——sync.Map详解

sync.Map是1.9才推荐的并发安全的map，除了互斥量以外，还运用了原子操作，所以在这之前，有必要了解下 Go语言——原子操作

成都创新互联公司长期为近千家客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为巩留企业提供专业的网站设计制作、成都网站制作，巩留网站改版等技术服务。拥有10多年丰富建站经验和众多成功案例,为您定制开发。

go1.10\src\sync\map.go

entry分为三种情况：

从read中读取key，如果key存在就tryStore。

注意这里开始需要加锁，因为需要操作dirty。

条目在read中，首先取消标记，然后将条目保存到dirty里。（因为标记的数据不在dirty里）

最后原子保存value到条目里面，这里注意read和dirty都有条目。

总结一下Store：

这里可以看到dirty保存了数据的修改，除非可以直接原子更新read，继续保持read clean。

有了之前的经验，可以猜测下load流程：

与猜测的 区别 ：

由于数据保存两份，所以删除考虑：

先看第二种情况。加锁直接删除dirty数据。思考下貌似没什么问题，本身就是脏数据。

第一种和第三种情况唯一的区别就是条目是否被标记。标记代表删除，所以直接返回。否则CAS操作置为nil。这里总感觉少点什么，因为条目其实还是存在的，虽然指针nil。

看了一圈貌似没找到标记的逻辑，因为删除只是将他变成nil。

之前以为这个逻辑就是简单的将为标记的条目拷贝给dirty，现在看来大有文章。

p == nil，说明条目已经被delete了，CAS将他置为标记删除。然后这个条目就不会保存在dirty里面。

这里其实就跟miss逻辑串起来了，因为miss达到阈值之后，dirty会全量变成read，也就是说标记删除在这一步最终删除。这个还是很巧妙的。

真正的删除逻辑：

很绕。。。。

Go并发编程之美-CAS操作

摘要： 一、前言 go语言类似Java JUC包也提供了一些列用于多线程之间进行同步的措施，比如低级的同步措施有 锁、CAS、原子变量操作类。相比Java来说go提供了独特的基于通道的同步措施。本节我们先来看看go中CAS操作 二、CAS操作 go中的Cas操作与java中类似，都是借用了CPU提供的原子性指令来实现。

go语言类似Java JUC包也提供了一些列用于多线程之间进行同步的措施，比如低级的同步措施有 锁、CAS、原子变量操作类。相比Java来说go提供了独特的基于通道的同步措施。本节我们先来看看go中CAS操作

go中的Cas操作与java中类似，都是借用了CPU提供的原子性指令来实现。CAS操作修改共享变量时候不需要对共享变量加锁，而是通过类似乐观锁的方式进行检查，本质还是不断的占用CPU 资源换取加锁带来的开销（比如上下文切换开销）。下面一个例子使用CAS来实现计数器

go中CAS操作具有原子性，在解决多线程操作共享变量安全上可以有效的减少使用锁所带来的开销，但是这是使用cpu资源做交换的。

我简单列举了并发编程的大纲，需要详细的私信“555”~~

有没有实现过cas的golang客户端

首先理解是错的，不管用户态的API(syscall)是否是同步还是异步，在kernel层面都是异步的。其实实现原理很简单，就是利用C(嵌入汇编)语言可以直接修改寄存器(setcontext/setjmp/longjmp均是类似原理，修改程序指针eip实现跳转，栈指针实现上线文切换)来实现从func_a调进去，从func_b返回出来这种行为。对于golang来说，func_a/func_b属于不同的goroutine，从而就实现了goroutine的调度切换。另外对于所有可能阻塞的syscall，golang对其进行了封装，底层实际是epoll方式做的，注册回调后切换到另一个runnable的goroutine。

图解Go中select语句的底层原理

Go 的select语句是一种仅能用于channl发送和接收消息的专用语句，此语句运行期间是阻塞的；当select中没有case语句的时候，会阻塞当前的groutine。所以，有人也会说select是用来阻塞监听goroutine的。

还有人说：select是Golang在语言层面提供的I/O多路复用的机制，其专门用来检测多个channel是否准备完毕：可读或可写。

以上说法都正确。

我们来回顾一下是什么是 I/O多路复用 。

每来一个进程，都会建立连接，然后阻塞，直到接收到数据返回响应。

普通这种方式的缺点其实很明显：系统需要创建和维护额外的线程或进程。因为大多数时候，大部分阻塞的线程或进程是处于等待状态，只有少部分会接收并处理响应，而其余的都在等待。系统为此还需要多做很多额外的线程或者进程的管理工作。

为了解决图中这些多余的线程或者进程，于是有了"I/O多路复用"

每个线程或者进程都先到图中”装置“中注册，然后阻塞，然后只有一个线程在”运输“，当注册的线程或者进程准备好数据后，”装置“会根据注册的信息得到相应的数据。从始至终kernel只会使用图中这个黄黄的线程，无需再对额外的线程或者进程进行管理，提升了效率。

select的实现经历了多个版本的修改，当前版本为：1.11

select这个语句底层实现实际上主要由两部分组成： case语句 和 执行函数 。

源码地址为：/go/src/runtime/select.go

每个case语句，单独抽象出以下结构体：

结构体可以用下图表示：

然后执行select语句实际上就是调用 func selectgo(cas0 *scase, order0 *uint16, ncases int) (int, bool) 函数。

func selectgo(cas0 *scase, order0 *uint16, ncases int) (int, bool) 函数参数：

selectgo 返回所选scase的索引(该索引与其各自的select {recv，send，default}调用的序号位置相匹配)。此外，如果选择的scase是接收操作(recv)，则返回是否接收到值。

谁负责调用 func selectgo(cas0 *scase, order0 *uint16, ncases int) (int, bool) 函数呢？

在 /reflect/value.go 中有个 func rselect([]runtimeSelect) (chosen int, recvOK bool) 函数，此函数的实现在 /runtime/select.go 文件中的 func reflect_rselect(cases []runtimeSelect) (int, bool) 函数中:

那谁调用的 func rselect([]runtimeSelect) (chosen int, recvOK bool) 呢？

在 /refect/value.go 中，有一个 func Select(cases []SelectCase) (chosen int, recv Value, recvOK bool) 的函数，其调用了 rselect 函数，并将最终Go中select语句的返回值的返回。

以上这三个函数的调用栈按顺序如下：

这仨函数中无论是返回值还是参数都大同小异，可以简单粗暴的认为：函数参数传入的是case语句，返回值返回被选中的case语句。

那谁调用了 func Select(cases []SelectCase) (chosen int, recv Value, recvOK bool) 呢？

可以简单的认为是系统了。

来个简单的图：

前两个函数 Select 和 rselect 都是做了简单的初始化参数，调用下一个函数的操作。select真正的核心功能，是在最后一个函数 func selectgo(cas0 *scase, order0 *uint16, ncases int) (int, bool) 中实现的。

打乱传入的case结构体顺序

锁住其中的所有的channel

遍历所有的channel，查看其是否可读或者可写

如果其中的channel可读或者可写，则解锁所有channel，并返回对应的channel数据

假如没有channel可读或者可写，但是有default语句，则同上:返回default语句对应的scase并解锁所有的channel。

假如既没有channel可读或者可写，也没有default语句，则将当前运行的groutine阻塞，并加入到当前所有channel的等待队列中去。

然后解锁所有channel，等待被唤醒。

此时如果有个channel可读或者可写ready了，则唤醒，并再次加锁所有channel，

遍历所有channel找到那个对应的channel和G，唤醒G，并将没有成功的G从所有channel的等待队列中移除。

如果对应的scase值不为空，则返回需要的值，并解锁所有channel

如果对应的scase为空，则循环此过程。

在想想select和channel做了什么事儿，我觉得和多路复用是一回事儿