go语言buf go语言bug

Go 语言 channel 的阻塞问题

Hello，大家好，又见面了！上一遍我们将 channel 相关基础以及使用场景。这一篇，还需要再次进阶理解channel 阻塞问题。以下创建一个chan类型为int，cap 为3。

创新互联建站从2013年成立，是专业互联网技术服务公司，拥有项目网站制作、成都网站设计网站策划，项目实施与项目整合能力。我们以让每一个梦想脱颖而出为使命，1280元敖汉做网站,已为上家服务,为敖汉各地企业和个人服务,联系电话:028-86922220

channel 内部其实是一个环形buf数据结构 ，是一种滑动窗口机制，当make完后，就分配在 Heap 上。

上面，向 chan 发送一条“hello”数据：

如果 G1 发送数据超过指定cap时，会出现什么情况？

看下面实例：

以上会出现什么，chan 缓冲区允许大小为1，如果再往chan仍数据，满了就会被阻塞，那么是如何实现阻塞的呢？当 chan 满时，会进入 gopark，此时 G1 进入一个 waiting 状态，然后会创建一个 sudog 对象，其实就sendq队列，把 200放进去。等 buf 不满的时候，再唤醒放入buf里面。

通过如下源码，你会更加清晰：

上面，从 chan 获取数据：

Go 语言核心思想：“Do not communicate by sharing memory; instead, share memory by communicating.” 你可以看看这本书名叫：Effective Go

如果接收者，接收一个空对象，也会发生什么情况？

代码示例 ：

也会报错如下：

上面，从 chan 取出数据，可是没有数据了。此时，它会把 接收者 G2 阻塞掉，也是和G1发送者一样，也会执行 gopark 将状态改为 waiting，不一样的点就是。

正常情况下，接收者G2作为取出数据是去 buf 读取数据的，但现在，buf 为空了，此时，接收者G2会将sudog导出来，因为现在G2已经被阻塞了嘛，会把G2给G，然后将 t := -ch 中变量 t 是在栈上的地址，放进去 elem ，也就是说，只存它的地址指针在sudog里面。

最后， ch - 200 当G1往 chan 添加200这个数据，正常情况是将数据添加到buf里面，然后唤醒 G2 是吧，而现在是将 G1 的添加200数据直接干到刚才G2阻塞的t这里变量里面。

你会认为，这样真的可以吗？想一想，G2 本来就是已经阻塞了，然后我们直接这么干肯定没有什么毛病，而且效率提高了，不需要再次放入buf再取出，这个过程也是需要时间。不然，不得往chan添加数据需要加锁、拷贝、解锁一序列操作，那肯定就慢了，我想Go语言是为了高效及内存使用率的考虑这样设计的。（注意，一般都是在runtime里面完成，不然会出现象安全问题。）

总结 ：

chan 类型的特点：chan 如果为空，receiver 接收数据的时候就会阻塞等待，直到 chan 被关闭或者有新的数据到来。有这种个机制，就可以实现 wait/notify 的设计模式。

相关面试题：

go语言string之Buffer与Builder

操作字符串离不开字符串的拼接，但是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类型返回了回来，去掉了申请空间的操作。

Go 语言自我提升 (三次握手 - 四次挥手 - TCP状态图 - udp - 网络文件传输)

三次握手：

1. 主动发起连接请求端（客户端），发送 SYN 标志位，携带数据包、包号

2. 被动接收连接请求端（服务器），接收 SYN，回复 ACK，携带应答序列号。同时，发送SYN标志位，携带数据包、包号

3. 主动发起连接请求端（客户端），接收SYN 标志位，回复 ACK。

被动端（服务器）接收 ACK —— 标志着 三次握手建立完成（ Accept()/Dial() 返回 ）

四次挥手：

1. 主动请求断开连接端（客户端）， 发送 FIN标志，携带数据包

2. 被动接受断开连接端（服务器）， 发送 ACK标志，携带应答序列号。 —— 半关闭完成。

3. 被动接受断开连接端（服务器）， 发送 FIN标志，携带数据包

4. 主动请求断开连接端（客户端）， 发送 最后一个 ACK标志，携带应答序列号。—— 发送完成，客户端不会直接退出，等 2MSL时长。

等 2MSL待目的：确保服务器 收到最后一个ACK

滑动窗口：

通知对端本地存储数据的 缓冲区容量。—— write 函数在对端 缓冲区满时，有可能阻塞。

TCP状态转换：

1. 主动发起连接请求端：

CLOSED —— 发送SYN —— SYN_SENT(了解) —— 接收ACK、SYN，回发 ACK —— ESTABLISHED (数据通信)

2. 主动关闭连接请求端：

ESTABLISHED —— 发送FIN —— FIN_WAIT_1 —— 接收ACK —— FIN_WAIT_2 (半关闭、主动端)

—— 接收FIN、回复ACK —— TIME_WAIT (主动端) —— 等 2MSL 时长 —— CLOSED

3. 被动建立连接请求端：

CLOSED —— LISTEN —— 接收SYN、发送ACK、SYN —— SYN_RCVD —— 接收 ACK —— ESTABLISHED (数据通信)

4. 被动断开连接请求端：

ESTABLISHED —— 接收 FIN、发送 ACK —— CLOSE_WAIT —— 发送 FIN —— LAST_ACK —— 接收ACK —— CLOSED

windows下查看TCP状态转换：

netstat -an | findstr  端口号

Linux下查看TCP状态转换：

netstat -an | grep  端口号

TCP和UDP对比: 

TCP: 面向连接的可靠的数据包传递。 针对不稳定的 网络层，完全弥补。ACK

UDP：无连接不可靠的报文传输。 针对不稳定的 网络层，完全不弥补。还原网络真实状态。

优点                                                             缺点

TCP： 可靠、顺序、稳定                                      系统资源消耗大，程序实现繁复、速度慢

UDP：系统资源消耗小，程序实现简单、速度快                          不可靠、无序、不稳定

使用场景：

TCP：大文件、可靠数据传输。 对数据的 稳定性、准确性、一致性要求较高的场合。

UDP：应用于对数据时效性要求较高的场合。 网络直播、电话会议、视频直播、网络游戏。

UDP-CS-Server实现流程：

1.  创建 udp地址结构 ResolveUDPAddr(“协议”， “IP：port”) —— udpAddr 本质 struct{IP、port}

2.  创建用于 数据通信的 socket ListenUDP(“协议”, udpAddr ) —— udpConn (socket)

3.  从客户端读取数据，获取对端的地址 udpConn.ReadFromUDP() —— 返回：n，clientAddr， err

4.  发送数据包给 客户端 udpConn.WriteToUDP("数据"， clientAddr)

UDP-CS-Client实现流程：

1.  创建用于通信的 socket。 net.Dial("udp", "服务器IP：port") —— udpConn (socket)

2.  以后流程参见 TCP客户端实现源码。

UDPserver默认就支持并发！

------------------------------------

命令行参数： 在main函数启动时，向整个程序传参。 【重点】

语法： go run xxx.go   argv1 argv2  argv3  argv4 。。。

xxx.exe:  第 0 个参数。

argv1 ：第 1 个参数。

argv2 ：第 2 个参数。

argv3 ：第 3 个参数。

argv4 ：第 4 个参数。

使用： list := os.Args  提取所有命令行参数。

获取文件属性函数：

os.stat(文件访问绝对路径) —— fileInfo 接口

fileInfo 包含 两个接口。

Name() 获取文件名。 不带访问路径

Size() 获取文件大小。

网络文件传输 —— 发送端（客户端）

1.  获取命令行参数，得到文件名（带路径）filePath list := os.Args

2.  使用 os.stat() 获取 文件名（不带路径）fileName

3.  创建 用于数据传输的 socket  net.Dial("tcp"， “服务器IP+port”) —— conn

4.  发送文件名(不带路径)  给接收端， conn.write()

5.  读取 接收端回发“ok”，判断无误。封装函数 sendFile(filePath, conn) 发送文件内容

6.  实现 sendFile(filePath,  conn)

1) 只读打开文件 os.Open(filePath)

for {

2) 从文件中读数据  f.Read(buf)

3) 将读到的数据写到socket中  conn.write(buf[:n])

4）判断读取文件的 结尾。 io.EOF. 跳出循环

}

网络文件传输 —— 接收端（服务器）

1. 创建用于监听的 socket net.Listen() —— listener

2. 借助listener 创建用于 通信的 socket listener.Accpet()  —— conn

3. 读取 conn.read() 发送端的 文件名， 保存至本地。

4. 回发 “ok”应答 发送端。

5. 封装函数，接收文件内容 recvFile(文件路径)

1) f = os.Create(带有路径的文件名)

for {

2）从 socket中读取发送端发送的 文件内容 。 conn.read(buf)

3)  将读到的数据 保存至本地文件 f.Write(buf[:n])

4)  判断 读取conn 结束， 代表文件传输完成。 n == 0  break

}

标题名称：go语言buf go语言bug
分享URL：http://6mz.cn/article/ddgpsce.html