文章目录
0.一个场景题
要求实现一个map:
(1).面向高并发
(2).只存在插入和查询(O(1))
(3).查询时,若key存在,直接返回val,不存在就阻塞到kv对被放入,获取v返回,或返回超时错误
1.前言
channel是Golang在语言层面提供的goroutine间的通信方式,比Unix管道更易用也更轻便。channel主要用于进程内各goroutine间通信,如果需要跨进程通信,建议使用分布式系统的方法来解决。
2.chan数据结构
一个channel同时仅允许被一个goroutine读写,src/runtime/chan.go:hchan定义了channel的数据结构:
type hchan struct {
qcount uint // total data in the queue
dataqsiz uint // size of the circular queue
buf unsafe.Pointer // points to an array of dataqsiz elements
elemsize uint16
closed uint32
elemtype *_type // element type
sendx uint // send index
recvx uint // receive index
recvq waitq // list of recv waiters
sendq waitq // list of send waiters
// 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
}
2.1环形队列
chan内部实现了一个环形队列作为其缓冲区,队列的长度是创建chan时指定的。
- dataqsiz指示了队列长度为6,即可缓存6个元素;
- buf指向队列的内存,队列中还剩余两个元素;
- qcount表示队列中还有两个元素;
- sendx指示后续写入的数据存储的位置,取值[0, 6);
- recvx指示从该位置读取数据, 取值[0, 6);
2.2 等待队列
从channel读数据,如果channel缓冲区为空或者没有缓冲区,当goroutine会被阻塞。
向channel写数据,如果channel缓冲区已满或者没有缓冲区,当goroutine会被阻塞。
被阻塞的goroutine将会挂在channel的等待队列中:
因读阻塞的goroutine会被向channel写入数据的goroutine唤醒;
因写阻塞的goroutine会被从channel读数据的goroutine唤醒;
注意,
一般情况下recvq和sendq至少有一个为空。只有一个例外,那就是同一个goroutine使用select语句向channel一边写数据,一边读数据。
2.3 类型信息
一个channel只能传递一种类型的值,类型信息存储在hchan数据结构中。
- elemtype代表类型,用于数据传递过程中的赋值;
- elemsize代表类型大小,用于在buf中定位元素位置。
3.channel读写
3.1 创建channel
创建channel的过程实际上是初始化hchan结构。其中类型信息和缓冲区长度由make语句传入,buf的大小则与元素大小和缓冲区长度共同决定。
func makechan(t *chantype, size int) *hchan {
var c *hchan
c = new(hchan)
c.buf = malloc(元素类型大小*size)
c.elemsize = 元素类型大小
c.elemtype = 元素类型
c.dataqsiz = size
return c
}
3.2 向channel写数据
向一个channel中写数据简单过程如下:
- 如果等待接收队列recvq不为空,说明缓冲区中没有数据或者没有缓冲区,此时直接从recvq取出G,并把数据写入,最后把该G唤醒,结束发送过程;
- 如果缓冲区中有空余位置,将数据写入缓冲区,结束发送过程;
- 如果缓冲区中没有空余位置,将待发送数据写入G,将当前G加入sendq,进入睡眠,等待被读goroutine唤
醒
3.3 从channel读数据
从一个channel读数据简单过程如下:
- 如果等待发送队列sendq不为空,且没有缓冲区,直接从sendq中取出G,把G中数据读出,最后把G唤醒,结束读取过程;
- 如果等待发送队列sendq不为空,此时说明缓冲区已满,从缓冲区中首部读出数据,把G中数据写入缓冲区尾部,把G唤醒,结束读取过程;
- 如果缓冲区中有数据,则从缓冲区取出数据,结束读取过程;
- 将当前goroutine加入recvq,进入睡眠,等待被写goroutine唤醒;
3.4 关闭channel
关闭channel时会把recvq中的G全部唤醒,本该写入G的数据位置为nil。把sendq中的G全部唤醒,但这些G会panic。
除此之外,panic出现的常见场景还有:
- 关闭值为nil的channel
- 关闭已经被关闭的channel
- 向已经关闭的channel写数据
4.select
事实上select语句的多个case执行顺序是随机的.
select的case语句读channel不会阻塞,尽管channel中没有数据。这是由于case语句编译后调用读channel时会明确传入不阻塞的参数,此时读不到数据时不会将当前goroutine加入到等待队列,而是直接返回
5.range
通过range可以持续从channel中读出数据,好像在遍历一个数组一样,当channel中没有数据时会阻塞当前goroutine,与读channel时阻塞处理机制一样。
注意:如果向此channel写数据的goroutine退出时,系统检测到这种情况后会panic,否则range将会永久阻塞
场景题解决方法:
type MyConcurrentMap struct{
mp map[int]int
mu sync.Mutex
keyToChan map[int]chan struct{}
}
func NewConcurrentMap()*MyConcurrentMap {
return &MyConcurrentMap {mp:make(map[int][int]),keyToChan:make(map[int]chan struct)}
}
//查询
func (m *MyConcurrentMap)Get(k,maxWaiting time.Duration)(int,error){
m.mu.Lock()
val,ok := m.mp[k]
if ok {
m.mu.Unlock()
return val
}
//在第一次等待时需要给chan初始化
if _,ok := m.keytochan[k];!ok{
m.keytochan[k] = make(chan struct{})
}
//阻塞读
m.mu.Unlock()
ctx,cancal := context.WithTimeout(context.Background,maxWaiting)
defer cancel()
select{
case <-ctx:return -1,ctx.Err
case <-ch:
}
//读信号到达
m.mu.Lock()
val,ok := m.mp[k]
m.mu.Unlock()
return val,nil
}
//插入
func (m *MyConcurrentMap)Put(k,v int){
m.Lock()
m.mp[k] = v
//没有人在阻塞等着读
if _,ok := m.keytochan[k];!ok{
m.Unlock()
return
}
//有人在阻塞等着读
//2.chan已经关闭 select{case <- ch:m.mu.Unlock() return drfault:close()}
//3.封装chan + syn.once 保证全局单次关闭
close(m.keytochan[k])
//1.销毁channel的key
delete(m.keytochan[k])
m.mu.Unlock()
return
}