正文

话说今天在玩select的时候发现一个问题，是这样的：

片段1：

func main(){ 	var count int 	for { 		select { 		case <-time.Tick(time.Millisecond * 500): 			fmt.Println("咖啡色的羊驼") 			count++ 			fmt.Println("count--->" , count) 		case <-time.Tick(time.Millisecond * 499) : 			fmt.Println(time.Now().Unix()) 			count++ 			fmt.Println("count--->" , count) 		} 	} }

片段2：

func main(){ 	t1 := time.Tick(time.Second) 	t2 := time.Tick(time.Second) 	var count int 	for { 		select { 		case <-t1: 			fmt.Println("咖啡色的羊驼") 			count++ 			fmt.Println("count--->" , count) 		case <-t2 : 			fmt.Println(time.Now().Unix()) 			count++ 			fmt.Println("count--->" , count) 		} 	} }

两个问题：1.以上片段的输出结果是？2.如何解释？

1535673600 count---> 1 1535673600 count---> 2 1535673601 count---> 3

片段2：

咖啡色的羊驼 count---> 1 1535673600 count---> 2 咖啡色的羊驼 count---> 3 1535673601 count---> 4

第二个好理解，因为select监听了两个time的通道，所以交替出现。那么第一个为何只有出现1个？为了这个问题不得不把select的实现机制走一波，所以有了此文。

select机制简述

2.select底下有多个可执行的case，则随机执行一个。

3.select常配合for循环来监听channel有没有故事发生。需要注意的是在这个场景下，break只是退出当前select而不会退出for，需要用break TIP / goto的方式。

4.无缓冲的通道，则传值后立马close，则会在close之前阻塞，有缓冲的通道则即使close了也会继续让接收后面的值

5.同个通道多个goroutine进行关闭，可用recover panic的方式来判断通道关闭问题

看完以上知识点其实还是没法解释本文的核心疑惑，继续往下！

select机制详解

select的机制可以查看/src/runtime/select.go来了解。

源码片段解读：

func selectgo(sel *hselect) int { 	// ...  	// case洗牌 	pollslice := slice{unsafe.Pointer(sel.pollorder), int(sel.ncase), int(sel.ncase)} 	pollorder := *(*[]uint16)(unsafe.Pointer(&pollslice)) 	for i := 1; i < int(sel.ncase); i++ { 		//.... 	}  	// 给case排序 	lockslice := slice{unsafe.Pointer(sel.lockorder), int(sel.ncase), int(sel.ncase)} 	lockorder := *(*[]uint16)(unsafe.Pointer(&lockslice)) 	for i := 0; i < int(sel.ncase); i++ { 		// ... 	} 	for i := int(sel.ncase) - 1; i >= 0; i-- { 		// ... 	}  	// 加锁该select中所有的channel 	sellock(scases, lockorder)  	// 进入loop loop: 	// ...  	// pass 1 - look for something already waiting 	// 按顺序遍历case来寻找可执行的case 	for i := 0; i < int(sel.ncase); i++ { 		//... 		switch cas.kind { 		case caseNil: 			continue 		case caseRecv: 			// ... goto xxx 		case caseSend: 			// ... goto xxx 		case caseDefault: 			dfli = casi 			dfl = cas 		} 	}  	// 没有找到可以执行的case，但有default条件，这个if里就会直接退出了。 	if dfl != nil { 		// ... 	} 	// ...  	// pass 2 - enqueue on all chans 	// chan入等待队列 	for _, casei := range lockorder { 		// ... 		switch cas.kind { 		case caseRecv: 			c.recvq.enqueue(sg)  		case caseSend: 			c.sendq.enqueue(sg) 		} 	}  	// wait for someone to wake us up 	// 等待被唤起,同时解锁channel(selparkcommit这里实现的) 	gp.param = nil 	gopark(selparkcommit, nil, "select", traceEvGoBlockSelect, 1) 	 	// 突然有故事发生，被唤醒，再次该select下全部channel加锁 	sellock(scases, lockorder)  	// pass 3 - dequeue from unsuccessful chans 	// 本轮最后一次循环操作，获取可执行case，其余全部出队列丢弃 	casi = -1 	cas = nil 	sglist = gp.waiting 	// Clear all elem before unlinking from gp.waiting. 	for sg1 := gp.waiting; sg1 != nil; sg1 = sg1.waitlink { 		sg1.isSelect = false 		sg1.elem = nil 		sg1.c = nil 	} 	gp.waiting = nil  	for _, casei := range lockorder { 		// ... 		if sg == sglist { 			// sg has already been dequeued by the G that woke us up. 			casi = int(casei) 			cas = k 		} else { 			c = k.c 			if k.kind == caseSend { 				c.sendq.dequeueSudoG(sglist) 			} else { 				c.recvq.dequeueSudoG(sglist) 			} 		} 		// ... 	}  	// 没有的话，再走一次loop 	if cas == nil { 		goto loop 	} 	// ... bufrecv: 	// can receive from buffer bufsend: 	// ... recv: 	// ... rclose: 	// ... send: 	// ... retc: 	// ... sclose: 	// send on closed channel }

为了方便展示，专门搞了一张很丑的图，来说明流程：

大概就是说呢，select是分四步进行的。

本文的疑惑关键点就在于那个loop的时候，当接收到发现一个可执行的时候，本次select不会执行的那些case对应的channel给出队当前goroutine，就不管他们了，就丢了，由于time.Tick是现场在case里头创建的，而不是像片段二是处于全局栈中，所以当每次任何一个执行的时候，另一个就被抛弃了，再次selelct的时候有需要重新获取，又是新的需要重头再来。

本人暂时的理解是这样，如果你有更好的理解，请给我留言，谢谢。

以上就是Golang中select的实现机制的详细内容，更多内容请关注技术你好其它相关文章！