关于goroutine的一点点浅薄理解

golang_china · · 2141 次点击 · 开始浏览    置顶
这是一个创建于 的主题,其中的信息可能已经有所发展或是发生改变。
###介绍 学习golang就不能不理解goroutine,关于goroutine的科普文章是http://studygolang.com/articles/1855, 这篇教程都第一次看就能看懂,写的非常好,当时以为会goroutine了,但是随着最近半个月的研究发现,如果只看了这篇文章就跟别人吹goroutine就真的贻笑大方了。 ### 我的学习启蒙 我对goroutine的进一步理解是通过这篇 http://morsmachine.dk/netpoller, 因为之前对epoll有些懂(只看过一点点科普文章),所以看这篇文章的时候我没怎么看懂,但是看懂了他说的问题,调用epoll按道理说一般是阻塞的,阻塞的情况下 scheduler 会将 M 拿走,将阻塞的 P 扔给 os thread,那么这种情况下如果有成千上万个 链接过来,那么将有成千上万个 os thread被申请,这样goroutine没有什么意义了,文章上解释了golang怎么做的,不过我看不懂,就这样我就开始了查找相关资料,包括goroutine schedule 和 epoll。 ### 我的学习发现 最后我发现 goroutine 的精髓是 用阻塞的写法(正常思维)实现异步代码(相对于未采用csp模型的语言),具体实现办法就是 non-block + goroutine, 相当于go标准库封装了大量阻塞操作为非阻塞,这样才可以利用goroutine进行调度,因为如果是 os 操作 M就阻塞了,goroutine没有操作空间,也失去了价值,不过因为 os 操作本身就很多不支持非阻塞操作的,所以goroutine也是无能为力的,比如Printf。 ### non-block+epoll 关于golang 网络库,我们看 net/http 标准库都是 直接 go server(),相当于来一个请求开一个goroutine,为什么golang的效率会比其他的好呢,因为golang底层用的是 epoll + non-block+et , et 代表边缘触发的意思,epoll选择et模式才可以非阻塞(幸亏epoll 有这个模式),而且效率比LT会好一些,具体自己看吧。在 epoll 函数进行wait的时候 会在 goroutine层面park而不是os层面阻塞,这样就利用了goroutine的特点,所以即使我不测试我也知道 node.js 那种异步调用的方法不会比golang好(特别是多核情况下),因为node.js 那种单线程异步模型 好处是不用开很多thread,资源消耗少,但是goroutine 随便一开几十万个毫无压力,选择js做后端的我实在想不懂怎么想的,只有一个理由就是让前台写js的来做后台开发,只是从人力成本角度考虑,不过话说回来真的会降低成本吗? ### goroutine的资源支撑 以上都是从逻辑角度说的goroutine是如何提高IO效率的,这一切的一切的支撑是goroutine的资源消耗少,上下文切换快,不过我不想说这部分了,感觉没啥搞头,对于我来说我只要看看科普理解就行了,也没必要深究,资源上主要就是先申请小内存,然后不够了大点,在大点。</br> 我感觉我对goroutine的理解算是到位了,希望有NB大神在给我指点指点,看不懂我在写什么的同学一定要自己弄懂(也可以评论,我会回答的),不然不好意思说用golang哦

有疑问加站长微信联系(非本文作者)

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:701969077

2141 次点击  
加入收藏 微博
3 回复  |  直到 2016-07-10 10:18:43
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传