1.go channel close后读的问题
答 ：golang channel关闭后，其中剩余的数据，是可以继续读取的，channel关闭之后，仍然可以从channel中读取剩余的数据，直到数据全部读取完成。
- 对于一个关闭的channel，如果继续向channel发送数据，会引起panic，如果继续读数据，得到的是零值(对于int，就是0)。
判断一个channel的方式有两种:
value, ok := <- ch
//ok是false，就表示已经关闭。
for value := range ch {
}
package main
import "fmt"
func main() {
ch := make(chan int, 3)
ch <- 1
ch <- 2
ch <- 3
close(ch)
value, ok := <-ch // 1 value 2 value 3 第一种方式
if ok {
fmt.Println(value)
}
for v := range ch { //第二种方式
fmt.Println("value", v)
}
// ch <- 4 panic
}
go slice 和 array 区别
- 相同
属于集合类的类型，值都可以用来存储某一种类型的值(或者说元素)
- 区别（最大的不同）
数组的长度固定，数组是值类型（值类型有基本数据类型，结构体类型），
不需要使用额外的内存并且比使用数组更有效率。如果传递的是引用类型，那么就是“传引用”，如果传递的是值类型，那么就是“传值”(会把以前的数据复制一遍)
数组长度在声明的时候就必须给定，并且之后不会再改变。
slice类型的字面量中只有元素类型，没有长度。切片长度可以自动随着元素数量的增长而增长，但不会随着元素数量的减少而减少。数组的容量=长度，不可改变
[...]T{1, 2, 3} 和 [3]T{1, 2, 3} 在运行时是完全等价的，
[...]T 这种初始化方式也只是 Go 语言为我们提供的一种语法糖，当我们不想计算数组中的元素个数时可以通过这种方法减少一些工作量。
Go 语言运行时在发现数组、切片和字符串的越界操作会由运行时的 runtime.panicIndex 和 runtime.goPanicIndex 触发程序的运行时错误并导致崩溃退出：
slice组成
type SliceHeader struct {
Data uintptr 指向数组的指针;
Len int 前切片的长度；
Cap int 当前切片的容量，即 Data 数组的大小：
}
Dataarr[0:3] or slice[0:3] \\通过下标的方式获得数组或者切片的一部分；
slice := []int{1, 2, 3} \\使用字面量初始化新的切片；
slice := make([]int, 10) \\使用关键字 make 创建切片：
内存空间=切片中元素大小×切片容量
相比于依次拷贝元素，runtime.memmove 能够提供更好的性能。需要注意的是，整块拷贝内存仍然会占用非常多的资源，在大切片上执行拷贝操作时一定要注意对性能的影响
Slice 扩容
使用append向Slice追加元素时，如果Slice空间不足，将会触发Slice扩容，扩容实际上重新一配一块更大的内存，将原Slice数据拷贝进新Slice，然后返回新Slice，扩容后再将数据追加进去。
例如，当向一个capacity为5，且length也为5的Slice再次追加1个元素时，就会发生扩容，如下图所示：
扩容操作只关心容量，会把原Slice数据拷贝到新Slice，追加数据由append在扩容结束后完成。上图可见，扩容后新的Slice长度仍然是5，但容量由5提升到了10，原Slice的数据也都拷贝到了新Slice指向的数组中。
扩容容量的选择遵循以下规则：
- 如果原Slice容量小于1024，则新Slice容量将扩大为原来的2倍；
- 如果原Slice容量大于等于1024，则新Slice容量将扩大为原来的1.25倍；
使用append()向Slice添加一个元素的实现步骤如下：
- 假如Slice容量够用，则将新元素追加进去，Slice.len++，返回原Slice
- 原Slice容量不够，则将Slice先扩容，扩容后得到新Slice
- 将新元素追加进新Slice，Slice.len++，返回新的Slice。
Slice Copy
使用copy()内置函数拷贝两个切片时，会将源切片的数据逐个拷贝到目的切片指向的数组中，拷贝数量取两个切片长度的最小值。
例如长度为10的切片拷贝到长度为5的切片时，将会拷贝5个元素。
也就是说，copy过程中不会发生扩容
Slice总结
- 每个切片都指向一个底层数组
- 每个切片都保存了当前切片的长度、底层数组可用容量
- 使用len()计算切片长度时间复杂度为O(1)，不需要遍历切片
- 使用cap()计算切片容量时间复杂度为O(1)，不需要遍历切片
- 通过函数传递切片时，不会拷贝整个切片，因为切片本身只是个结构体而矣
- 使用append()向切片追加元素时有可能触发扩容，扩容后将会生成新的切片
GMP 模型
线程池的缺陷
我们知道，在高并发应用中频繁创建线程会造成不必要的开销，所以有了线程池。线程池中预先保存一定数量的线程，而新任务将不再以创建线程的方式去执行，而是将任务发布到任务队列，线程池中的线程不断的从任务队列中取出任务并执行，可以有效的减少线程创建和销毁所带来的开销。
下图展示一个典型的线程池：
为了方便下面的叙述，我们把任务队列中的每一个任务称作G，而G往往代表一个函数。 线程池中的线程worker线程不断的从任务队列中取出任务并执行。而worker线程的调度则交给操作系统进行调度。
如果worker线程执行的G任务中发生系统调用，则操作系统会将该线程置为阻塞状态，也意味着该线程在怠工，也意味着消费任务队列的worker线程变少了，也就是说线程池消费任务队列的能力变弱了。
如果任务队列中的大部分任务都会进行系统调用，则会让这种状态恶化，大部分worker线程进入阻塞状态，从而任务队列中的任务产生堆积。
解决这个问题的一个思路就是重新审视线程池中线程的数量，增加线程池中线程数量可以一定程度上提高消费能力，但随着线程数量增多，由于过多线程争抢CPU，消费能力会有上限，甚至出现消费能力下降。 如下图所示：
2. Goroutine调度器
线程数过多，意味着操作系统会不断的切换线程，频繁的上下文切换就成了性能瓶颈。 Go提供一种机制，可以在线程中自己实现调度，上下文切换更轻量，从而达到了线程数少，而并发数并不少的效果。而线程中调度的就是Goroutine.
早期Go版本，比如1.9.2版本的源码注释中有关于调度器的解释。 Goroutine 调度器的工作就是把“ready-to-run”的goroutine分发到线程中。
Goroutine主要概念如下：
- G（Goroutine）: 即Go协程，每个go关键字都会创建一个协程。
- M（Machine）： 工作线程，在Go中称为Machine。
- P(Processor): 处理器（Go中定义的一个摡念，不是指CPU），包含运行Go代码的必要资源，也有调度goroutine的能力。
M必须拥有P才可以执行G中的代码，P含有一个包含多个G的队列，P可以调度G交由M执行。其关系如下图所示：
图中M是交给操作系统调度的线程，M持有一个P，P将G调度进M中执行。P同时还维护着一个包含G的队列（图中灰色部分），可以按照一定的策略将不能的G调度进M中执行。
P的个数在程序启动时决定，默认情况下等同于CPU的核数，由于M必须持有一个P才可以运行Go代码，所以同时运行的M个数，也即线程数一般等同于CPU的个数，以达到尽可能的使用CPU而又不至于产生过多的线程切换开销。
runtime.GOMAXPROCS()3. Goroutine调度策略
3.1 队列轮转
上图中可见每个P维护着一个包含G的队列，不考虑G进入系统调用或IO操作的情况下，P周期性的将G调度到M中执行，执行一小段时间，将上下文保存下来，然后将G放到队列尾部，然后从队列中重新取出一个G进行调度。
除了每个P维护的G队列以外，还有一个全局的队列，每个P会周期性的查看全局队列中是否有G待运行并将期调度到M中执行，全局队列中G的来源，主要有从系统调用中恢复的G。之所以P会周期性的查看全局队列，也是为了防止全局队列中的G被饿死。
3.2 系统调用
上面说到P的个数默认等于CPU核数，每个M必须持有一个P才可以执行G，一般情况下M的个数会略大于P的个数，这多出来的M将会在G产生系统调用时发挥作用。类似线程池，Go也提供一个M的池子，需要时从池子中获取，用完放回池子，不够用时就再创建一个。
当M运行的某个G产生系统调用时，如下图所示：
如图所示，当G0即将进入系统调用时，M0将释放P，进而某个空闲的M1获取P，继续执行P队列中剩下的G。而M0由于陷入系统调用而进被阻塞，M1接替M0的工作，只要P不空闲，就可以保证充分利用CPU。
M1的来源有可能是M的缓存池，也可能是新建的。当G0系统调用结束后，跟据M0是否能获取到P，将会将G0做不同的处理：
- 如果有空闲的P，则获取一个P，继续执行G0。
- 如果没有空闲的P，则将G0放入全局队列，等待被其他的P调度。然后M0将进入缓存池睡眠。
3.3 工作量窃取
多个P中维护的G队列有可能是不均衡的，比如下图：
竖线左侧中右边的P已经将G全部执行完，然后去查询全局队列，全局队列中也没有G，而另一个M中除了正在运行的G外，队列中还有3个G待运行。此时，空闲的P会将其他P中的G偷取一部分过来，一般每次偷取一半。偷取完如右图所示。
4. GOMAXPROCS设置对性能的影响
一般来讲，程序运行时就将GOMAXPROCS大小设置为CPU核数，可让Go程序充分利用CPU。 在某些IO密集型的应用里，这个值可能并不意味着性能最好。 理论上当某个Goroutine进入系统调用时，会有一个新的M被启用或创建，继续占满CPU。 但由于Go调度器检测到M被阻塞是有一定延迟的，也即旧的M被阻塞和新的M得到运行之间是有一定间隔的，所以在IO密集型应用中不妨把GOMAXPROCS设置的大一些，或许会有好的效果。
sync.WaitGroup
信号量
信号量是Unix系统提供的一种保护共享资源的机制，用于防止多个线程同时访问某个资源。
可简单理解为信号量为一个数值：
- 当信号量>0时，表示资源可用，获取信号量时系统自动将信号量减1；
- 当信号量==0时，表示资源暂不可用，获取信号量时，当前线程会进入睡眠，当信号量为正时被唤醒；
由于WaitGroup实现中也使用了信号量，在此做个简单介绍。
WaitGroup
数据结构
src/sync/waitgroup.go:WaitGrouptype WaitGroup struct {
state1 [3]uint32
}
state1是个长度为3的数组，其中包含了state和一个信号量，而state实际上是两个计数器：
- counter： 当前还未执行结束的goroutine计数器
- waiter count: 等待goroutine-group结束的goroutine数量，即有多少个等候者
- semaphore: 信号量
考虑到字节是否对齐，三者出现的位置不同，为简单起见，依照字节已对齐情况下，三者在内存中的位置如下所示：
WaitGroup对外提供三个接口：
- Add(delta int): 将delta值加到counter中
- Wait()： waiter递增1，并阻塞等待信号量semaphore
- Done()： counter递减1，按照waiter数值释放相应次数信号量
下面分别介绍这三个函数的实现细节。
Add(delta int)
Add()做了两件事，一是把delta值累加到counter中，因为delta可以为负值，也就是说counter有可能变成0或负值，所以第二件事就是当counter值变为0时，跟据waiter数值释放等量的信号量，把等待的goroutine全部唤醒，如果counter变为负值，则panic.
Add()伪代码如下：
func (wg *WaitGroup) Add(delta int) {
statep, semap := wg.state() //获取state和semaphore地址指针
state := atomic.AddUint64(statep, uint64(delta)<<32) //把delta左移32位累加到state，即累加到counter中
v := int32(state >> 32) //获取counter值
w := uint32(state) //获取waiter值
if v < 0 { //经过累加后counter值变为负值，panic
panic("sync: negative WaitGroup counter")
}
//经过累加后，此时，counter >= 0
//如果counter为正，说明不需要释放信号量，直接退出
//如果waiter为零，说明没有等待者，也不需要释放信号量，直接退出
if v > 0 || w == 0 {
return
}
//此时，counter一定等于0，而waiter一定大于0（内部维护waiter，不会出现小于0的情况），
//先把counter置为0，再释放waiter个数的信号量
*statep = 0
for ; w != 0; w-- {
runtime_Semrelease(semap, false) //释放信号量，执行一次释放一个，唤醒一个等待者
}
}
Wait()
Wait()方法也做了两件事，一是累加waiter, 二是阻塞等待信号量
func (wg *WaitGroup) Wait() {
statep, semap := wg.state() //获取state和semaphore地址指针
for {
state := atomic.LoadUint64(statep) //获取state值
v := int32(state >> 32) //获取counter值
w := uint32(state) //获取waiter值
if v == 0 { //如果counter值为0，说明所有goroutine都退出了，不需要待待，直接返回
return
}
// 使用CAS（比较交换算法）累加waiter，累加可能会失败，失败后通过for loop下次重试
if atomic.CompareAndSwapUint64(statep, state, state+1) {
runtime_Semacquire(semap) //累加成功后，等待信号量唤醒自己
return
}
}
}
这里用到了CAS算法保证有多个goroutine同时执行Wait()时也能正确累加waiter。
Done()
Done()只做一件事，即把counter减1，我们知道Add()可以接受负值，所以Done实际上只是调用了Add(-1)。
源码如下：
func (wg *WaitGroup) Done() {
wg.Add(-1)
}
Done()的执行逻辑就转到了Add()，实际上也正是最后一个完成的goroutine把等待者唤醒的。
go内存分配原理
http://books.studygolang.com/GoExpertProgramming/chapter04/4.1-memory_alloc.html
go垃圾回收
http://books.studygolang.com/GoExpertProgramming/chapter04/4.1-memory_alloc.html
go struct能不能比较？
struct能不能比较？ 很显然这句话包含了两种情况：
- 同一个struct的两个实例能不能比较？
- 两个不同的struct的实例能不能比较？
在分析上面两个问题前，先跟大家梳理一下golang中，哪些数据类型是可比较的，哪些是不可比较的：
- 可比较：Integer，Floating-point，String，Boolean，Complex(复数型)，Pointer，Channel，Interface，Array
- 不可比较：Slice，Map，Function
struct可以作为map的key么？*
struct必须是可比较的，才能作为key，否则编译时报错
两个不同的struct的实例能不能比较？
结论：可以比较，也不可以比较，可通过强制转换来比较
如果成员变量中含有不可比较成员变量，即使可以强制转换，也不可以比较
go defer（for defer）
- defer定义的延迟函数参数在defer语句出时就已经确定下来了
- defer定义顺序与实际执行顺序相反
- return不是原子操作，执行过程是: 保存返回值(若有)–>执行defer（若有）–>执行ret跳转
- 申请资源后立即使用defer关闭资源是好习惯
切忌在循环中直接使用defer
for {
time.Sleep(time.Second)
// ......
conn, err := grpc.Dial(address, grpc.WithInsecure())
if err != nil {
log.Fatalf("did not connect: %v", err)
}
defer conn.Close()
//...
}
由于这是一个死循环，defer代码不会被执行到，所以申请的内存得不到释放，然后会导致程序占满整个内存，死机。 注意这里需要强调的是直接使用，如果是封装到匿名函数中，结果就不一样了
for {
time.Sleep(time.Second)
// ......
go func (){
conn, err := grpc.Dial(address, grpc.WithInsecure())
if err != nil {
log.Fatalf("did not connect: %v", err)
}
defer conn.Close()
}
//...
}
这里的defer会在匿名函数结束的时候得到执行，所以这样写就不会出现之前的资源没有释放的情况
select可以用于什么？
常用语gorotine的完美退出
golang 的 select 就是监听 IO 操作，当 IO 操作发生时，触发相应的动作每个case语句里必须是一个IO操作，确切的说，应该是一个面向channel的IO操作
基本使用
-
select是Go中的一个控制结构，类似于switch语句，用于处理异步IO操作。select会监听case语句中channel的读写操作，当case中channel读写操作为非阻塞状态（即能读写）时，将会触发相应的动作。
- select中的default子句总是可运行的
- select中的case语句必须是一个channel操作
-
如果有多个case都可以运行，select会随机公平地选出一个执行，其他不会执行。
-
如果没有可运行的case语句，且有default语句，那么就会执行default的动作。
-
如果没有可运行的case语句，且没有default语句，select将阻塞，直到某个case通信可以运行
典型用法
1.超时判断
//比如在下面的场景中，使用全局resChan来接受response，如果时间超过3S,resChan中还没有数据返回，则第二条case将执行
var resChan = make(chan int)
// do request
func test() {
select {
case data := <-resChan: //
doData(data)
case <-time.After(time.Second * 3):
fmt.Println("request time out")
}
}
func doData(data int) {
//...
}
2.退出
//主线程（协程）中如下：
var shouldQuit=make(chan struct{})
fun main(){
{
//loop
}
//...out of the loop
select {
case <-c.shouldQuit:
cleanUp()
return
default:
}
//...
}
//再另外一个协程中，如果运行遇到非法操作或不可处理的错误，就向shouldQuit发送数据通知程序停止运行
close(shouldQuit)
3.判断channel是否阻塞
//在某些情况下是存在不希望channel缓存满了的需求的，可以用如下方法判断
ch := make (chan int, 5)
//...
data：=0
select {
case ch <- data:
default:
//做相应操作，比如丢弃data。视需求而定
}
slice，len，cap，共享，扩容
map如何顺序读取？
// Put the keys in a slice and sort it.
var keys []string
for key := range fruits {
keys = append(keys, key)
}
sort.Strings(keys)
// Display keys according to the sorted slice.
for _, key := range keys {
fmt.Printf("%s:%v\n", key, fruits[key])
}
golang：线程安全的map----sync.Map
map 线程不安全
Go语言中的 map 在并发情况下，只读是线程安全的，同时读写是线程不安全的。
package main
import "fmt"
func main() {
m := make(map[int]int)
go func() {
// 不停地对map进行写入
for {
m[1] = 1
}
}()
go func() {
// 不停地对map进行读取
for {
_ = m[1]
}
}()
fmt.Scanln()
}
fatal error: concurrent map read and map write
错误信息显示：并发的map读和map写，也就是说使用了两个并发函数不断的对map进行读和写而发生了竞态问题，map 内部会对这种并发操作进行检查并提前发现。
需要并发读写时，一般的做法是加锁，但这样性能并不高，Go语言在 1.9 版本中提供了一种效率较高的并发安全的 sync.Map，sync.Map 和 map 不同，不是以语言原生形态提供，而是在 sync 包下的特殊结构。
sync.Map 有以下特性：
-
无须初始化，直接声明即可。
-
sync.Map 不能使用 map 的方式进行取值和设置等操作，而是使用 sync.Map 的方法进行调用，Store 表示存储，Load 表示获取，Delete 表示删除。
-
使用 Range 配合一个回调函数进行遍历操作，通过回调函数返回内部遍历出来的值，Range 参数中回调函数的返回值在需要继续迭代遍历时，返回 true，终止迭代遍历时，返回 false。
-
LoadOrStore：参数是一对key：value，如果该key存在且没有被标记删除则返回原先的value（不更新）和true；不存在则store，返回该value 和false
sync.Map 没有提供获取 map 数量的方法，替代方法是在获取 sync.Map 时遍历自行计算数量，sync.Map 为了保证并发安全有一些性能损失，因此在非并发情况下，使用 map 相比使用 sync.Map 会有更好的性能。
channel底层实现
channel一个类型管道，通过它可以在goroutine之间发送和接收消息。它是Golang在语言层面提供的goroutine间的通信方式。Go依赖于成为CSP的并发模型，通过Channel实现这种同步模式。Golang并发的核心哲学是不要通过共享内存进行通信。
下面Go通过channel来实现通信例子：
package main
import (
"fmt"
"time"
)
func goRoutineA(a <-chan int) {
val := <-a
fmt.Println("goRoutineA received the data", val)
}
func goRoutineB(b chan int) {
val := <-b
fmt.Println("goRoutineB received the data", val)
}
func main() {
ch := make(chan int, 3)
go goRoutineA(ch)
go goRoutineB(ch)
ch <- 3
time.Sleep(time.Second * 1)
}
终端显示结果：
~$ goRoutineA recv the data 3
上面的例子只输出goRoutineA信息，没有执行goRoutineB说明channel仅允许被一个goroutine读写。
下面通过源码程序执行过程分析，如果对go并发和调度相关知识不了解，可以预览这里
首先我们看下通道的结构hchan,源码再src/runtime/chan.go下
type hchan struct {
qcount uint // total data in the queue 当前队列里还剩余元素个数
dataqsiz uint // size of the circular queue 环形队列长度，即缓冲区的大小，即make(chan T,N) 中的N
buf unsafe.Pointer // points to an array of dataqsiz elements 环形队列指针
elemsize uint16 //每个元素的大小
closed uint32 //标识当前通道是否处于关闭状态，创建通道后，该字段设置0，即打开通道；通道调用close将其设置为1，通道关闭
elemtype *_type // element type 元素类型，用于数据传递过程中的赋值
sendx uint // send index 环形缓冲区的状态字段，它只是缓冲区的当前索引-支持数组，它可以从中发送数据
recvx uint // receive index 环形缓冲区的状态字段，它只是缓冲区当前索引-支持数组，它可以从中接受数据
recvq waitq // list of recv waiters 等待读消息的goroutine队列
sendq waitq // list of send waiters 等待写消息的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 //互斥锁，为每个读写操作锁定通道，因为发送和接受必须是互斥操作
}
// sudog 代表goroutine
type waitq struct {
first *sudog
last *sudog
}
创建两种channel类型，一个带缓冲区和一个不带缓冲区的channel
//带缓冲区
ch:=make(chan int, 3)
//不带缓冲区
ch:=make(chan int)
带缓冲区
ch:=make(chan int, 3)
创建通道后的缓冲通道结构
hchan struct {
qcount uint : 0
dataqsiz uint : 3 //buf
buf unsafe.Pointer : 0xc00007e0e0 //环形队列指针
elemsize uint16 : 8 // 字段大小
closed uint32 : 0 // 该字段设置0，即打开通道；通道调用close将其设置为1，通道关闭
elemtype *runtime._type : &{ //元素类型，用于数据传递过程中的赋值
size:8
ptrdata:0
hash:4149441018
tflag:7
align:8
fieldalign:8
kind:130
alg:0x55cdf0
gcdata:0x4d61b4
str:1055
ptrToThis:45152
}
sendx uint : 0 //环形缓冲区的状态字段，它只是缓冲区的当前索引-支持数组，它可以从中发送数据
recvx uint : 0 //环形缓冲区的状态字段，它只是缓冲区当前索引-支持数组，它可以从中接受数据
recvq runtime.waitq : //等待读消息的goroutine队列
{first:<nil> last:<nil>}
sendq runtime.waitq : //等待写消息的goroutine队列
{first:<nil> last:<nil>}
lock runtime.mutex :
{key:0}
}
源码在$GOPATH/src/runtime/chan.go下：
func makechan(t *chantype, size int) *hchan {
elem := t.elem
...
}
创建一个带有buffer的channel，底层的数据结构模型如图：
向channel中写入数据
ch <- 3
底层hchan数据流程下如图：
发送操作步骤：
- 锁定整个通道结构
- 确定写入。城市recvq从等待队列中等待goroutine，然后将元素直接写入goroutine
- 如果recvq为Empty，则确定缓冲区是否可用，如果可用那么从当前goroutine复制数据到缓冲区中。
- 如果缓冲区已经满了，则要写入的元素将保存在当前执行的goroutine结构中，并且当前goroutine在sendq中并且队列从运行时挂起。
- 写入完成释放锁
- 需要注意的接个属性的变化：buf、sendx、lock
执行流程图如下：
从channel中读取数据
从channel中读取数据操作几乎和写入操作雷同
func goRoutineA(a <-chan int){
val := <- a
fmt.Println("goRoutineA received the data",val)
}
底层hchan数据流转如下图:
- 需要注意的几个属性变化 buf、sendx、recvx、lock
读数据操作如下:
- 先获取channel全局锁
- 尝试sendq等待队列中获取等待的goroutine
- 如果有等待的goroutine，没有缓冲区，取出goroutine并读取数据，然后唤醒这个goroutine，结束读取释放锁
- 如果有等待goroutine，且有缓冲区(缓冲区满了)，从缓冲区队列首取数据，再从sendq取出一个goroutine，将goroutine中的数据存放到buf队列尾，结束读取释放锁。
- 如果没有等待的goroutine，且缓冲区有数据，直接读取缓冲区数据，结束释放锁。
- 如果没有等待的goroutine，且没有缓冲区或者缓冲区为空，将当前goroutine加入到sendq队列，进入睡眠，等待被写入goroutine唤醒，结束读取释放锁。
大概流程如下：
recvq和sendq结构
recvq和sendq基本上是链表，基本如下：
向为 nil 的 channel 发送数据会怎么样
当未为channel分配内存时，channel就是nil channel，例如var ch1 chan int。nil channel会永远阻塞对该channel的读、写操作。
nil channel会阻塞对该channel的所有读、写。所以，可以将某个channel设置为nil，进行强制阻塞，对于select分支来说，就是强制禁用此分支。
for 循环遍历 slice 有什么问题
将临时变量stu的地址给map，最后所有的地址都为同样的一个值
Go 闭包
函数在Golang中是“一等公民”，因此关于函数的特性必须要掌握号，闭包可以看成函数的高阶应用，是Golang高级开发的必备技能。
“一等公民”意味着函数可以像普通的类型（整型、字符串等）一样进行赋值、作为函数的参数传递、作为函数的返回值等。Golang的函数只能返回匿名函数！
闭包是匿名函数与匿名函数所引用环境的组合。匿名函数有动态创建的特性，该特性使得匿名函数不用通过参数传递的方式，就可以直接引用外部的变量。这就类似于常规函数直接使用全局变量一样，个人理解为：匿名函数和它引用的变量以及环境，类似常规函数引用全局变量处于一个包的环境。
go test 要点
单元测试、性能测试、示例测试
单元测试从上面可以看出，编写一个单元测试并执行是非常方便的，只需要遵循一定的规则：
- 测试文件名必须以"_test.go"结尾；
- 测试函数名必须以“TestXxx”开始；
- 命令行下使用"go test"即可启动测试；
性能测试从上面的例子可以看出，编写并执行性能测试是非常简单的，只需要遵循一些规则：
- 文件名必须以“_test.go”结尾；
- 函数名必须以“BenchmarkXxx”开始；
- 使用命令“go test -bench=.”即可开始性能测试；
-benchBenchmarkMakeSliceWithoutAlloc1103822BenchmarkMakeSliceWithPreAlloc328944示例测试go testgo test package gotest
import "fmt"
// SayHello 打印一行字符串
func SayHello() {
fmt.Println("Hello World")
}
// SayGoodbye 打印两行字符串
func SayGoodbye() {
fmt.Println("Hello,")
fmt.Println("goodbye")
}
// PrintNames 打印学生姓名
func PrintNames() {
students := make(map[int]string, 4)
students[1] = "Jim"
students[2] = "Bob"
students[3] = "Tom"
students[4] = "Sue"
for _, value := range students {
fmt.Println(value)
}
}
进程、线程、协程区别
进程管道(Pipe)、命名管道(FIFO)、消息队列(Message Queue) 、信号量(Semaphore) 、共享内存（Shared Memory）；套接字（Socket）
线程，有时被称为轻量级进程(Lightweight Process，LWP），是操作系统调度（CPU调度）执行的最小单位。
三、进程和线程的区别与联系
【区别】：
-
调度：线程作为调度和分配的基本单位，进程作为拥有资源的基本单位；
-
并发性：不仅进程之间可以并发执行，同一个进程的多个线程之间也可并发执行；
-
拥有资源：进程是拥有资源的一个独立单位，线程不拥有系统资源，但可以访问隶属于进程的资源。进程所维护的是程序所包含的资源（静态资源）， 如：地址空间，打开的文件句柄集，文件系统状态，信号处理handler等；线程所维护的运行相关的资源（动态资源），如：运行栈，调度相关的控制信息，待处理的信号集等；
-
系统开销：在创建或撤消进程时，由于系统都要为之分配和回收资源，导致系统的开销明显大于创建或撤消线程时的开销。但是进程有独立的地址空间，一个进程崩溃后，在保护模式下不会对其它进程产生影响，而线程只是一个进程中的不同执行路径。线程有自己的堆栈和局部变量，但线程之间没有单独的地址空间，一个进程死掉就等于所有的线程死掉，所以多进程的程序要比多线程的程序健壮，但在进程切换时，耗费资源较大，效率要差一些。
【联系】：
def A():
print '1'
print '2'
print '3'
def B():
print 'x'
print 'y'
print 'z'
请你说说golang的CSP思想
go语言的最大两个亮点，一个是goroutine，一个就是chan了。二者合体的典型应用CSP，基本就是大家认可的并行开发神器，简化了并行程序的开发难度，我们来看一下CSP。
一、CSP是什么
CSP 是 Communicating Sequential Process 的简称，中文可以叫做通信顺序进程，是一种并发编程模型，是一个很强大的并发数据模型，是上个世纪七十年代提出的，用于描述两个独立的并发实体通过共享的通讯 channel(管道)进行通信的并发模型。相对于Actor模型，CSP中channel是第一类对象，它不关注发送消息的实体，而关注与发送消息时使用的channel。
严格来说，CSP 是一门形式语言（类似于 ℷ calculus），用于描述并发系统中的互动模式，也因此成为一众面向并发的编程语言的理论源头，并衍生出了 Occam/Limbo/Golang…
而具体到编程语言，如 Golang，其实只用到了 CSP 的很小一部分，即理论中的 Process/Channel（对应到语言中的 goroutine/channel）：这两个并发原语之间没有从属关系， Process 可以订阅任意个 Channel，Channel 也并不关心是哪个 Process 在利用它进行通信；Process 围绕 Channel 进行读写，形成一套有序阻塞和可预测的并发模型。
二、Golang CSP
与主流语言通过共享内存来进行并发控制方式不同，Go 语言采用了 CSP 模式。这是一种用于描述两个独立的并发实体通过共享的通讯 Channel（管道）进行通信的并发模型。
Golang 就是借用CSP模型的一些概念为之实现并发进行理论支持，其实从实际上出发，go语言并没有，完全实现了CSP模型的所有理论，仅仅是借用了 process和channel这两个概念。process是在go语言上的表现就是 goroutine 是实际并发执行的实体，每个实体之间是通过channel通讯来实现数据共享。
Go语言的CSP模型是由协程Goroutine与通道Channel实现：
-
Go协程goroutine: 是一种轻量线程，它不是操作系统的线程，而是将一个操作系统线程分段使用，通过调度器实现协作式调度。是一种绿色线程，微线程，它与Coroutine协程也有区别，能够在发现堵塞后启动新的微线程。
-
通道channel: 类似Unix的Pipe，用于协程之间通讯和同步。协程之间虽然解耦，但是它们和Channel有着耦合。
三、Channel
Goroutine 和 channel 是 Go 语言并发编程的 两大基石。Goroutine 用于执行并发任务，channel 用于 goroutine 之间的同步、通信。
Channel 在 gouroutine 间架起了一条管道，在管道里传输数据，实现 gouroutine 间的通信；由于它是线程安全的，所以用起来非常方便；channel 还提供 “先进先出” 的特性；它还能影响 goroutine 的阻塞和唤醒。
相信大家一定见过一句话：
Do not communicate by sharing memory; instead, share memory by communicating.
不要通过共享内存来通信，而要通过通信来实现内存共享。
这就是 Go 的并发哲学，它依赖 CSP 模型，基于 channel 实现。
channel 实现 CSP
Channel 是 Go 语言中一个非常重要的类型，是 Go 里的第一对象。通过 channel，Go 实现了通过通信来实现内存共享。Channel 是在多个 goroutine 之间传递数据和同步的重要手段。
使用原子函数、读写锁可以保证资源的共享访问安全，但使用 channel 更优雅。
channel 字面意义是 “通道”，类似于 Linux 中的管道。声明 channel 的语法如下：
chan T // 声明一个双向通道
chan<- T // 声明一个只能用于发送的通道
<-chan T // 声明一个只能用于接收的通道
单向通道的声明，用 <- 来表示，它指明通道的方向。你只要明白，代码的书写顺序是从左到右就马上能掌握通道的方向是怎样的。
因为 channel 是一个引用类型，所以在它被初始化之前，它的值是 nil，channel 使用 make 函数进行初始化。可以向它传递一个 int 值，代表 channel 缓冲区的大小（容量），构造出来的是一个缓冲型的 channel；不传或传 0 的，构造的就是一个非缓冲型的 channel。
两者有一些差别：非缓冲型 channel 无法缓冲元素，对它的操作一定顺序是 “发送 -> 接收 -> 发送 -> 接收 -> ……”，如果想连续向一个非缓冲 chan 发送 2 个元素，并且没有接收的话，第一次一定会被阻塞；对于缓冲型 channel 的操作，则要 “宽松” 一些，毕竟是带了 “缓冲” 光环。
对 chan 的发送和接收操作都会在编译期间转换成为底层的发送接收函数。
Channel 分为两种：带缓冲、不带缓冲。对不带缓冲的 channel 进行的操作实际上可以看作 “同步模式”，带缓冲的则称为 “异步模式”。
-
同步模式下，发送方和接收方要同步就绪，只有在两者都 ready 的情况下，数据才能在两者间传输（后面会看到，实际上就是内存拷贝）。否则，任意一方先行进行发送或接收操作，都会被挂起，等待另一方的出现才能被唤醒。
-
异步模式下，在缓冲槽可用的情况下（有剩余容量），发送和接收操作都可以顺利进行。否则，操作的一方（如写入）同样会被挂起，直到出现相反操作（如接收）才会被唤醒。
小结一下：同步模式下，必须要使发送方和接收方配对，操作才会成功，否则会被阻塞；异步模式下，缓冲槽要有剩余容量，操作才会成功，否则也会被阻塞。
简单来说，CSP 模型由并发执行的实体（线程或者进程或者协程）所组成，实体之间通过发送消息进行通信，
这里发送消息时使用的就是通道，或者叫 channel。
CSP 模型的关键是关注 channel，而不关注发送消息的实体。Go 语言实现了 CSP 部分理论，goroutine 对应 CSP 中并发执行的实体，channel 也就对应着 CSP 中的 channel。
四、Goroutine
Goroutine 是实际并发执行的实体，它底层是使用协程(coroutine)实现并发，coroutine是一种运行在用户态的用户线程，类似于 greenthread，go底层选择使用coroutine的出发点是因为，它具有以下特点：
-
用户空间 避免了内核态和用户态的切换导致的成本
-
可以由语言和框架层进行调度
-
更小的栈空间允许创建大量的实例
可以看到第二条 用户空间线程的调度不是由操作系统来完成的，像在java 1.3中使用的greenthread的是由JVM统一调度的(后java已经改为内核线程)，还有在ruby中的fiber(半协程) 是需要在重新中自己进行调度的，而goroutine是在golang层面提供了调度器，并且对网络IO库进行了封装，屏蔽了复杂的细节，对外提供统一的语法关键字支持，简化了并发程序编写的成本。
五、Goroutine 调度器
Go并发调度: G-P-M模型
在操作系统提供的内核线程之上，Go搭建了一个特有的两级线程模型。goroutine机制实现了M : N的线程模型，goroutine机制是协程（coroutine）的一种实现，golang内置的调度器，可以让多核CPU中每个CPU执行一个协程。
六、最后
Golang 的 channel 将 goroutine 隔离开，并发编程的时候可以将注意力放在 channel 上。在一定程度上，这个和消息队列的解耦功能还是挺像的。如果大家感兴趣，还是来看看 channel 的源码吧，对于更深入地理解 channel 还是挺有用的。
Go 通过 channel 实现 CSP 通信模型，主要用于 goroutine 之间的消息传递和事件通知。
有了 channel 和 goroutine 之后，Go 的并发编程变得异常容易和安全，得以让程序员把注意力留到业务上去，实现开发效率的提升。
要知道，技术并不是最重要的，它只是实现业务的工具。一门高效的开发语言让你把节省下来的时间，留着去做更有意义的事情，比如写写文章。
go 内存逃逸分析（分析了栈帧，讲五种例子，描述堆栈优缺点，点头）
1 前言
所谓逃逸分析（Escape analysis）是指由编译器决定内存分配的位置，不需要程序员指定。 函数中申请一个新的对象
- 如果分配 在栈中，则函数执行结束可自动将内存回收；
- 如果分配在堆中，则函数执行结束可交给GC（垃圾回收）处理;
有了逃逸分析，返回函数局部变量将变得可能，除此之外，逃逸分析还跟闭包息息相关，了解哪些场景下对象会逃逸至关重要。
2 逃逸策略
每当函数中申请新的对象，编译器会跟据该对象是否被函数外部引用来决定是否逃逸：
- 如果函数外部没有引用，则优先放到栈中；
- 如果函数外部存在引用，则必定放到堆中；
注意，对于函数外部没有引用的对象，也有可能放到堆中，比如内存过大超过栈的存储能力。
3 逃逸场景
3.1 指针逃逸
我们知道Go可以返回局部变量指针，这其实是一个典型的变量逃逸案例，示例代码如下：
package main
type Student struct {
Name string
Age int
}
func StudentRegister(name string, age int) *Student {
s := new(Student) //局部变量s逃逸到堆
s.Name = name
s.Age = age
return s
}
func main() {
StudentRegister("Jim", 18)
}
函数StudentRegister()内部s为局部变量，其值通过函数返回值返回，s本身为一指针，其指向的内存地址不会是栈而是堆，这就是典型的逃逸案例。
通过编译参数-gcflag=-m可以查年编译过程中的逃逸分析：
D:\SourceCode\GoExpert\src>go build -gcflags=-m
# _/D_/SourceCode/GoExpert/src
.\main.go:8: can inline StudentRegister
.\main.go:17: can inline main
.\main.go:18: inlining call to StudentRegister
.\main.go:8: leaking param: name
.\main.go:9: new(Student) escapes to heap
.\main.go:18: main new(Student) does not escape
可见在StudentRegister()函数中，也即代码第9行显示"escapes to heap"，代表该行内存分配发生了逃逸现象。
3.2 栈空间不足逃逸
看下面的代码，是否会产生逃逸呢？
package main
func Slice() {
s := make([]int, 1000, 1000)
for index, _ := range s {
s[index] = index
}
}
func main() {
Slice()
}
上面代码Slice()函数中分配了一个1000个长度的切片，是否逃逸取决于栈空间是否足够大。 直接查看编译提示，如下：
D:\SourceCode\GoExpert\src>go build -gcflags=-m
# _/D_/SourceCode/GoExpert/src
.\main.go:4: Slice make([]int, 1000, 1000) does not escape
我们发现此处并没有发生逃逸。那么把切片长度扩大10倍即10000会如何呢?
D:\SourceCode\GoExpert\src>go build -gcflags=-m
# _/D_/SourceCode/GoExpert/src
.\main.go:4: make([]int, 10000, 10000) escapes to heap
我们发现当切片长度扩大到10000时就会逃逸。
实际上当栈空间不足以存放当前对象时或无法判断当前切片长度时会将对象分配到堆中。
3.3 动态类型逃逸
很多函数参数为interface类型，比如fmt.Println(a …interface{})，编译期间很难确定其参数的具体类型，也人产生逃逸。 如下代码所示：
package main
import "fmt"
func main() {
s := "Escape"
fmt.Println(s)
}
上述代码s变量只是一个string类型变量，调用fmt.Println()时会产生逃逸：
D:\SourceCode\GoExpert\src>go build -gcflags=-m
# _/D_/SourceCode/GoExpert/src
.\main.go:7: s escapes to heap
.\main.go:7: main ... argument does not escape
3.4 闭包引用对象逃逸
某著名的开源框架实现了某个返回Fibonacci数列的函数：
func Fibonacci() func() int {
a, b := 0, 1
return func() int {
a, b = b, a+b
return a
}
}
该函数返回一个闭包，闭包引用了函数的局部变量a和b，使用时通过该函数获取该闭包，然后每次执行闭包都会依次输出Fibonacci数列。 完整的示例程序如下所示：
package main
import "fmt"
func Fibonacci() func() int {
a, b := 0, 1
return func() int {
a, b = b, a+b
return a
}
}
func main() {
f := Fibonacci()
for i := 0; i < 10; i++ {
fmt.Printf("Fibonacci: %d\n", f())
}
}
上述代码通过Fibonacci()获取一个闭包，每次执行闭包就会打印一个Fibonacci数值。输出如下所示：
D:\SourceCode\GoExpert\src>src.exe
Fibonacci: 1
Fibonacci: 1
Fibonacci: 2
Fibonacci: 3
Fibonacci: 5
Fibonacci: 8
Fibonacci: 13
Fibonacci: 21
Fibonacci: 34
Fibonacci: 55
Fibonacci()函数中原本属于局部变量的a和b由于闭包的引用，不得不将二者放到堆上，以致产生逃逸：
D:\SourceCode\GoExpert\src>go build -gcflags=-m
# _/D_/SourceCode/GoExpert/src
.\main.go:7: can inline Fibonacci.func1
.\main.go:7: func literal escapes to heap
.\main.go:7: func literal escapes to heap
.\main.go:8: &a escapes to heap
.\main.go:6: moved to heap: a
.\main.go:8: &b escapes to heap
.\main.go:6: moved to heap: b
.\main.go:17: f() escapes to heap
.\main.go:17: main ... argument does not escape
4 逃逸总结
- 栈上分配内存比在堆中分配内存有更高的效率
- 栈上分配的内存不需要GC处理
- 堆上分配的内存使用完毕会交给GC处理
- 逃逸分析目的是决定内分配地址是栈还是堆
- 逃逸分析在编译阶段完成
是否有逃逸分析过
defer recover 的问题
go的异常捕获需要延迟函数defer + recover实现,在函数返回前,就可以捕获到, 这样其实比java的try catch更加优雅一点；
比如: web服务器程序崩溃前,需要做一些清理,那么就可以这样搞定； 还可以在捕获时，打印一些信息,继续panic,让错误往上抛
案例
如果我们起了一个协程，但这个协程出现了panic，但我们没有捕获这个协程，就会造成程序的崩溃，这时可以在goroutine中使用recover来捕获panic，进行处理，这样主线程不会受到影响。
package main
import (
"fmt"
"time"
)
func sayHello() {
for i := 0; i < 10; i++ {
time.Sleep(time.Second)
fmt.Println("hello world")
}
}
func test() {
//使用 defer + recover
defer func() {
//捕获test抛出的panic
if err := recover();err!=nil{
fmt.Println("test发生错误",err)
}
}()
//定义一个map
var myMap map[int]string
myMap[0] = "golang" //error
}
func main() {
go sayHello()
go test()
for i := 0; i < 10; i++ {
fmt.Println("main() ok=",i)
time.Sleep(time.Second)
}
}
.go:7: func literal escapes to heap
.\main.go:7: func literal escapes to heap
.\main.go:8: &a escapes to heap
.\main.go:6: moved to heap: a
.\main.go:8: &b escapes to heap
.\main.go:6: moved to heap: b
.\main.go:17: f() escapes to heap
.\main.go:17: main … argument does not escape
#### 4 逃逸总结
- 栈上分配内存比在堆中分配内存有更高的效率
- 栈上分配的内存不需要GC处理
- 堆上分配的内存使用完毕会交给GC处理
- 逃逸分析目的是决定内分配地址是栈还是堆
- 逃逸分析在编译阶段完成
## 是否有逃逸分析过
## defer recover 的问题
go的异常捕获需要延迟函数defer + recover实现,在函数返回前,就可以捕获到, 这样其实比java的try catch更加优雅一点；
比如: web服务器程序崩溃前,需要做一些清理,那么就可以这样搞定； 还可以在捕获时，打印一些信息,继续panic,让错误往上抛
==案例==
如果我们起了一个协程，但这个协程出现了panic，但我们没有捕获这个协程，就会造成程序的崩溃，这时可以在goroutine中使用recover来捕获panic，进行处理，这样主线程不会受到影响。
```go
package main
import (
"fmt"
"time"
)
func sayHello() {
for i := 0; i < 10; i++ {
time.Sleep(time.Second)
fmt.Println("hello world")
}
}
func test() {
//使用 defer + recover
defer func() {
//捕获test抛出的panic
if err := recover();err!=nil{
fmt.Println("test发生错误",err)
}
}()
//定义一个map
var myMap map[int]string
myMap[0] = "golang" //error
}
func main() {
go sayHello()
go test()
for i := 0; i < 10; i++ {
fmt.Println("main() ok=",i)
time.Sleep(time.Second)
}
}