io模型

计算机的io模型区分为多种，目前用的最多的也就是nio、epoll、select。

结合不同场景使用不同的io模型才是正解。

具体可以查看我之前写的io模型演进。io模型演进

golang中网络io

golang天然适合并发，为什么？一个是轻量级的协程，二个是将复杂的io进行了抽象化，简化了流程。

比如我们简单的访问一个http服务，几行简单的代码就能实现:

那么golang对Io做了哪些优化呢？能实现如此简单的切换呢？

groutinue 针对io事件的调度

我们这里假设你对groutinue调度已经有一定的了解了。

我们知道,在go中，每个process绑定一个虚拟的machine,而在machine中，是具有一个g0的，g0在本地遍历自己的队列获取g或者从全局队列获取g。


我们也知道了，在g运行的时候，g会把执行权交给g0进行重新调度，那么在io事件中，g是怎么把事件交还给g0的呢？这时候就牵扯到我们今天的主角----netpoll。

netpoll

selectselect
  • 监听能力有限 — 最多只能监听 1024 个文件描述符，可以通过手动修改limit来改变，但是各方面成本比较大；
  • 内存拷贝开销大 — 需要维护一个较大的数据结构存储文件描述符，该结构需要拷贝到内核中；
  • 时间复杂度 — 返回准备就绪的事件个数后，需要遍历所有的文件描述符；

golang官方统一封装一个网络事件的poll，和平台无关，为epoll/kqueue/port/AIX/Windows 提供了特定的实现。

src/runtime/netpoll_epoll.gosrc/runtime/netpoll_kqueue.gosrc/runtime/netpoll_solaris.gosrc/runtime/netpoll_windows.gosrc/runtime/netpoll_aix.gosrc/runtime/netpoll_fake.go

这些模块在不同平台上实现了相同的功能，构成了一个常见的树形结构。编译器在编译 Go 语言程序时，会根据目标平台选择树中特定的分支进行编译

必须实现的方法有：

netpoll中有2个重要的结构体：

rseqwseqrgwgpdReadypdWaitnilrdwdrtwt

golang关于io时间做了很多统一的封装在runtime/netpoll之下（其实调用的是internal/poll包下的）,然后通过internal包下对 runtime包进行调用，internal包下也封装了一个同名的pollDesc对象，不过是一个指针(关于internal有个细节就是这个包是不能被外部调用)：

其实最终都是对runtime底下的调用，只不过封装了一些易用的方法，比如read,write,做了一些抽象化的处理。

这些方法的具体实现都在runtime下，我们挑几个重要的看看：

思考：

  1. a、b两个协程，b io阻塞，完成后，一直没有获取到调度权，会出现什么后果。
  2. a、b两个协程，b io阻塞，2s time out,但是a一直占用执行权，b一直没有获取到调度权，5s后才获得到，b对使用端已经超时，这时候是超时还是不超时

所以设置的timeout，不一定是真实的io waiting，可能是没有获取到执行权。

怎么触发读事件的？

因为写io是我们主动操作的，那么读是怎么进行操作的呢？这是一个被动的状态

首先我们了解一个结构体。golang中所有的网络事件和文件读写都用fd进行标识(位于internal包下)。

我们看到，fd中关联的pollDesc,通过pollDesc调用了runtime包内部的实现的各种平台的io事件。

当我们进行read操作时（下面是代码截取）

会阻塞调用waiteRead方法，方法内部主要就是调用的runtime_pollWait。

这里主要是由netpollblock控制,netpollblock方法我们上面就说过，当io还未就绪的时候，直接释放当前的执行权，否则就是已经课读写的io事件，直接进行读取操作即可。

总结

整体流程 listenStream –> bind&listen&init –> pollDesc.Init -> poll_runtime_pollOpen –> runtime.netpollopen -> epollctl(EPOLL_CTL_ADD)

画个图来更容易理解，当然，我偷懒是找的图


golang中遇到io事件时，统一对其做了封装，首先建立系统事件（本文主要针对epoll），然后让出cpu（gopark），然后进行协程调度执行其他g。当g io事件完成时，会从epoll进行交互看是否就绪（epoll就绪列表），就绪则pop取出一个g往下执行，未就绪则调度其他g。（其实pop取就绪列表也有一定逻辑，时候延时处理之类的）

runtime/proc.go，

另外在sysmon中，也对netpoll进行了调度。

备注

epoll

epoll是由系统内核单独维护的一个线程,不由go本身维护

常量

FD_CLOEXEC用来设置文件的close-on-exec状态标准。 这，emm 就挺难理解得。

gc

pollDesc是由pollCache进行维护的，并且不受GC监控(persistentalloc方法分配)，所以，在正常情况关于io的操作，我们一定要进行手动关闭，对epoll中的引用对象进行清理(具体实现在poll_runtime_Semrelease)。

sysmon

Go 的标准库提供了一种监测应用程序的线程,并帮你 (找寻) 程序可能遇到的瓶颈. 该线程称为sysmon，即系统监视器 (system monitor).在GMP 模型中,这个 (特殊) 线程未链接任何的 P, 这意味着调度器 (scheduler) 没有将其考虑在内, 因此始终处于运行状态.



sysmon线程的作用很广, 主要涉及以下方面:

  • 由应用程序创建的计时器 (timers). sysmon线程查看应该在运行却仍在等待执行时间的计时器. 在这种情况下, Go 将查看空闲的 M 和 P 列表, 以便尽可能快地运行它们.
  • 网络轮询器和系统调用. 它将运行在网络操作中被阻塞的 goroutine.
  • 垃圾回收器（如果已经很长时间没有运行）. 如果垃圾回收器已经两分钟没有运行,则 sysmon 将强制执行一轮垃圾回收 (GC).
  • 长时间运行的 goroutine 的抢占. 任何运行时间超过10 毫秒的 goroutine 都会被抢占, 将运行时间 (running time) 留给其他 goroutine.# io模型

计算机的io模型区分为多种，目前用的最多的也就是nio、epoll、select。

结合不同场景使用不同的io模型才是正解。