前言

哈喽，大家好，我是asong。今天与大家来聊一聊内联函数。虽然我们在开发中根本不需要考虑内联函数，其在编译器编译代码时会做优化，但是如果想分析更底层的技术，这个知识是要必备，今天我们就一起来看看什么是内联函数以及Go编译器是如何对函数调用做优化的！

什么是内联函数

学过C语言的朋友应该对内联函数不陌生吧，在C语言中一个inline关键字，使用inline修饰的函数就是内联函数。

示例：

#include <stdio.h>    
inline char* chooseParity(int a) 
{  
 return (i % 2 > 0) ? "奇" : "偶";  
}   
  
int main()  
{  
 int i = 0;  
 for (i=1; i < 100; i++) 
 {  
  printf("i:%d    奇偶性:%s /n", i, chooseParity(i));      
 }  
} 

这段代码中函数char* chooseParity(int a)使用inline进行修饰，那么这段代码在执行的时候就会变成这样：

int i = 0;  
for (i=1; i < 100; i++) 
{  
 printf("i:%d    奇偶性:%s /n", i, (i % 2 > 0) ? "奇" : "偶");      
}  

这样就避免了频繁调用函数对栈内存重复开辟所带来的消耗，我们都知道一些函数被频繁调用，会不断地有函数入栈，即函数栈，会造成栈空间或栈内存的大量消耗，内联函数的出现节省了每次调用函数带来的额外时间开支。但并不是所有场景都可以使用内联函数的，必须在程序占用空间和程序执行效率之间进行权衡，因为过多的比较复杂的函数进行内联扩展将带来很大的存储资源开支。

大多数语言的内联函数的优化都是在编译器编译代码时进行的，在C语言中编译器也会对函数调用进行优化，但是其还是提供了inline关键字，这是因为在C编译其中可以选择不同的优化级别，有些函数在As-if规则是不可分辨的，所以提供inline供使用者使用，保证没有触发规则时，仍然是内联函数，说难听点就是起到擦屁股的作用！Go 语言的编译器也会对函数调用进行优化，但是他没有提供任何关键字可以手动声明内联函数，不过我们可以在函数上添加//go:noinline注释告诉编译器不要对它进行内联优化。

示例：

//go:noinline
func maxValue(a,b int) int {
 if a > b{
  return a
 }
 return b
}

内联函数优化带来的性能提升

接下来，我们来写一个简单的例子看一看内联函数与非内联函数的差异。

//go:noinline
func AddNoinline(x,y,z int) int {
 return x+y+z
}

func AddInline(x,y,z int) int {
 return x+y+z
}
func BenchmarkAddNoinline(b *testing.B) {
 x,y,z :=1,2,3
 b.ResetTimer()
 for i:=0;i<b.N;i++{
  AddNoinline(x,y,z)
 }
}

func BenchmarkAddInline(b *testing.B) {
 x,y,z :=1,2,3
 b.ResetTimer()
 for i:=0;i<b.N;i++{
  AddNoinline(x,y,z)
 }
}

运行结果：

goos: darwin
goarch: amd64
pkg: asong.cloud/Golang_Dream/code_demo/inline
BenchmarkAddNoinline-16         657618259                1.70 ns/op
BenchmarkAddInline-16           676145614                1.62 ns/op
PASS
ok      asong.cloud/Golang_Dream/code_demo/inline       3.316s

从运行结果我们可以看出内联函数的处理速度还是略快于非内联函数，因为我这个例子比较简单，所以差异还不是特别明显。

查看编译器做了什么优化

我们在编译代码时传入--gcflags=-m参数可以查看编译器的优化策略，传入--gcflags="-m -m"会查看更完整的优化策略！

示例：

func main(){
 s := []int{10,12,3,14}
 fmt.Println(GetMaxValue(s))
}

func GetMaxValue(s []int) int {
 max :=0
 for i:=0;i<len(s);i++{
  max = maxValue(s[i],max)
 }
 return max
}

func maxValue(a,b int) int {
 if a > b{
  return a
 }
 return b
}

执行go build --gcflags="-m -m" ./test.go，输出如下结果：

# command-line-arguments
./test.go:20:6: can inline maxValue with cost 8 as: func(int, int) int { if a > b { return a }; return b }
./test.go:12:6: cannot inline GetMaxValue: unhandled op FOR
./test.go:15:17: inlining call to maxValue func(int, int) int { if a > b { return a }; return b }
./test.go:7:6: cannot inline main: function too complex: cost 145 exceeds budget 80
./test.go:9:13: inlining call to fmt.Println func(...interface {}) (int, error) { var fmt..autotmp_3 int; fmt..autotmp_3 = <N>; var fmt..autotmp_4 error; fmt..autotmp_4 = <N>; fmt..autotmp_3, fmt..autotmp_4 = fmt.Fprintln(io.Writer(os.Stdout), fmt.a...); return fmt..autotmp_3, fmt..autotmp_4 }
./test.go:12:18: s does not escape
./test.go:9:25: GetMaxValue(s) escapes to heap:
./test.go:9:25:   flow: ~arg0 = &{storage for GetMaxValue(s)}:
./test.go:9:25:     from GetMaxValue(s) (spill) at ./test.go:9:25
./test.go:9:25:     from ~arg0 = <N> (assign-pair) at ./test.go:9:13
./test.go:9:25:   flow: {storage for []interface {} literal} = ~arg0:
./test.go:9:25:     from []interface {} literal (slice-literal-element) at ./test.go:9:13
./test.go:9:25:   flow: fmt.a = &{storage for []interface {} literal}:
./test.go:9:25:     from []interface {} literal (spill) at ./test.go:9:13
./test.go:9:25:     from fmt.a = []interface {} literal (assign) at ./test.go:9:13
./test.go:9:25:   flow: {heap} = *fmt.a:
./test.go:9:25:     from fmt.Fprintln(io.Writer(os.Stdout), fmt.a...) (call parameter) at ./test.go:9:13
./test.go:8:12: []int literal does not escape
./test.go:9:25: GetMaxValue(s) escapes to heap
./test.go:9:13: []interface {} literal does not escape
<autogenerated>:1: .this does not escape

编译器判断函数maxValue可以进行内联，在函数GetMaxValue中对maxValue的调用就是内联，但是函数GetMaxValue是不能内联的，原因是使用了FOR循环，与Go编译器优化规则有关，我们在下一节介绍。还对fmt.Println 进行了内联优化。后面几行都是逃逸分析，后面会专门写一篇文章来了解逃逸分析～。

Go编译器内联优化规则

我们在/src/cmd/compile/internal/gc/inl.go中看到内联优化相关的代码：

inlineMaxBudget       = 80

func (v *hairyVisitor) visit(n *Node) bool {
 if n == nil {
  return false
 }

 switch n.Op {
    .... //省略部分代码
    case OCLOSURE,
  OCALLPART,
  ORANGE,
  OFOR,
  OFORUNTIL,
  OSELECT,
  OTYPESW,
  OGO,
  ODEFER,
  ODCLTYPE, // can't print yet
  OBREAK,
  ORETJMP:
  v.reason = "unhandled op " + n.Op.String()
  return true
    .... //省略部分代码
  }
  return v.visit(n.Left) || v.visit(n.Right) ||
  v.visitList(n.List) || v.visitList(n.Rlist) ||
  v.visitList(n.Ninit) || v.visitList(n.Nbody)
}

从这里可以看出一个规则：

1. 闭包，select，for，defer，go关键字所开启的新goroutine等不会进行内联；

2. Go函数中超过80个节点的代码量就不再内联，根据解析的AST节点数量来做判断；

其实这部分规则还是很多的，代码量也是1300+，看仔细还是挺有难度的，这里只简单介绍一下一目了然的规则，在日后开发中有个概念就好，更详细的规则可在源码中自己发掘！

内联函数带来的问题

我们知道内联函数会直接把函数替换为函数的内容，这样就会引入一个问题，如果发生panic时，开发者需要知道panic的准确堆栈信息，获取源码文件以及行号，但是因为使用了内联函数，那么错误日志就打印在错误的地方，这就会产生误导性。Go开发者当然会考虑到这个问题，他是如何解决的呢？

Go在内部维持了一份内联函数的映射关系，会生成一个内联树，我们可以通过-gcflags="-d pctab=pctoinline"参数查看，看一个例子：

func main(){
 s := []int{90,100,24,18}
 Sum(s)
}

func Sum(s []int) int {
 sum :=0
 for i:=0;i<len(s);i++{
  sum = add(sum,s[i])
 }
 return sum
}

func add(x,y int) int{
 panic("panic")
 return x+y
}

运行go build -gcflags="-d pctab=pctoinline" ./test1.go：

-- inlining tree for "".Sum:
0 | -1 | "".add (/Users/go/src/asong.cloud/Golang_Dream/code_demo/inline/test1.go:11:12) pc=39
--

从结果我们可以看到在inlining tree中为.Sum和.add添加了映射关系。

总结

内联函数对于程序的提升是很重要的，函数调用是有开销的，比如：创建新的堆栈帧、保存和恢复寄存器等，所以内联函数的优化可以有效避免一些不必要的开销，你学会了吗？宝贝！

参考文章：https://medium.com/a-journey-with-go/go-inlining-strategy-limitation-6b6d7fc3b1be

文中代码已上传github：https://github.com/asong2020/Golang_Dream/tree/master/code_demo/inline

素质三连（分享、点赞、在看）都是笔者持续创作更多优质内容的动力！我是asong，我们下期见。

创建了一个Golang学习交流群，欢迎各位大佬们踊跃入群，我们一起学习交流。入群方式：关注公众号获取。更多学习资料请到公众号领取。

推荐往期文章：

• 学习channel设计：从入门到放弃

• 编程模式之Go如何实现装饰器

• Go语言中new和make你使用哪个来分配内存？

• 源码剖析panic与recover，看不懂你打我好了！

• 空结构体引发的大型打脸现场

• 面试官：你能聊聊string和[]byte的转换吗？

• 面试官：两个nil比较结果是什么？

• 面试官：你能用Go写段代码判断当前系统的存储方式吗?

• 赏析Singleflight设计