sync.Map是1.9才推荐的并发安全的map，除了互斥量以外，还运用了原子操作，所以在这之前，有必要了解下 Go语言——原子操作
专注于为中小企业提供成都做网站、成都网站建设、成都外贸网站建设服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业樊城免费做网站提供优质的服务。我们立足成都，凝聚了一批互联网行业人才，有力地推动了1000多家企业的稳健成长，帮助中小企业通过网站建设实现规模扩充和转变。
go1.10\src\sync\map.go
entry分为三种情况：
从read中读取key，如果key存在就tryStore。
注意这里开始需要加锁，因为需要操作dirty。
条目在read中，首先取消标记，然后将条目保存到dirty里。（因为标记的数据不在dirty里）
最后原子保存value到条目里面，这里注意read和dirty都有条目。
总结一下Store：
这里可以看到dirty保存了数据的修改，除非可以直接原子更新read，继续保持read clean。
有了之前的经验，可以猜测下load流程：
与猜测的 区别 ：
由于数据保存两份，所以删除考虑：
先看第二种情况。加锁直接删除dirty数据。思考下貌似没什么问题，本身就是脏数据。
第一种和第三种情况唯一的区别就是条目是否被标记。标记代表删除，所以直接返回。否则CAS操作置为nil。这里总感觉少点什么，因为条目其实还是存在的，虽然指针nil。
看了一圈貌似没找到标记的逻辑，因为删除只是将他变成nil。
之前以为这个逻辑就是简单的将为标记的条目拷贝给dirty，现在看来大有文章。
p == nil，说明条目已经被delete了，CAS将他置为标记删除。然后这个条目就不会保存在dirty里面。
这里其实就跟miss逻辑串起来了，因为miss达到阈值之后，dirty会全量变成read，也就是说标记删除在这一步最终删除。这个还是很巧妙的。
真正的删除逻辑：
很绕。。。。
操作字符串离不开字符串的拼接，但是Go中string是只读类型，大量字符串的拼接会造成性能问题。
拼接字符串，无外乎四种方式，采用“+”，“fmt.Sprintf()”,"bytes.Buffer","strings.Builder"
上面我们创建10万字符串拼接的测试，可以发现"bytes.Buffer","strings.Builder"的性能最好，约是“+”的1000倍级别。
这是由于string是不可修改的，所以在使用“+”进行拼接字符串，每次都会产生申请空间，拼接，复制等操作，数据量大的情况下非常消耗资源和性能。而采用Buffer等方式，都是预先计算拼接字符串数组的总长度（如果可以知道长度），申请空间，底层是slice数组，可以以append的形式向后进行追加。最后在转换为字符串。这申请了不断申请空间的操作，也减少了空间的使用和拷贝的次数，自然性能也高不少。
bytes.buffer是一个缓冲byte类型的缓冲器存放着都是byte
是一个变长的 buffer，具有 Read 和Write 方法。 Buffer 的 零值 是一个 空的 buffer，但是可以使用，底层就是一个 []byte， 字节切片。
向Buffer中写数据，可以看出Buffer中有个Grow函数用于对切片进行扩容。
从Buffer中读取数据
strings.Builder的方法和bytes.Buffer的方法的命名几乎一致。
但实现并不一致，Builder的Write方法直接将字符拼接slice数组后。
其没有提供read方法，但提供了strings.Reader方式
Reader 结构:
Buffer:
Builder:
可以看出Buffer和Builder底层都是采用[]byte数组进行装载数据。
先来说说Buffer:
创建好Buffer是一个empty的，off 用于指向读写的尾部。
在写的时候，先判断当前写入字符串长度是否大于Buffer的容量，如果大于就调用grow进行扩容，扩容申请的长度为当前写入字符串的长度。如果当前写入字符串长度小于最小字节长度64，直接创建64长度的[]byte数组。如果申请的长度小于二分之一总容量减去当前字符总长度，说明存在很大一部分被使用但已读，可以将未读的数据滑动到数组头。如果容量不足，扩展2*c + n 。
其String()方法就是将字节数组强转为string
Builder是如何实现的。
Builder采用append的方式向字节数组后添加字符串。
从上面可以看出，[]byte的内存大小也是以倍数进行申请的，初始大小为 0，第一次为大于当前申请的最大 2 的指数，不够进行翻倍.
可以看出如果旧容量小于1024进行翻倍，否则扩展四分之一。（2048 byte 后，申请策略的调整）。
其次String()方法与Buffer的string方法也有明显区别。Buffer的string是一种强转，我们知道在强转的时候是需要进行申请空间，并拷贝的。而Builder只是指针的转换。
这里我们解析一下 *(*string)(unsafe.Pointer(b.buf)) 这个语句的意思。
先来了解下unsafe.Pointer 的用法。
也就是说，unsafe.Pointer 可以转换为任意类型，那么意味着，通过unsafe.Pointer媒介，程序绕过类型系统，进行地址转换而不是拷贝。
即*A = Pointer = *B
就像上面例子一样，将字节数组转为unsafe.Pointer类型，再转为string类型，s和b中内容一样，修改b,s也变了，说明b和s是同一个地址。但是对s重新赋值后，意味着s的地址指向了“WORLD”,它们所使用的内存空间不同了，所以s改变后，b并不会改变。
所以他们的区别就在于 bytes.Buffer 是重新申请了一块空间，存放生成的string变量， 而strings.Builder直接将底层的[]byte转换成了string类型返回了回来，去掉了申请空间的操作。
当读取91.2 MB文件时，read1耗时43ms，read2耗时99ms。
查看源码：
读取文件主要是通过 Read(p []byte) (n int, err error) ：
官方文档中关于该接口方法的说明：
结论：
ReadFile(filename string)方法之所以速度快的原因就是先计算出file文件的size，在初始化对应size大小的buff，传入ReadRead(p []byte) 来读取字节流
package main
import "fmt"
func main() {
var a, b, c int
fmt.Scanf("%d%d%d", a, b, c)
fmt.Println(a + b + c)
}
希望采纳！
Go 原生的 pkg 中有一些核心的 interface ，其中 io.Reader/Writer 是比较常用的接口。很多原生的结构都围绕这个系列的接口展开，在实际的开发过程中，你会发现通过这个接口可以在多种不同的io类型之间进行过渡和转化。本文结合实际场景来总结一番。
围绕 io.Reader/Writer ，有几个常用的实现：
这些实现对于初学者来说其实比较难去记忆，在遇到实际问题的时候更是一脸蒙圈，不知如何是好。下面用实际的场景来举例
encoding/base64 包中：
这个用来做 base64 编码，但是仔细观察发现，它需要一个io.Writer作为输出目标，并用返回的 WriteCloser 的Write方法将结果写入目标，下面是Go官方文档的例子
这个例子是将结果写入到 Stdout ，如果我们希望得到一个字符串呢？观察上面的图，不然发现可以用bytes.Buffer作为目标 io.Writer ：
这种场景经常用在基于字节的协议上，比如有一个具有固定长度的结构：
通过一个 []byte 来反序列化得到这个 Protocol ，一种思路是遍历这个 []byte ，然后逐一赋值。其实在 encoding/binary 包中有个方便的方法：
这个方法从一个 io.Reader 中读取字节，并已 order 指定的端模式，来给填充 data （data需要是fixed-sized的结构或者类型）。要用到这个方法首先要有一个 io.Reader ，从上面的图中不难发现，我们可以这么写：
换句话说，我们将一个 []byte 转成了一个 io.Reader 。
反过来，我们需要将 Protocol 序列化得到 []byte ，使用 encoding/binary 包中有个对应的 Write 方法：
通过将 []byte 转成一个 io.Writer 即可：
比如对于常见的基于文本行的 HTTP 协议的读取，我们需要将一个流按照行来读取。本质上，我们需要一个基于缓冲的读写机制（读一些到缓冲，然后遍历缓冲中我们关心的字节或字符）。在Go中有一个 bufio 的包可以实现带缓冲的读写：
这个ReadString方法从 io.Reader 中读取字符串，直到 delim ，就返回 delim 和之前的字符串。如果将 delim 设置为 \n ，相当于按行来读取了：
等价于
实现一个最简单的类似spark的流式处理流程
包含map和filter
数据
map函数
fliter函数
所有数据+1 过滤出偶数 过滤出大于5的数
