golang面试：golang实现原理（二）

title: golang实现原理（二）

auther: Russshare

toc: true

date: 2021-07-13 18:56:46

tags: [golang, 面试]

categories: golang面试

• 2、实现原理

• 01 init() 函数是什么时候执行的？

• init() 函数是 Go 程序初始化的一部分。Go 程序初始化先于 main 函数，由 runtime 初始化每个导入的包，初始化顺序不是按照从上到下的导入顺序，而是按照解析的依赖关系，没有依赖的包最先初始化。
  
• 每个包首先初始化包作用域的常量和变量（常量优先于变量），
  
• 然后执行包的 init() 函数。
  
• 同一个包，甚至是同一个源文件可以有多个 init() 函数。
  
• init() 函数没有入参和返回值，不能被其他函数调用，
  
• 同一个包内多个 init() 函数的执行顺序不作保证。
  
• （全局变量在init后 main之前）
  

• 02 Go 语言的局部变量分配在栈上还是堆上？

• 由编译器决定。Go 语言编译器会自动决定把一个变量放在栈还是放在堆，编译器会做逃逸分析(escape analysis)，当发现变量的作用域没有超出函数范围，就可以在栈上，反之则必须分配在堆上

• 03 2 个 interface 可以比较吗 ？

• Go 语言中，interface 的内部实现包含了 2 个字段，类型 T 和 值 V，interface 可以使用 == 或 != 比较。2 个 interface 相等有以下 2 种情况

• 1）两个 interface 均等于 nil（此时 V 和 T 都处于 unset 状态）
  2）类型 V 相同，且对应的值 V 相等。
  
• 04 2 个 nil 可能不相等吗？

• 可能。

• 接口(interface) 是对非接口值(例如指针，struct等)的封装，内部实现包含 2 个字段，类型 T 和 值 V。一个接口等于 nil，当且仅当 T 和 V 处于 unset 状态（T=nil，V is unset）。
  两个接口值比较时，会先比较 T，再比较 V。
  接口值与非接口值比较时，会先将非接口值尝试转换为接口值，再比较。
  
• 05 简述 Go 语言GC(垃圾回收)的工作原理

• 见下

• 06 函数返回局部变量的指针是否安全？

• 这在 Go 中是安全的，Go 编译器将会对每个局部变量进行逃逸分析。如果发现局部变量的作用域超出该函数，则不会将内存分配在栈上，而是分配在堆上。

• 07 非接口的任意类型 T() 都能够调用 *T 的方法吗？反过来呢？

• 一个T类型的值可以调用为T类型声明的方法，但是仅当此T的值是可寻址(addressable) 的情况下。编译器在调用指针属主方法前，会自动取此T值的地址。因为不是任何T值都是可寻址的，所以并非任何T值都能够调用为类型T声明的方法。
  
• 
  
• 反过来，一个T类型的值可以调用为类型T声明的方法，这是因为引用指针总是合法的。事实上，你可以认为对于每一个为类型 T 声明的方法，编译器都会为类型T自动隐式声明一个同名和同签名的方法。
  
• 哪些值是不可寻址的呢？

• 字符串中的字节；
• map 对象中的元素（slice 对象中的元素是可寻址的，slice的底层是数组）；
• 常量；
• 包级别的函数等。
• 例子

• 08 怎么避免内存逃逸？

• 1、golang程序变量会携带有一组校验数据，用来证明它的整个生命周期是否在运行时完全可知。如果变量通过了这些校验，它就可以在栈上分配。否则就说它 逃逸 了，必须在堆上分配
  
• 2、能引起逃逸的情况

• 在方法内把局部变量指针返回 局部变量原本应该在栈中分配，在栈中回收。但是由于返回时被外部引用，因此其生命周期大于栈，则溢出。
• 发送指针或带有指针的值到 channel 中。 在编译时，是没有办法知道哪个 goroutine 会在 channel 上接收数据。所以编译器没法知道变量什么时候才会被释放。
• 在一个切片上存储指针或带指针的值。 一个典型的例子就是 []*string 。这会导致切片的内容逃逸。尽管其后面的数组可能是在栈上分配的，但其引用的值一定是在堆上。
• slice 的背后数组被重新分配了，因为 append 时可能会超出其容量( cap )。 slice 初始化的地方在编译时是可以知道的，它最开始会在栈上分配。如果切片背后的存储要基于运行时的数据进行扩充，就会在堆上分配。
• 在 interface 类型上调用方法。 在 interface 类型上调用方法都是动态调度的 —— 方法的真正实现只能在运行时知道。想像一个 io.Reader 类型的变量 r , 调用 r.Read(b) 会使得 r 的值和切片b 的背后存储都逃逸掉，所以会在堆上分配。
• 
  
• go build -gcflags=-m

• 3、怎样避免逃逸

• 在runtime/stubs.go:133有个函数叫noescape。noescape可以在逃逸分析中隐藏一个指针。让这个指针在逃逸分析中不会被检测为逃逸。

• 09 互斥锁，读写锁，死锁问题是怎么解决。

• 互斥锁
  互斥锁就是互斥变量mutex，用来锁住临界区的.
  条件锁就是条件变量，当进程的某些资源要求不满足时就进入休眠，也就是锁住了。当资源被分配到了，条件锁打开，进程继续运行；读写锁，也类似，用于缓冲区等临界资源能互斥访问的。
  
• 读写锁
  通常有些公共数据修改的机会很少，但其读的机会很多。并且在读的过程中会伴随着查找，给这种代码加锁会降低我们的程序效率。读写锁可以解决这个问题。
  
• 注意：写独占，读共享，写锁优先级高
  
• 一个是只读的锁，一个是写锁。读锁可以在没有写锁的时候被多个线程同时持有，写锁是独占的。
  所有读写锁的实现必须确保写操作对读操作的内存影响。换句话说，一个获得了读锁的线程必须能看到前一个释放的写锁所更新的内容。
  读写锁比互斥锁允许对于共享数据更大程度的并发。每次只能有一个写线程，但是同时可以有多个线程并发地读数据。ReadWriteLock适用于读多写少的并发情况。
  
• 死锁一般情况下，如果同一个线程先后两次调用lock，在第二次调用时，由于锁已经被占用，该线程会挂起等待别的线程释放锁，然而锁正是被自己占用着的，该线程又被挂起而没有机会释放锁，因此就永远处于挂起等待状态了，这叫做死锁（Deadlock）。另外一种情况是：若线程A获得了锁1，线程B获得了锁2，这时线程A调用lock试图获得锁2，结果是需要挂起等待线程B释放锁2，而这时线程B也调用lock试图获得锁1，结果是需要挂起等待线程A释放锁1，于是线程A和B都永远处于挂起状态了。

• 死锁产生的四个必要条件:

• 互斥条件：一个资源每次只能被一个进程使用
  请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
  不剥夺条件:进程已获得的资源，在末使用完之前，不能强行剥夺。
  循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。
  这四个条件是死锁的必要条件，只要系统发生死锁，这些条件必然成立，而只要上述条件之一不满足，就不会发生死锁。
  
• 银行家算法
  
• 
  
• 预防死锁的几种策略，会严重地损害系统性能。因此在避免死锁时，要施加较弱的限制，从而获得 较满意的系统性能。由于在避免死锁的策略中，允许进程动态地申请资源。因而，系统在进行资源分配之前预先计算资源分配的安全性。若此次分配不会导致系统进入不安全状态，则将资源分配给进程；否则，进程等待。其中最具有代表性的避免死锁算法是银行家算法。
  

• 10 Data Race问题怎么解决？能不能不加锁解决这个问题？

• 同步访问共享数据是处理数据竞争的一种有效的方法.golang在1.1之后引入了竞争检测机制，可以使用 go run -race 或者 go build -race来进行静态检测。 其在内部的实现是,开启多个协程执行同一个命令， 并且记录下每个变量的状态.
  
• 要想解决数据竞争的问题可以使用互斥锁sync.Mutex,解决数据竞争(Data race),也可以使用管道解决,使用管道的效率要比互斥锁高.
  

• 11 Epoll原理.

• Epoll是一种IO多路复用技术，可以非常高效的处理数以百万计的Socket句柄，比起以前的Select和EPoll效率提高了很多。
  
• 因此epoll比select的提高实际上是一个用空间换时间思想的具体应用.
  

• 12 Log包线程安全吗？

• Golang的标准库提供了log的机制，但是该模块的功能较为简单（看似简单，其实他有他的设计思路）。在输出的位置做了线程安全的保护。