GO是编译性语言，所以函数的顺序是无关紧要的，为了方便阅读，建议入口函数 main 写在最前面，其余函数按照功能需要进行排列
GO的函数 不支持嵌套，重载和默认参数
GO的函数 支持 无需声明变量，可变长度，多返回值，匿名，闭包等
GO的函数用 func 来声明，且左大括号 { 不能另起一行
一个简单的示例：
输出为：
参数：可以传0个或多个值来供自己用
返回：通过用 return 来进行返回
输出为：
上面就是一个典型的多参数传递与多返回值
对例子的说明：
按值传递：是对某个变量进行复制，不能更改原变量的值
引用传递：相当于按指针传递，可以同时改变原来的值，并且消耗的内存会更少，只有4或8个字节的消耗
在上例中，返回值 (d int, e int, f int) { 是进行了命名，如果不想命名可以写成 (int,int,int){ ,返回的结果都是一样的，但要注意:
当返回了多个值，我们某些变量不想要，或实际用不到，我们可以使用 _ 来补位，例如上例的返回我们可以写成 d,_,f := test(a,b,c) ，我们不想要中间的返回值，可以以这种形式来舍弃掉
在参数后面以 变量 ... type 这种形式的，我们就要以判断出这是一个可变长度的参数
输出为：
在上例中， strs ...string 中， strs 的实际值是b,c,d,e,这就是一个最简单的传递可变长度的参数的例子，更多一些演变的形式，都非常类似
在GO中 defer 关键字非常重要，相当于面相对像中的析构函数，也就是在某个函数执行完成后，GO会自动这个；
如果在多层循环中函数里，都定义了 defer ,那么它的执行顺序是先进后出；
当某个函数出现严重错误时， defer 也会被调用
输出为
这是一个最简单的测试了，当然还有更复杂的调用，比如调试程序时，判断是哪个函数出了问题，完全可以根据 defer 打印出来的内容来进行判断，非常快速，这种留给你们去实现
一个函数在函数体内自己调用自己我们称之为递归函数，在做递归调用时，经常会将内存给占满，这是非常要注意的，常用的比如，快速排序就是用的递归调用
本篇重点介绍了GO函数(func)的声明与使用，下一篇将介绍GO的结构 struct
简单来说， SetMaxHeap 提供了一种可以设置固定触发阈值的 GC （Garbage Collection垃圾回收）方式
官方源码链接 https://go-review.googlesource.com/c/go/+/227767/3
大量临时对象分配导致的 GC 触发频率过高， GC 后实际存活的对象较少，
或者机器内存较充足，希望使用剩余内存，降低 GC 频率的场景
GC 会 STW （ Stop The World ），对于时延敏感场景，在一个周期内连续触发两轮 GC ，那么 STW 和 GC 占用的 CPU 资源都会造成很大的影响， SetMaxHeap 并不一定是完美的，在某些场景下做了些权衡，官方也在进行相关的实验，当前方案仍没有合入主版本。
先看下如果没有 SetMaxHeap ，对于如上所述的场景的解决方案
这里简单说下 GC 的几个值的含义，可通过 GODEBUG=gctrace=1 获得如下数据
这里只关注 128->132->67 MB 135 MB goal ，
分别为 GC开始时内存使用量 ->GC标记完成时内存使用量 ->GC标记完成时的存活内存量 本轮GC标记完成时的 预期 内存使用量（上一轮 GC 完成时确定）
引用 GC peace设计文档 中的一张图来说明
对应关系如下：
简单说下 GC pacing （信用机制）
GC pacing 有两个目标，
那么当一轮 GC 完成时，如何只根据本轮 GC 存活量去实现这两个小目标呢？
这里实际是根据当前的一些数据或状态去 预估 “未来”，所有会存在些误差
首先确定 gc Goalgoal = memstats.heap_marked + memstats.heap_marked*uint64(gcpercent)/100
heap_marked 为本轮 GC 存活量， gcpercent 默认为 100 ，可以通过环境变量 GOGC=100 或者 debug.SetGCPercent(100) 来设置
那么默认情况下 goal = 2 * heap_marked
gc_trigger 是与 goal 相关的一个值（ gc_trigger 大约为 goal 的 90% 左右），每轮 GC 标记完成时，会根据 |Ha-Hg| 和实际使用的 cpu 资源 动态调整 gc_trigger 与 goal 的差值
goal 与 gc_trigger 的差值即为，为 GC 期间分配的对象所预留的空间
GC pacing 还会预估下一轮 GC 发生时，需要扫描对象对象的总量，进而换算为下一轮 GC 所需的工作量，进而计算出 mark assist 的值
本轮 GC 触发（ gc_trigger ），到本轮的 goal 期间，需要尽力完成 GC mark 标记操作，所以当 GC 期间，某个 goroutine 分配大量内存时，就会被拉去做 mark assist 工作，先进行 GC mark 标记赚取足够的信用值后，才能分配对应大小的对象
根据本轮 GC 存活的内存量（ heap_marked ）和下一轮 GC 触发的阈值（ gc_trigger ）计算 sweep assist 的值，本轮 GC 完成，到下一轮 GC 触发（ gc_trigger ）时，需要尽力完成 sweep 清扫操作
预估下一轮 GC 所需的工作量的方式如下：
继续分析文章开头的问题，如何充分利用剩余内存，降低 GC 频率和 GC 对 CPU 的资源消耗
如上图可以看出， GC 后，存活的对象为 2GB 左右，如果将 gcpercent 设置为 400 ，那么就可以将下一轮 GC 触发阈值提升到 10GB 左右
前面一轮看起来很好，提升了 GC 触发的阈值到 10GB ，但是如果某一轮 GC 后的存活对象到达 2.5GB 的时候，那么下一轮 GC 触发的阈值，将会超过内存阈值，造成 OOM （ Out of Memory ），进而导致程序崩溃。
可以通过 GOGC=off 或者 debug.SetGCPercent(-1) 来关闭 GC
可以通过进程外监控内存使用状态，使用信号触发的方式通知程序，或 ReadMemStats 、或 linkname runtime.heapRetained 等方式进行堆内存使用的监测
可以通过调用 runtime.GC() 或者 debug.FreeOSMemory() 来手动进行 GC 。
这里还需要说几个事情来解释这个方案所存在的问题
通过 GOGC=off 或者 debug.SetGCPercent(-1) 是如何关闭 GC 的？
gc 4 @1.006s 0%: 0.033+5.6+0.024 ms clock, 0.27+4.4/11/25+0.19 ms cpu, 428->428->16 MB, 17592186044415 MB goal, 8 P (forced)
通过 GC trace 可以看出，上面所说的 goal 变成了一个很诡异的值 17592186044415
实际上关闭 GC 后， Go 会将 goal 设置为一个极大值 ^uint64(0) ，那么对应的 GC 触发阈值也被调成了一个极大值，这种处理方式看起来也没什么问题，将阈值调大，预期永远不会再触发 GC
那么如果在关闭 GC 的情况下，手动调用 runtime.GC() 会导致什么呢？
由于 goal 和 gc_trigger 被设置成了极大值， mark assist 和 sweep assist 也会按照这个错误的值去计算，导致工作量预估错误，这一点可以从 trace 中进行证明
可以看到很诡异的 trace 图，这里不做深究，该方案与 GC pacing 信用机制不兼容
记住，不要在关闭 GC 的情况下手动触发 GC ，至少在当前 Go1.14 版本中仍存在这个问题
SetMaxHeap 的实现原理，简单来说是强行控制了 goal 的值
注： SetMaxHeap ，本质上是一个软限制，并不能解决 极端场景 下的 OOM ，可以配合内存监控和 debug.FreeOSMemory() 使用
SetMaxHeap 控制的是堆内存大小， Go 中除了堆内存还分配了如下内存，所以实际使用过程中，与实际硬件内存阈值之间需要留有一部分余量。
对于文章开始所述问题，使用 SetMaxHeap 后，预期的 GC 过程大概是这个样子
简单用法1
该方法简单粗暴，直接将 goal 设置为了固定值
注：通过上文所讲，触发 GC 实际上是 gc_trigger ，所以当阈值设置为 12GB 时，会提前一点触发 GC ，这里为了描述方便，近似认为 gc_trigger=goal
简单用法2
当不关闭 GC 时， SetMaxHeap 的逻辑是， goal 仍按照 gcpercent 进行计算，当 goal 小于 SetMaxHeap 阈值时不进行处理；当 goal 大于 SetMaxHeap 阈值时，将 goal 限制为 SetMaxHeap 阈值
注：通过上文所讲，触发 GC 实际上是 gc_trigger ，所以当阈值设置为 12GB 时，会提前一点触发 GC ，这里为了描述方便，近似认为 gc_trigger=goal
切换到 go1.14 分支，作者选择了 git checkout go1.14.5
选择官方提供的 cherry-pick 方式(可能需要梯子，文件改动不多，我后面会列出具体改动)
git fetch "https://go.googlesource.com/go" refs/changes/67/227767/3 &&git cherry-pick FETCH_HEAD
需要重新编译Go源码
注意点：
下面源码中的官方注释说的比较清楚，在一些关键位置加入了中文注释
入参bytes为要设置的阈值
notify 简单理解为 GC 的策略 发生变化时会向 channel 发送通知，后续源码可以看出“策略”具体指哪些内容
返回值为本次设置之前的 MaxHeap 值
$GOROOT/src/runtime/debug/garbage.go
$GOROOT/src/runtime/mgc.go
注：作者尽量用通俗易懂的语言去解释 Go 的一些机制和 SetMaxHeap 功能，可能有些描述与实现细节不完全一致，如有错误还请指出
在本节中，您将添加通用函数调用的修改版本，进行小的更改以简化调用代码。您将删除在这种情况下不需要的类型参数。
当 Go 编译器可以推断您要使用的类型时，您可以在调用代码中省略类型参数。编译器从函数参数的类型推断类型参数。
请注意，这并不总是可能的。例如，如果您需要调用没有参数的泛型函数，则需要在函数调用中包含类型参数。
在 main.go 中，在您已有的代码下方，粘贴以下代码。
在此代码中：
（1）调用泛型函数，省略类型参数。
从包含 main.go 的目录中的命令行，运行代码。
接下来，您将通过将整数和浮点数的并集捕获到您可以重用的类型约束（例如从其他代码中）来进一步简化函数。
正如您将在本节中看到的，约束接口也可以引用特定类型。
1、编写代码
在此代码中：
b.在您已有的函数下方，粘贴以下通用 SumNumbers函数。
在此代码中：
c.在 main.go 中，在您已有的代码下方，粘贴以下代码。
在此代码中：
（1）调用SumNumbers打印每个map的总和。
与上一节一样，在调用泛型函数时省略了类型参数（方括号中的类型名称）。Go 编译器可以从其他参数推断类型参数。
从包含 main.go 的目录中的命令行，运行代码。
做得很好！您刚刚学习了 Go 中的泛型。
