没有任何的宣传（上论坛社区贴链接什么的），居然有人fork或star了我的github项目。没什么特别的意思，就是有点意外的高兴，虽然人数不多
-
没有任何的宣传（上论坛社区贴链接什么的），居然有人fork或star了我的github项目。没什么特别的意思，就是有点意外的高兴，虽然人数不多
-
Kafka日志传输网络延迟导致的服务假死。
原因：zap框架挂载了kafka日志传输，是同步模式。由于网络延迟，kafka日志不能及时完成传输，导致业务代码产生延迟。
场景: 同事首先发现问题是在某个TCP写的位置，本地正常，初步怀疑是TCP写延迟，但是并未明确
排查过程:
TCP读顺利无延迟,写最终能被接收，初步排除网络连接方面问题
- pprof, 火焰图heap,cpufile均无明显异常，goroutine没有明显增高(实际有异常增多，但是当时用户量不高，没有发现，只是以为用户量引起的goroutine变化)
- 前后打日志（本地正常，所以无法对服务器做断点测试），标准输出或文本输出都正常,但是在write之后的日志出来的慢
- 疑惑…仍然怀疑TCP问题，但是稍加思考后还是否定了
- 只有日志模块（当时基本没有怀疑日志），没有查看ELK日志，因为一开始不知道使用了kafka日志传输
- 查看日志模块代码，有挂载kafka日志。查看配置，生产的连接写成了测试的连接地址，服务器在国外。
解决方案: 修改连接，顺便将kafka的传输方式改成异步。
Kafka日志传输造成的服务“停止”
原因：kafka服务没有开启
场景：客户端大量接收不到回包，日志稀少(但是阅读代码发现服务在大部分情况下确实不打日志)。但是过一段时间（半小时到1小时），几乎所有用户连接不上，telnet通过。
排查过程：
1. 查询逻辑，发现没有明显会造成阻塞的情况2. 在相关消息入口增加日志，重启服务后发现过一段时间后重现，日志不打印3. 怀疑日志问题，查看日志模块4. 发现kafka挂载，查看kafka异步代码，阻塞通道满总结: 这两次其实通过异常goroutine的排场是可以直接从pprof中定位到问题所在的，但是由于对他人项目的不熟，加上一眼看上去没有问题的心理，没有充分使用到pprof分析，导致后来依赖阅读代码的来排查。
连接指针未释放造成的最终内存持续累积
原因: 连接未释放，早期read方法有点奇葩，好像是先分配一个指定大小的 byte 数组再去读数据的（具体不记得了）
场景: 内存持续缓慢增长，heap数量只增不减
排查过程:
1. 通过pprof生成heap文件，图形化显示下查询到内存占用最多的地方累积在read方法。2. read的奇葩读法，但是read每次分配好像是4M,,依照当时的用户量以及15超时清理分钟，也不应该达到那么大累积量3. 继续查看pprof文件，发现有大量的Client连接，考虑到15分钟断开可能有所累积，但是结合web图的引导，确实是连接下的read积累了最多的内存4. 怀疑连接没有正确释放造成(这里是无法直接得出哪块代码有问题的)5. 查询代码，发现客户端和用户管理混乱，让其自己按照这个方向排查代码6. 得出问题，是在服务器异常断开后，没有EOF，新连接替代了旧连接，然后在用户管理下的超市清理处理不到这部分链接，被一直保存到connMap中，其read goroutine 也无法断开
客户端允许body过长造成的内存突增
原因:socket分包的时候通过协议header的bodyLen分配内存，客户端由于某些错误传递了很大的bodyLen使得内存突增
场景:监控服务报警，内存突增。
排查过程:
1. 由于有上述的经验，首先怀疑是read时候分配内存堆积造成的，实际上确实如此，但有所不同的是当前是徒增，而且没有出现指针不释放的问题2. 直接查看源码，发现bodyLen的判断是小于MaxInt323. 直接依靠经验判断是bodyLen传入过大(而且基于最近出现了客户端连接异常的情况，发数据无响应等)。
客户端总是因心跳超时而被清理(早期设置心跳超时是30秒，没有设置readTimeout而是服务器根据心跳时间判断清理)
原因: mars框架对相同数据发送的处理
排查过程:
1. debug模式下查看心跳日志，日志显示心跳在一段时间后(每五秒)会停止，客户端怀疑是服务端业务处理延迟。2. 通过tcpdum抓包，明确服务端业务处理没有问题3. 怀疑是tcp纳格算法造成的小数据包延迟4. 设置了TCPNODELAY依然会出现5. 敦促客户端自查源码，发现mars框架相同的数据传送多少次之后就不再传送
1. 服务端的代码框架是自己开发的，所以流程十分清晰，日志齐全，排查定位问题简单2. 设计TCP的知识略有疑惑，但所幸通过baidu能及时解决3. 当时和客户端商议提出一起写一份属于自己公司的通用框架模版，结果自己花费月余时间收集整理，客户端却直套了第三方，只是做业务处理上的框架，导致开发过程中不断要兼容客户端的处理方式，十分痛苦。但是也正是因为是自己开发的框架，在变更处理逻辑的时候十分顺畅。4. 日志是很重要的，尽管有pprof可以排查问题，但是很多时候自己还是忽略了pprof的某些信息导致没有排查到问题，这样清晰的日志也可以很快帮忙定位问题。 1 | gc # @#s #%: #+#+# ms clock, #+#/#/#+# ms cpu, #->#-># MB, # MB goal, # P |
gc#：GC 执行次数的编号，每次叠加。@#s：自程序启动后到当前的具体秒数。#%：自程序启动以来在GC中花费的时间百分比。#+...+#：GC 的标记工作共使用的 CPU 时间占总 CPU 时间的百分比。#->#-># MB：分别表示 GC 启动时, GC 结束时, GC 活动时的堆大小.#MB goal：下一次触发 GC 的内存占用阈值。#P：当前使用的处理器 P 的数量。schedtrace=X 参数可以使运行时在每 X 毫秒发出一行调度器的摘要信息到标准 err 输出中。输出:
sched：每一行都代表调度器的调试信息，后面提示的毫秒数表示启动到现在的运行时间，输出的时间间隔受
schedtrace的值影响。gomaxprocs：当前的 CPU 核心数（GOMAXPROCS 的当前值）。
idleprocs：空闲的处理器数量，后面的数字表示当前的空闲数量。
threads：OS 线程数量，后面的数字表示当前正在运行的线程数量。
spinningthreads：自旋状态的 OS 线程数量。
idlethreads：空闲的线程数量。
runqueue：全局队列中中的 Goroutine 数量，而后面的 [0 0 1 1] 则分别代表这 4 个 P 的本地队列正在运行的 Goroutine 数量。
schedtrace=X 和 scheddetail=1 可以使运行时在每 X 毫秒发出一次详细的多行信息，信息内容主要包括调度程序、处理器、OS 线程 和 Goroutine 的状态
- raft基本原理演示请参考 http://thesecretlivesofdata.com/raft/
- go语言的raft实现 https://github.com/goraft/raft, 但是该项目早已不再维护，原作者将raft融入到etcd和influxdb(现在貌似不是了)里了，这里摘出etcd的raft实现进行研究
1 | // Copyright 2015 The etcd Authors |
1 | package main |
1 | package main |
编译成库文件
1 | go build -buildmode=plugin -o print.so p1.go |
终端输入编译后的文件路径，获取终端的输出
主要是 INFORMATION_SCHEMA 库里的表
1 | -- 包含事务正在等待的锁的信息 |
PERFORMANCE_SCHEMA 中的表(*_INSTANCES)
所有的*_INSTANCES表都包含 NAME和OBJECT_INSTANCE_BEGIN字段，这两个字段分别代表实例的名称和对象检测时的内存地址
COND_INSTANCES: 表包含等待条件列表，这些条件是在服务器启动后生成的。条件是指使一个线程等待其他线程的方式方法。
FILE_INSTANCES: 表包含性能架构可见的文件列表。当服务器首次打开文件的时候就将文件名插入该表，并且在文件从磁盘删除之前都会保存在该表之中。目前（…）打开文件会有一个正的 OPEN_COUNT计数。Number字段保存当前使用该文件的文件句柄数量。
MUTEX_INSTANCES: 表包含性能架构可见的互斥列表。互斥记录中 LOCKED_BY_THREAD_IS 的值为 NOT NULL 部分是当前锁定的互斥。
RWLOCK_INSTANCE: 表包含所有读/写锁实例的列表。WRITE_LOCKED_BY_THREAD_IS 字段代表持有锁的线程ID。READ_LOCKED_BYCOUNT字段代表当前在实例上获取了多少读锁。
EVENTS_WAITS_*： 系列表包含每个线程等待的事件的信息。
*SUMMARY*: 表包含被终止事件的聚合信息。
1 | -- 查看变量 |
如果一个 TCP 连接的一端启用了 Nagle‘s Algorithm，而另一端启用了 TCP Delayed
Ack，而发送的数据包又比较小，则可能会出现这样的情况：发送端在等 待接收端对上
一个packet 的 Ack 才发送当前的 packet，而接收端则正好延迟了 此 Ack 的发送，那么
这个正要被发送的 packet 就会同样被延迟。当然 Delayed Ack 是有个超时机制的，而默
认的超时正好就是40ms。
tcp协议规定在接受到数据段时需要向对方发送一个确认,但如果只是单纯的发送一个确
认,代价会比较高(20字节的ip首部,20字节的tcp首部),最好能附带响应数据一起发送给
对 方.所以tcp在何时发送ack给对方有以下规定:
1) 当有响应数据要发送时,ack会随响数据立即发送给对方.
2) 如果没有响应数据,ack的发 送将会有一个延迟,以等待看是否有响应数据可以一起发送 ,这称是”Delayed Ack”.但这个延迟最多不会超过500ms,一般为200ms.如果在200ms内有数据要发送,那么ack会随数据一起立即发送给对方.注意这里的延迟200ms,不是指的从接受到对方数据到发送ack的最长等待时间差.而是指的内核启动的一个定时器,它每隔200ms就查看下是否有ack要发送.例如:假设定时器在0ms时启动,对方的数据段在185ms时到达,那么ack最迟会在200ms时发送,而不是385ms时发送.
3) 如果在等待发送ack期间,对方的第二个数据段又到达了,这时要立即发送ack.但是如果对方的三个数据段相继 到达,那么第二个数据段到达时ack立即发送,但第三个数据段到达时是否立即发送,则取决于上面两条.
当tcp协议用来传输小的数据段时代码是很高的,并且如果传输是在广域网上,那可能就会引起网络拥塞.Nagle算法就是用来解决这个问题.该算法要求一个TCP连接上最多只能有一个未被确认(未收到Ack确认)的未完成的小分组，在该分组的确认到达之前不能发送其他的小分组。相反TCP收集这些少量的分组，并在确认到来时以一 个分组的方式发出去.Host Requirements RFC声明TCP必须实现Nagle算法，但必须为应用提供一种方法来关闭该算法在某个连接上执行。
纳格算法是合并(coalescing)一定数量的输出资料后一次送出。特别的是，只要有已送出的封包尚未确认，传送者会持续缓冲封包，直到累积一定数量的资料才送出。
算法如下如下：
1 | if 有新资料要传送 |
为什么要同时介绍这两个知识呢？因为这两个技术同时使用的话会出现问题，下面来看一下问题的出现场景:
A 和B进行数据传输:
A运行Nagle算法，
B运行delayed ACK算法
此时问题就来了，因为A没有收到第二个packet的ACK确认，同时数据当然我们从上面可以看到这种等待机制还是有副作用的，那就是需要等待：一项数据表明：在以太网上,传输100000字节仅需1ms,但由于delayed ack和nagle的作用却要花费201ms,这显然对程序的效率产生了很大影响.TCP/IP协议中，无论发送多少数据，总是要在数据前面加上协议头，同时，对方接收到数据，也需要发送ACK表示确认。为了尽可能的利用网络带宽，TCP总是希望尽可能的发送足够大的数据。（一个连接会设置MSS参数，因此，TCP/IP希望每次都能够以MSS尺寸的数据块来发送数据）。
Nagle算法就是为了尽可能发送大块数据，避免网络中充斥着许多小数据块。
Nagle算法的基本定义是任意时刻，最多只能有一个未被确认的小段。
所谓“小段”，指的是小于MSS尺寸的数据块，
所谓“未被确认”，是指一个数据块发送出去后，没有收到对方发送的ACK确认该数据已收到。
举个例子，比如之前的blog中的实验，一开始client端调用socket的write操作将一个int型数据(称为A块)写入到网络中，由于此时连接是空闲的（也就是说还没有未被确认的小段），因此这个int型数据会被马上发送到server端，接着，client端又调用write操作写入‘/r/n’（简称B块），这个时候，A块的ACK没有返回，所以可以认为已经存在了一个未被确认的小段，所以B块没有立即被发送，一直等待A块的ACK收到（大概40ms之后），B块才被发送。整个过程如图所示：
这里还隐藏了一个问题，就是A块数据的ACK为什么40ms之后才收到？这是因为TCP/IP中不仅仅有nagle算法，还有一个ACK延迟机制。当Server端收到数据之后，它并不会马上向client端发送ACK，而是会将ACK的发送延迟一段时间（假设为t），它希望在t时间内server端会向client端发送应答数据，这样ACK就能够和应答数据一起发送，就像是应答数据捎带着ACK过去。在我之前的时间中，t大概就是40ms。这就解释了为什么’/r/n’(B块)总是在A块之后40ms才发出。
如果你觉着nagle算法太捣乱了，那么可以通过设置TCP_NODELAY将其禁用。当然，更合理的方案还是应该使用一次大数据的写操作，而不是多次小数据的写操作。
]]>Golang的主要 设计目标之一就是面向大规模后端服务程序，网络通信这块是服务端 程序必不可少也是至关重要的一部分。在日常应用中，我们也可以看到Go中的net以及其subdirectories下的包均是“高频+刚需”，而TCP socket则是网络编程的主流，即便您没有直接使用到net中有关TCP Socket方面的接口，但net/http总是用到了吧，http底层依旧是用tcp socket实现的
网络编程方面，我们最常用的就是tcp socket编程了，在posix标准出来后，socket在各大主流OS平台上都得到了很好的支持。关于tcp programming，最好的资料莫过于W. Richard Stevens 的网络编程圣经《UNIX网络 编程 卷1：套接字联网API》 了，书中关于tcp socket接口的各种使用、行为模式、异常处理讲解的十分细致。Go是自带runtime的跨平台编程语言，Go中暴露给语言使用者的tcp socket api是建立OS原生tcp socket接口之上的。由于Go runtime调度的需要，golang tcp socket接口在行为特点与异常处理方面与OS原生接口有着一些差别。这篇博文的目标就是整理出关于Go tcp socket在各个场景下的使用方法、行为特点以及注意事项
从tcp socket诞生后，网络编程架构模型也几经演化，大致是：“每进程一个连接” –> “每线程一个连接” –> “Non-Block + I/O多路复用(linux epoll/windows iocp/freebsd darwin kqueue/solaris Event Port)”。伴随着模型的演化，服务程序愈加强大，可以支持更多的连接，获得更好的处理性能
目前主流web server一般均采用的都是”Non-Block + I/O多路复用”（有的也结合了多线程、多进程）。不过I/O多路复用也给使用者带来了不小的复杂度，以至于后续出现了许多高性能的I/O多路复用框架， 比如libevent、libev、libuv等，以帮助开发者简化开发复杂性，降低心智负担。不过Go的设计者似乎认为I/O多路复用的这种通过回调机制割裂控制流 的方式依旧复杂，且有悖于“一般逻辑”设计，为此Go语言将该“复杂性”隐藏在Runtime中了：Go开发者无需关注socket是否是 non-block的，也无需亲自注册文件描述符的回调，只需在每个连接对应的goroutine中以“block I/O”的方式对待socket处理即可，这可以说大大降低了开发人员的心智负担。一个典型的Go server端程序大致如下
1 | //go-tcpsock/server.go |
用户层眼中看到的goroutine中的“block socket”，实际上是通过Go runtime中的netpoller通过Non-block socket + I/O多路复用机制“模拟”出来的，真实的underlying socket实际上是non-block的，只是runtime拦截了底层socket系统调用的错误码，并通过netpoller和goroutine 调度让goroutine“阻塞”在用户层得到的Socket fd上。比如：当用户层针对某个socket fd发起read操作时，如果该socket fd中尚无数据，那么runtime会将该socket fd加入到netpoller中监听，同时对应的goroutine被挂起，直到runtime收到socket fd 数据ready的通知，runtime才会重新唤醒等待在该socket fd上准备read的那个Goroutine。而这个过程从Goroutine的视角来看，就像是read操作一直block在那个socket fd上似的。具体实现细节在后续场景中会有补充描述
众所周知，TCP Socket的连接的建立需要经历客户端和服务端的三次握手的过程。连接建立过程中，服务端是一个标准的Listen + Accept的结构(可参考上面的代码)，而在客户端Go语言使用net.Dial()或net.DialTimeout()进行连接建立
阻塞Dial：
1
2
3
4
5 conn, err := net.Dial("tcp", "www.baidu.com:80")
if err != nil {
//handle error
}
//read or write on conn
超时机制的Dial：
1
2
3
4
5 conn, err := net.DialTimeout("tcp", "www.baidu.com:80", 2*time.Second)
if err != nil {
//handle error
}
//read or write on conn
对于客户端而言，连接的建立会遇到如下几种情形：
1、网络不可达或对方服务未启动
如果传给Dial的Addr是可以立即判断出网络不可达，或者Addr中端口对应的服务没有启动，端口未被监听，Dial会几乎立即返回错误，比如：
1 | //go-tcpsock/conn_establish/client1.go |
如果本机8888端口未有服务程序监听，那么执行上面程序，Dial会很快返回错误：
1 | $go run client1.go |
2、对方服务的listen backlog满
还有一种场景就是对方服务器很忙，瞬间有大量client端连接尝试向server建立，server端的listen backlog队列满，server accept不及时((即便不accept，那么在backlog数量范畴里面，connect都会是成功的，因为new conn已经加入到server side的listen queue中了，accept只是从queue中取出一个conn而已)，这将导致client端Dial阻塞。我们还是通过例子感受Dial的行为特点：
服务端代码：
1 | //go-tcpsock/conn_establish/server2.go |
客户端代码：
1 | //go-tcpsock/conn_establish/client2.go |
可以看出Client初始时成功地一次性建立了128个连接，然后后续每阻塞近10s才能成功建立一条连接。也就是说在server端 backlog满时(未及时accept)，客户端将阻塞在Dial上，直到server端进行一次accept。至于为什么是128，这与darwin 下的默认设置有关：
如果我在ubuntu 14.04上运行上述server程序，我们的client端初始可以成功建立499条连接。
如果server一直不accept，client端会一直阻塞么？我们去掉accept后的结果是：在Darwin下，client端会阻塞大 约1分多钟才会返回timeout：
而如果server运行在ubuntu 14.04上，client似乎一直阻塞，我等了10多分钟依旧没有返回。 阻塞与否看来与server端的网络实现和设置有关
3、网络延迟较大，Dial阻塞并超时
如果网络延迟较大，TCP握手过程将更加艰难坎坷（各种丢包），时间消耗的自然也会更长。Dial这时会阻塞，如果长时间依旧无法建立连接，则Dial也会返回“ getsockopt: operation timed out”错误
在连接建立阶段，多数情况下，Dial是可以满足需求的，即便阻塞一小会儿。但对于某些程序而言，需要有严格的连接时间限定，如果一定时间内没能成功建立连接，程序可能会需要执行一段“异常”处理逻辑，为此我们就需要DialTimeout了。下面的例子将Dial的最长阻塞时间限制在2s内，超出这个时长，Dial将返回timeout error：
1 | //go-tcpsock/conn_establish/client3.go |
执行结果如下，需要模拟一个网络延迟大的环境
1 | $go run client3.go |
连接建立起来后，我们就要在conn上进行读写，以完成业务逻辑。前面说过Go runtime隐藏了I/O多路复用的复杂性。语言使用者只需采用goroutine+Block I/O的模式即可满足大部分场景需求。Dial成功后，方法返回一个net.Conn接口类型变量值，这个接口变量的动态类型为一个*TCPConn：
1 | //$GOROOT/src/net/tcpsock_posix.go |
TCPConn内嵌了一个unexported类型：conn，因此TCPConn”继承”了conn的Read和Write方法，后续通过Dial返回值调用的Write和Read方法均是net.conn的方法：
1 | //$GOROOT/src/net/net.go |
1、conn.Read的行为特点
1.1、Socket中无数据
连接建立后，如果对方未发送数据到socket，接收方(Server)会阻塞在Read操作上，这和前面提到的“模型”原理是一致的。执行该Read操作的goroutine也会被挂起。runtime会监视该socket，直到其有数据才会重新
调度该socket对应的Goroutine完成read。由于篇幅原因，这里就不列代码了，例子对应的代码文件：go-tcpsock/read_write下的client1.go和server1.go。
1.2、Socket中有部分数据
如果socket中有部分数据，且长度小于一次Read操作所期望读出的数据长度，那么Read将会成功读出这部分数据并返回，而不是等待所有期望数据全部读取后再返回。
1.3、Socket中有足够数据
如果socket中有数据，且长度大于等于一次Read操作所期望读出的数据长度，那么Read将会成功读出这部分数据并返回。这个情景是最符合我们对Read的期待的了：Read将用Socket中的数据将我们传入的slice填满后返回：n = 10, err = nil
1.4、Socket关闭
如果client端主动关闭了socket，那么Server的Read将会读到什么呢？
这里分为“有数据关闭”和“无数据关闭”。
有数据关闭是指在client关闭时，socket中还有server端未读取的数据。当client端close socket退出后，server依旧没有开始Read，10s后第一次Read成功读出了所有的数据，当第二次Read时，由于client端 socket关闭，Read返回EOF error
无数据关闭情形下的结果，那就是Read直接返回EOF error
1.5、读取操作超时
有些场合对Read的阻塞时间有严格限制，在这种情况下，Read的行为到底是什么样的呢？在返回超时错误时，是否也同时Read了一部分数据了呢？
不会出现“读出部分数据且返回超时错误”的情况
2、conn.Write的行为特点
2.1、成功写
前面例子着重于Read，client端在Write时并未判断Write的返回值。所谓“成功写”指的就是Write调用返回的n与预期要写入的数据长度相等，且error = nil。这是我们在调用Write时遇到的最常见的情形，这里不再举例了
2.2、写阻塞
TCP连接通信两端的OS都会为该连接保留数据缓冲，一端调用Write后，实际上数据是写入到OS的协议栈的数据缓冲的。TCP是全双工通信，因此每个方向都有独立的数据缓冲。当发送方将对方的接收缓冲区以及自身的发送缓冲区写满后，Write就会阻塞
2.3、写入部分数据
Write操作存在写入部分数据的情况。没有按照预期的写入所有数据。这时候循环写入便是
综上例子，虽然Go给我们提供了阻塞I/O的便利，但在调用Read和Write时依旧要综合需要方法返回的n和err的结果，以做出正确处理。net.conn实现了io.Reader和io.Writer接口，因此可以试用一些wrapper包进行socket读写，比如bufio包下面的Writer和Reader、io/ioutil下的函数等
基于goroutine的网络架构模型，存在在不同goroutine间共享conn的情况，那么conn的读写是否是goroutine safe的呢？在深入这个问题之前，我们先从应用意义上来看read操作和write操作的goroutine-safe必要性。
对于read操作而言，由于TCP是面向字节流，conn.Read无法正确区分数据的业务边界，因此多个goroutine对同一个conn进行read的意义不大，goroutine读到不完整的业务包反倒是增加了业务处理的难度。对与Write操作而言，倒是有多个goroutine并发写的情况。
每次Write操作都是受lock保护，直到此次数据全部write完。因此在应用层面，要想保证多个goroutine在一个conn上write操作的Safe，需要一次write完整写入一个“业务包”；一旦将业务包的写入拆分为多次write，那就无法保证某个Goroutine的某“业务包”数据在conn发送的连续性。
同时也可以看出即便是Read操作，也是lock保护的。多个Goroutine对同一conn的并发读不会出现读出内容重叠的情况，但内容断点是依 runtime调度来随机确定的。存在一个业务包数据，1/3内容被goroutine-1读走，另外2/3被另外一个goroutine-2读 走的情况。比如一个完整包：world，当goroutine的read slice size < 5时，存在可能：一个goroutine读到 “worl”,另外一个goroutine读出”d”。
原生Socket API提供了丰富的sockopt设置接口，但Golang有自己的网络架构模型，golang提供的socket options接口也是基于上述模型的必要的属性设置。包括
SetKeepAlive
SetKeepAlivePeriod
SetLinger
SetNoDelay （默认no delay）
SetWriteBuffer
SetReadBuffer
不过上面的Method是TCPConn的，而不是Conn的，要使用上面的Method的，需要type assertion：
1 | tcpConn, ok := conn.(*TCPConn) |
对于listener socket, golang默认采用了 SO_REUSEADDR，这样当你重启 listener程序时，不会因为address in use的错误而启动失败。而listen backlog的默认值是通过获取系统的设置值得到的。不同系统不同：mac 128, linux 512等
七、关闭连接
和前面的方法相比，关闭连接算是最简单的操作了。由于socket是全双工的，client和server端在己方已关闭的socket和对方关闭的socket上操作的结果有不同。看下面例子：
1 | //go-tcpsock/conn_close/client1.go |
执行结果如下
1 | $go run server1.go |
从client的结果来看，在己方已经关闭的socket上再进行read和write操作，会得到”use of closed network connection” error；
从server的执行结果来看，在对方关闭的socket上执行read操作会得到EOF error，但write操作会成功，因为数据会成功写入己方的内核socket缓冲区中，即便最终发不到对方socket缓冲区了，因为己方socket并未关闭。因此当发现对方socket关闭后，己方应该正确合理处理自己的socket，再继续write已经无任何意义了
本文比较基础，但却很重要，毕竟golang是面向大规模服务后端的，对通信环节的细节的深入理解会大有裨益。另外Go的goroutine+阻塞通信的网络通信模型降低了开发者心智负担，简化了通信的复杂性，这点尤为重要
]]> 1 | typedef struct redisDb { |
书上说save的时候过期键不保留,load的时候保留.但是5.0代码中,情况相反.可能是saveInfo的关系.即使是定时任务,因为在redis的过期处理规则可能会有部分过期键没有删除掉(serverCron->databasesCron->activeExpireCycle),所以这个不保留不是绝对的
rdbSave->rdbSaveRio
REDIS|db_version(4)|saveInfo|database|EOF|check_sum
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
dictIterator *di = NULL;
dictEntry *de;
char magic[10];
int j;
uint64_t cksum;
size_t processed = 0;
if (server.rdb_checksum)
// 校验函数
rdb->update_cksum = rioGenericUpdateChecksum;
snprintf(magic,sizeof(magic),"REDIS%04d",RDB_VERSION);
// 从这里开始,redis+4个字节的版本号
if (rdbWriteRaw(rdb,magic,9) == -1) goto werr;
// 写入saveInfo,type是 RDB_OPCODE_AUX
if (rdbSaveInfoAuxFields(rdb,flags,rsi) == -1) goto werr;
for (j = 0; j < server.dbnum; j++) {
redisDb *db = server.db+j;
dict *d = db->dict;
if (dictSize(d) == 0) continue;
di = dictGetSafeIterator(d);
/* Write the SELECT DB opcode */
// 写入SELECTDB = 254
if (rdbSaveType(rdb,RDB_OPCODE_SELECTDB) == -1) goto werr;
// 调用的是写入长度,其实是写入数字
if (rdbSaveLen(rdb,j) == -1) goto werr;
/* Write the RESIZE DB opcode. We trim the size to UINT32_MAX, which
* is currently the largest type we are able to represent in RDB sizes.
* However this does not limit the actual size of the DB to load since
* these sizes are just hints to resize the hash tables. */
uint64_t db_size, expires_size;
db_size = dictSize(db->dict);
expires_size = dictSize(db->expires);
// 写入db的size,RDB_OPCODE_RESIZEDB = 251
if (rdbSaveType(rdb,RDB_OPCODE_RESIZEDB) == -1) goto werr;
if (rdbSaveLen(rdb,db_size) == -1) goto werr;
// 跟着过期字典的大小
if (rdbSaveLen(rdb,expires_size) == -1) goto werr;
/* Iterate this DB writing every entry */
while((de = dictNext(di)) != NULL) {
sds keystr = dictGetKey(de);
robj key, *o = dictGetVal(de);
long long expire;
initStaticStringObject(key,keystr);
expire = getExpire(db,&key);
// key,value保存
if (rdbSaveKeyValuePair(rdb,&key,o,expire) == -1) goto werr;
/* When this RDB is produced as part of an AOF rewrite, move
* accumulated diff from parent to child while rewriting in
* order to have a smaller final write. */
// 这个应该是AOF重写中被rdb阻塞了而造成延迟
if (flags & RDB_SAVE_AOF_PREAMBLE &&
rdb->processed_bytes > processed+AOF_READ_DIFF_INTERVAL_BYTES)
{
processed = rdb->processed_bytes;
aofReadDiffFromParent();
}
}
dictReleaseIterator(di);
di = NULL; /* So that we don't release it again on error. */
}
/* If we are storing the replication information on disk, persist
* the script cache as well: on successful PSYNC after a restart, we need
* to be able to process any EVALSHA inside the replication backlog the
* master will send us. */
if (rsi && dictSize(server.lua_scripts)) {
di = dictGetIterator(server.lua_scripts);
while((de = dictNext(di)) != NULL) {
robj *body = dictGetVal(de);
if (rdbSaveAuxField(rdb,"lua",3,body->ptr,sdslen(body->ptr)) == -1)
goto werr;
}
dictReleaseIterator(di);
di = NULL; /* So that we don't release it again on error. */
}
/* EOF opcode */
if (rdbSaveType(rdb,RDB_OPCODE_EOF) == -1) goto werr;
/* CRC64 checksum. It will be zero if checksum computation is disabled, the
* loading code skips the check in this case. */
cksum = rdb->cksum;
memrev64ifbe(&cksum);
if (rioWrite(rdb,&cksum,8) == 0) goto werr;
return C_OK;
werr:
if (error) *error = errno;
if (di) dictReleaseIterator(di);
return C_ERR;
}
// 各类型在rdb中的编码方式
int rdbSaveKeyValuePair(rio *rdb, robj *key, robj *val, long long expiretime) {
int savelru = server.maxmemory_policy & MAXMEMORY_FLAG_LRU;
int savelfu = server.maxmemory_policy & MAXMEMORY_FLAG_LFU;
/* Save the expire time */
//如果设置了过期时间,先写过期时间 RDB_OPCODE_EXPIRETIME_MS = 252
if (expiretime != -1) {
if (rdbSaveType(rdb,RDB_OPCODE_EXPIRETIME_MS) == -1) return -1;
// 8个字节长的时间
if (rdbSaveMillisecondTime(rdb,expiretime) == -1) return -1;
}
/* Save the LRU info. */
// 如果设置了LRU策略,就要保存对象的lru信息,为了后面策略的执行
if (savelru) {
// 因为lru是相对时间,所以要修饰一下
uint64_t idletime = estimateObjectIdleTime(val);
idletime /= 1000; /* Using seconds is enough and requires less space.*/
if (rdbSaveType(rdb,RDB_OPCODE_IDLE) == -1) return -1;
if (rdbSaveLen(rdb,idletime) == -1) return -1;
}
/* Save the LFU info. */
// 按频率的删除策略,要存储频率
if (savelfu) {
uint8_t buf[1];
buf[0] = LFUDecrAndReturn(val);
/* We can encode this in exactly two bytes: the opcode and an 8
* bit counter, since the frequency is logarithmic with a 0-255 range.
* Note that we do not store the halving time because to reset it
* a single time when loading does not affect the frequency much. */
if (rdbSaveType(rdb,RDB_OPCODE_FREQ) == -1) return -1;
if (rdbWriteRaw(rdb,buf,1) == -1) return -1;
}
/* Save type, key, value */
// 存储对象类型
if (rdbSaveObjectType(rdb,val) == -1) return -1;
// 存储key,一定是string对象类型
if (rdbSaveStringObject(rdb,key) == -1) return -1;
// 存储值,key在类型为OBJ_STREAM和OBJ_MODULE中有用到
// 除了quicklist
if (rdbSaveObject(rdb,val,key) == -1) return -1;
return 1;
}
rdbSaveObject
1 | typedef struct redisObject { |
type类型
1 | |
encoding编码
1 | |
1 |
|
zlbytes- ztail- zllen- entrys-…- zlend uint32_t uint32_t uint16_t zlentry uint8_t
因为zlend使用固定值
ZIP_END = 255作为结束标志(0xFF作为uint8的最大值,与prevlen单字节长度0xFE进行区别,同时是最后面的两个数作为标志(这个懂的吧)).
这个结构体只是用来接收存放信息的,只是为了方便操作,而并不是其在ziplist中的真正编码方式
实际是:
previous_entry_length-> encoding -> content
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// 前一个entry的字长
unsigned int prevrawlensize; /* Bytes used to encode the previous entry len*/
//
unsigned int prevrawlen; /* Previous entry len. */
unsigned int lensize; /* Bytes used to encode this entry type/len.
For example strings have a 1, 2 or 5 bytes
header. Integers always use a single byte.*/
unsigned int len; /* Bytes used to represent the actual entry.
For strings this is just the string length
while for integers it is 1, 2, 3, 4, 8 or
0 (for 4 bit immediate) depending on the
number range. */
unsigned int headersize; /* prevrawlensize + lensize. */
// 编码方式
unsigned char encoding; /* Set to ZIP_STR_* or ZIP_INT_* depending on
the entry encoding. However for 4 bits
immediate integers this can assume a range
of values and must be range-checked. */
// 值
unsigned char *p; /* Pointer to the very start of the entry, that
is, this points to prev-entry-len field. */
} zlentry;
读取第一个字节是否为0xfe区分是1个字长还是5个字长(为什么是0xfe,因为0xff被用作结束标志)
- 1字节长,小于0xfe(244)
- 5字节长,第一字节是 0xfe,后面四个字节是实际长度
根据第一字节前2位,判断是整数还是字符串
- 前2位是00,01,10.这时候是字符串
- 00bbbbbb,后面6位表示content长度,(<=2^6-1 = 63)
- 01bbbbbb xxxxxxxx,用后6位以及后面一个字节表示content长度,共14位(<=16383)
- 10______ aaaaaaaa bbbbbbbb cccccccc dddddddd,5字节长,后4个字节表示长度(<=2^32-1)
前缀 c=ctrl, m=meta, a=alt,大写+shift
当前页的操作
进入新页面的操作
使用查找功能
历史
tab操作
使用标注
其他的浏览优化命令
]],[[ 大概是在分页中定位到有next或者>标签的地方,也就是上一页\下一页]]>前往github查看
结构定义在
server.h文件
方法实现在t_zset.c文件(ziplist是压缩)
zskiplistNode
1 | typedef struct zskiplistNode { |
zskiplist
1 | typedef struct zskiplist { |
幂次定律: 越大的数出现的概率越小
level为 n的概率大概是 (3/4)^n
2
3
4
5
6
7
int level = 1;
// 每次1/4的概率往上加
while ((random()&0xFFFF) < (ZSKIPLIST_P * 0xFFFF))
level += 1;
return (level<ZSKIPLIST_MAXLEVEL) ? level : ZSKIPLIST_MAXLEVEL;
}
zslCreate
1 | zskiplist *zslCreate(void) { |
zslInsert
前提保证了元素不存在
看起来有点复杂的
1 | zskiplistNode *zslInsert(zskiplist *zsl, double score, sds ele) { |
zslDelete
zslUpdateScore
是先delete,在insert,不复用
union里面多了double类型d 1 | typedef struct dictEntry { |
1 | typedef struct dict { |
迭代器,大多用在rdb,aof,cluster场景中
有safe的差异
2
3
4
5
6
7
8
dict *d;
long index;
int table, safe;
dictEntry *entry, *nextEntry;
/* unsafe iterator fingerprint for misuse detection. */
long long fingerprint; // 在非安全模式模式下,迭代的时候生成一个指纹,在后续再次处理相应键的时候,对比指纹是否一致,判断键值是否被修改
} dictIterator;
在rehash 过程中,dict是不会再次扩充的,那么有没有可能dict填满了,而还没有rehash完?
不会,dicths的table是二维链表,size只是外层bucket的数量,幷不限制每个bucket的存储数量
1 | /* Expand or create the hash table */ |
1 | // n是rehash的bucket数量(不包含空的) |
rehash机制dictRehashMilliseconds
这个返回的rehashes的bucket数量不一定准确,因为rehash完成了就不会把最后一次的具体数量加进去,然后这个毫秒时间差异也不是精确的
2
3
4
5
6
7
8
9
10
long long start = timeInMilliseconds();
int rehashes = 0;
while(dictRehash(d,100)) {
rehashes += 100;
if (timeInMilliseconds()-start > ms) break;
}
return rehashes;
}
rehash机制_dictRehashStep
这个就简单了,迭代一个一个bucket去rehash
2
3
if (d->iterators == 0) dictRehash(d,1);
}
比如dictAdd
1 |
|
dictGenericDelete
很简单,就是找到幷删除,然后在删除的时候区分是否释放内存
如果是dictDelete的实现,是要释放内存的
如果是dictUnlink,则不释放内存,在之后用dictFreeUnlinkedEntry释放内存,用在释放前,需要对它做其他操作而不影响其他增删改查.比如数据库server->db->dict对键dbAsyncDelete,zse里的del
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
uint64_t h, idx;
dictEntry *he, *prevHe;
int table;
if (d->ht[0].used == 0 && d->ht[1].used == 0) return NULL;
if (dictIsRehashing(d)) _dictRehashStep(d);
h = dictHashKey(d, key);
for (table = 0; table <= 1; table++) {
idx = h & d->ht[table].sizemask;
he = d->ht[table].table[idx];
prevHe = NULL;
while(he) {
if (key==he->key || dictCompareKeys(d, key, he->key)) {
/* Unlink the element from the list */
if (prevHe)
prevHe->next = he->next;
else
d->ht[table].table[idx] = he->next;
if (!nofree) {
dictFreeKey(d, he);
dictFreeVal(d, he);
zfree(he);
}
d->ht[table].used--;
return he;
}
prevHe = he;
he = he->next;
}
if (!dictIsRehashing(d)) break;
}
return NULL; /* not found */
}
privdata找到相关参数直接赋值过去 1 |
|
不是单一的
sdshdr结构,而是分了sdshdr5,sdshdr8,sdshdr16,sdshdr32,sdshdr64几种.鉴于对__attribute__的浅陋理解,是对某种结构属性的定义,也就是说可以当作同一个结构,然后在不同的场景,赋予了不同的结构属性.然后主要用flags的前三位(5种类型)来判断使用的是那种属性结构
1 | // 这个不存在使用场景,只是给出理论上的属性结构 |
#define SDS_MAX_PREALLOC (1024*1024)
这是重分配的1M空间临界定义字段
sdsReqType
这个函数没什么特殊的
1 | tatic inline char sdsReqType(size_t string_size) { |
这个函数是主要功能,其他的很多函数都是调用它实现的
1 | sds sdsnewlen(const void *init, size_t initlen) { |
虽然不一定都需要
- gv,go自带的pprof命令,实际上是
Graphviz,搜索安装就可以了- web,同gv,不过是在浏览器中显示
- go-torch,火焰图
源自于同事的socket连接服务,服务启动一段时间后,内存飙升,呈现累积不下的现象,初步判断为内存泄漏(top下单个服务占用29G内存).
1 | go tool pprof --inuse_space {{host}}/debug/pprof/heap |
结果如下:
分析代码(由于代码变动,实际上137行移动到140行)
msgData泄漏了.但是一开始在分析怎么泄漏的时候走了不少弯路conn是socket连接,所以在一开始Read的时候,读出的数据包是要自定义解析的,初步判定msgLen值过大引起分配过大,至于为什么过大(是客户端传错了还是怎么的,暂不考虑,主要是也没打日志).go是自带gc的语言 go线程泄漏(因为想当然的认为接下来的错误没有问题),于是去分析goroutine
goroutine的泄漏,很简单,因为前面内存泄漏是指向这个函数的block里面的阻塞(为什么呢?因为这个函数很简单,msgData泄漏的唯一可能是这个变量没有被使用,于是怀疑上是阻塞).重新打开goroutine的pprof界面,搜索该方法及文件名,很快发现一些IO Wait状态线程,于是确定是阻塞
heap文件指向的 140(137)行之后的io.ReadFull方法
bytes包的文档,当然下面给出的是Buffer的注释(Reader下没有)
net.Conn下的Read方法的注释,于是确认了这里这样读是会阻塞的
0或者比较大的一个值,比较麻烦.这是作者对runtime设计的一个阐述,翻译内容是这样的
这是一份原型文档,虽然在当下可能已经有点过时了.目的是讲述go程序运行原理,与我们写的go代码有什么不同.着重讲述一些大概的概念而不是详细的细节.
调度器管理了三种贯穿整个运行环境的资源:Gs,Ms和Ps.即时不需要操作运行环境也是需要了解的.
一个”G”就可以简单的代表一个goroutine,有类型g表示,当一个goroutine退出,g对象就会被放在空闲g列表(池),之后被其他goroutine复用.
一个”M”代表一个可以真正执行用户代码,运行时代码以,系统调用,也可以空闲.由结构体m表示.在某一时刻可能有任意多的m,因为同时间可能发生任意多的系统调用
最后,一个”P”代表执行用户代码所需要的资源,比如调度器和内存分配状态,由结构体p表示.数量可以由GOMAXPROCS决定.一个P就像操作系统的CPU,p的内容就像每个CPU的状态.为了调度效率,将共享状态放在p中比放在每个m中或者每个g里面要好.
调度的工作是匹配G(要执行的代码),M(执行时机)和P(执行的资源和环境).当M停止执行用户代码的时候(比如发生系统调用的时候),将P放回P池,在恢复执行之前,再到P池里面取出一个P.
所有的g,m,p都是在堆里分配的,并且是不释放的资源,所以他们是稳定存在的,不需要运行时通过write barrier.
每个没有进入到死亡状态的G都有一个用户栈,是Go代码运行的地方.用户栈在开始分配的时候很小,在运行过程中动态增长或缩减
每个M都有一个系统栈(也就是M的”g0”栈,因为它是固定的),并且在Unix平台中有一个信号栈(gsignal).系统栈和信号栈不会增长,但是足以执行运行时代码和cgo代码(纯go二进制文件是8k;cgo由系统分配)
运行时经常会调用systemstack,mcall,或者asmcgocall临时地切换到系统栈取执行那些无法增长栈空间或者且切换用户goroutine的非抢占任务.在系统栈上运行的代码一定是非抢占式的,而且gc无法扫描系统栈.在系统栈上运行的时候,当前的用户栈也不是用来执行代码的.
getg()和getg().m.curg获取当前的用户g,用 getg().m.curg.getg()也返回当前的g,但是在系统栈或者信号栈执行代码的时候,这个方法返回的是当前m的”g0”或者”gsignal”.
所以可以用getg() == getg().m.curg判断当前是在用户栈上运行还是系统栈上运行
一般情况下,用户可以捕捉到panic进行处理(recover).但是,有一些情况,比如在系统栈上调用,或者在mallocgc时候调用的panic是灾难性的,无法恢复.
大部分在运行时抛出的错误是无法recover的.比如,用throw会立即抛出错误路径幷终止进程.一般情况下,throw应该传递一个常量string参数,避免不安全的分配.最终,在throw之前会打印出以”runtime”开头的错误信息.
为了runtime错误进行debug,可以加参数 GOTRACEBACK=system或者GOTRACEBACK=crash.
运行时有很多不同的同步机制.这与语境上有关,比如goroutine调度上,和系统调度.
最简单的是 mutex, 只要使用lock和unlock就行了.这个用在短时间内保护共享结构.在mutex的是阻塞会直接阻塞m,与Go调度没什么关系.这意味着它是安全的也是runtime中最低级别的,因为阻碍了相关的G和P进行重调度.rwmutex也是一样的.
在一次性的通知情形下,使用note,提供了 notesleep和notewakeup两个方法.与传统UNIX系统中sleep/wakeup不同.note是一种无静态的调用,在调用notesleep或notewakeup之后立刻返回.note可以在用户调用noteclear之后重置,这也决定了note在sleep或者wakeup的时候不能有竟态.note和mutex一样,阻塞m,但是它进入睡眠状态的方式是不一样的:notesleep也阻碍了相关G和P的重调度,但是notetsleepg就像系统调用的阻塞,不影响在P上运行另一个G.当然,这仍然比阻塞G更低效.
用gopark和goready.gopark直接操作goroutine,将当前G放到等待队列幷从M/P就绪队列中移除,然后运行另一个就绪G,goready将一个停下的G重新放入就绪队列等待运行
总结一下,阻塞关系就是:
运行时有自己的atomic包 runtime/internal/atomic,与sync/atomic对应,但是应为历史遗留问题,函数有不同的名称,还有一下附加的功能
一般而言,我们在运行时要慎重使用atomics,最好避免使用atomics操作.如果一个变量有可能被其他的同步机制锁保护,这个被保护的变量一般也不需要是原子的.这其中有个方面的理由:
使用non-atomic或者atomic会使得相应代码self-documenting.因为atomic的介入往往意味着有会有线程问题.
non-atomic操作允许自动竟态检测,运行时虽然不会惊醒多线程静态检测,但是在不久的将来会.而atomic操作不允许竟态检测.而non-atomic允许你自定义的进行静态检测.
non-atomic可以提升性能
当然,任何对共享变量的non-atomic操作都应该描述清楚如何进行保护
有些模式混用了atomic和non-atomic:
Read-mostly 变量在更新的时候进行保护,而在锁定的时候,读操作不需要是原子的.在锁定区域外,读操作是原子的
在STW的读,因为在STW的时候不会发生写操作
也就是说,就像 Go Memory Model的观点,”Don’t be [too] clever”.这是在runtime里的情况,在其他地方也一样.
通常,runtime尝试使用正常的堆内存分配.但是,有时runtime必须在无法gc的地方(堆之外)进行分配,也就是unmanaged memory.这是必要的,如果对象是memory manager自己的或者调用方可能没有P.
有三种Unmanaged memory 分配机制
sysAlloc直接从操作系统中获取内存.内存可能来自各个分页,但是通过sysFree可以全部释放
fragmentation从小页中获取内存,联合成sysAlloc一样的,这样避免造成太多的内存碎片,但是正如它的名字,这些内存没有办法释放
fixalloc是SLAB算法分配内存的,它分配固定大小的内存,可以释放,但是这些内存只能由同一个fixalloc池复用.所以这些内存只能被同一种类型数据复用.
通常,使用以上方法分配内存的地方都会注释编译标记//go:notinheap.
在Unmanaged memory分配的对象,除了以下情况不许序包含堆指针.
任何Unmanaged memory里包含的堆内指针必须明确加入gc根(源)runtime.markroot
如果内存被复用,他们被标记为GC roots钱必须是零初始化的
在运行时有两种类型的零化,取决于内存是否已经初始化成类型安全的状态.
如果内存不是类型安全的,意味着它可能包含”garbage”,因为它刚被分配并且正在首次初始化,这种情况,必须使用zero-initialized,也就是memclrNoHeapPointers或者非指针写.这种情况下不会有写屏障write barriers.
如果内存已经是类型安全的并且简单的设置为零值了,那么必须使用typedmemclr或者memclrHasPointers,.这种方式有write barriers.
除了”//go:”除了用在文档之外,还可以直接对编译进行干预
go:systemstack表示函数必须运行在系统栈,这会在函数的开始进行动态检查
go:nowritebarrier让函数在出现write barriers的时候报错(无法阻止write barriers的生成,只是简单的插入)
通常的使用场景是,最好不要write barriers,但是不是必要的go:nowritebarrierrec. go:nowritebarrier
go:nowritebarrierrec 让编译器在函数及其递归调用的的函数中在write barrier的时候抛出错误.相应的 go:yeswritebarrierrec保证编译器进行write barrier
逻辑上,编译器floods每个一go:nowritebarrierrec 开始的函数调用图,当遇到一个包含write barrier 的函数的时候.在go:yeswritebarrierrec是没有flood的
go:nowritebarrierrec用在write barrier的实现上,防止循环初始化
两种方式都是直接在调度器使用,write barrier需要一个有效P(getg().m.p != nil)而调度器代码经常不在一个有效P上运行.在这种情况,go:nowritebarrierrec使用在P的释放函数上,或者在没有P的时候,go:yeswritebarrierrec运行在重新获取P的函数上.因为有函数层级概念,释放和获取P要分成2个函数
go:notinheap运用在类型声明,这意味着一个类型绝不会在GC’d(不GC?)堆里分配.所以,这种类型的指针总是会在runtime.inheap的检查中失败.这种类型可以是全局变量,栈变量或者非托管内存对象( sysAlloc, persistentalloc,fixalloc分配).
new(T), make([]T), append([]T, ...) 以及隐藏类型(泛型)分配是不允许的
正常类型的指针(不是unsafe.Pointer)不能被转换成一个go:notinheap 类型,即时它们有相同的底层
任何包含 go:notinheap类型的类型也是go:notinheap的,数组和结构体的元素是go:notinheap的,那么也是.map和channel不允许有go:notinheap.为了明确任何隐藏go:notinheap类型必须声明
在go:notinheap的指针上的Write barriers将被忽略
最后,go:notinheap真正的用处.运行时在低层级的内部结构中使用,以避免调度器和内存分配器上的memory barriers ,因为在这里他们是无效的,这种方式的安全的,也不会影响可读性.
1 | type cpuProfile struct { |
1 |
|
1 | func (p *cpuProfile) add(gp *g, stk []uintptr) { |
1 | // Invariants: |
翻译一下:
定式:
在无缓冲通道,除非send和rece都在单线程下阻塞, c.sendq和c.recvq至少有一个是空的,而且c.sendq和c.recvq的长度只受select语法限制
1 | hchanSize = unsafe.Sizeof(hchan{}) + uintptr(-int(unsafe.Sizeof(hchan{}))&(maxAlign-1)) |
看结果是结构体hchan的实际大小,因为hchan的对齐值是8
在makechan64(t *chantype, size int64) *hchan中,size不能越界
1 | func makechan64(t *chantype, size int64) *hchan { |
元素类型大小不能超过64k
1 | func makechan(t *chantype, size int) *hchan { |
1 | /* |
1 | func closechan(c *hchan) { |
1 |
|
1 | func TestChan6(t *testing.T) { |
default或其他条件的存在使得ch不是block读
补充:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
//
//select {
//case c <- v:
//... foo
//default:
//... bar
//}
//
// as
//
//if selectnbsend(c, v) {
//... foo
//} else {
//... bar
//}
//
func selectnbsend(c *hchan, elem unsafe.Pointer) (selected bool) {
return chansend(c, elem, false, getcallerpc())
}
]]>虽然文档说这样子是非阻塞调用,但是在debug的时候并没有见到该函数被调用!!