首页 > 代码库 > 关于协程的学习 & 线程栈默认10M
关于协程的学习 & 线程栈默认10M
先看的这篇文章:http://blog.csdn.net/qq910894904/article/details/41699541
以nginx为代表的事件驱动的异步server正在横扫天下,那么事件驱动模型会是server端模型的终点吗?
我们可以深入了解下,事件驱动编程的模型。
事件驱动编程的架构是预先设计一个事件循环,这个事件循环程序不断地检查目前要处理的信息,根据要处理的信息运行一个触发函数。其中这个外部信息可能来自一个目录夹中的文件,可能来自键盘或鼠标的动作,或者是一个时间事件。这个触发函数,可以是系统默认的也可以是用户注册的回调函数。
事件驱动程序设计着重于弹性以及异步化上面。许多GUI框架(如windows的MFC, Android的GUI框架),Zookeeper的Watcher等都使用了事件驱动机制。未来还会有其他的基于事件驱动的作品出现。
基于事件驱动的编程是单线程思维,其特点是异步+回调。
协程也是单线程,但是它能让原来要使用异步+回调方式写的非人类代码,可以用看似同步的方式写出来。它是实现推拉互动的所谓非抢占式协作的关键。
总结
协程的好处:
- 跨平台
- 跨体系架构
- 无需线程上下文切换的开销
- 无需原子操作锁定及同步的开销
- 方便切换控制流,简化编程模型
- 高并发+高扩展性+低成本:一个CPU支持上万的协程都不是问题。所以很适合用于高并发处理。
缺点:
- 无法利用多核资源:协程的本质是个单线程,它不能同时将 单个CPU 的多个核用上,协程需要和进程配合才能运行在多CPU上.当然我们日常所编写的绝大部分应用都没有这个必要,除非是cpu密集型应用。
- 进行阻塞(Blocking)操作(如IO时)会阻塞掉整个程序:这一点和事件驱动一样,可以使用异步IO操作来解决
https://www.zhihu.com/question/32218874
协程方便是因为“用代码来表示状态,而不是维护一坨数据结构来表示状态”,则客观得多。
作者:Tim Shen 链接:https://www.zhihu.com/question/32218874/answer/56255707 来源:知乎 著作权归作者所有,转载请联系作者获得授权。 讲点历史吧。 早期的Unix时代崇尚同步编程,当时设计的时候也没多想,管他什么性能不性能,先做出来再说。所以最开始人是开多进程(process)再用管子(pipe)连接起来的;多直观啊,我把东西推进管子里,你走你那头接一下。 不知道哪天人注意到开个千儿八百个进程机器就卡死了,这怎么行,所以我们只搞一个进程,里面有一坨打开的网络连接和文件,用select这个系统调用对io事件同时进行监听,谁先来我就处理谁。然而发现性能也不好,没什么卵用。 人们在这两条路上都想办法提升性能。进程这边人们又搞了多线程,结果还是不够。多线程还是吃内核资源,抗不住。 Linux忍不住了,搞出个epoll(不过我不知道和bsd的kqueue哪个在前)系统调用,就是红黑树改良版的select。这下子人开心了,真他妈快啊,开千儿八百个连接小意思,同时进行事件监听,判断连接的的id和事件的类型,再打(dispatch)到不同的回调函数里。 不知是不是市场原因,正巧这时候互联网开始火了,性能越好赚钱越多嘛,所以肯定来这套高效的接口,管他好不好用呢,反正俺们吃苦耐劳,外加抖M,才不怕手动维护状态。你多线程开太多最后不也是要手动维护状态。 不熟悉操作系统的开发人员们只知道有什么用什么,也没去多想怎么优化多线程。现在多线程优化出来了,叫协程,调度器有的有(比如go的用户态调度器)有的没有(比如yield),取决于怎么用。其内存开销仍然比异步回调要大(一个协程一个栈,而异步回调的话一个event loop一共就一个栈),但是现在内存也是便宜了,不算是瓶颈。人最关注的是“千万不能堵着(block)”,要千方百计让CPU转起来,这样concurrency才能上去。而到处乱开协程(因为比线程便宜啊)就能达到这个效果,开十万个协程内存也没爆炸,跑上24个就能把CPU打满。所以异步回调的这个优势已经没了。
至于趋势什么的,也就赶个时髦吧,这些枝叶伎俩学学也要不了几个小时。如果是担心要花很多精力学习某个“技术”,又怕学了没用,故有“是不是趋势啊”这一问,那多半是根基不牢,打打基础就行了。
我是写C++的,我发现我唯一用callback/closure/lambda的地方是我有个函数,但是我想把这个函数扣个洞,让用户来填这个洞。用得还真不算多。
注:之前想学Java的时候,花了很多时间来了解趋势。现在想想,的确是瞻前顾后呀,学一下就知道趋势了,哈哈。
------另一个人的回答---------
有时候总觉得 gevent(python的一个库) 这类协程库是被 python 的 GIL 逼出来的,如果原生线程支持足够好,协程的必要性可能并不一定很大。
协程最早来自高性能计算领域的成功案例,协作式调度相比抢占式调度而言,可以在牺牲公平性时换取吞吐。
Node.js需要按顺序执行异步逻辑时一般采用后续传递风格,也就是将后续逻辑封装在回调函数中作为起始函数的参数,逐层嵌套。这种风格虽然可以提高CPU利用率,降低等待时间,但当后续逻辑步骤较多时会影响代码的可读性,结果代码的修改维护变得很困难。根据这种代码的样子,一般称其为"callback hell"或"pyramid of doom",本文称之为回调大坑,嵌套越多,大坑越深。
注:monkey patch可以看:http://www.tuicool.com/articles/2aIZZb
monkey patch指的是在运行时动态替换,一般是在startup的时候. (感觉大多数是Python程序的一种技巧) 用过gevent就会知道,会在最开头的地方gevent.monkey.patch_all();把标准库中的thread/socket等给替换掉.这样我们在后面使用socket的时候可以跟平常一样使用,无需修改任何代码,但是它变成非阻塞的了. 之前做的一个游戏服务器,很多地方用的import json,后来发现ujson比自带json快了N倍,于是问题来了,难道几十个文件要一个个把import json改成import ujson as json吗? 其实只需要在进程startup的地方monkey patch就行了.是影响整个进程空间的. 同一进程空间中一个module只会被运行一次. 下面是代码. main.py import json import ujson def monkey_patch_json(): json.__name__ = ‘ujson‘ json.dumps = ujson.dumps json.loads = ujson.loads monkey_patch_json() print ‘main.py‘,json.__name__ import sub sub.py import json print ‘sub.py‘,json.__name__ 运行main.py,可以看到都是输出‘ujson‘,说明后面import的json是被patch了的. 最后,注意不能单纯的json = ujson来替换.
1. 用户态栈,更轻量地创建“轻量线程”;
2. 协作式的用户态调度器,更少线程上下文切换;
3. 重新实现 mutex 等同步原语;
协程的创建成本更小,但是创建成本可以被线程池完全绕开,而且线程池更 fine grained,这时相比线程池的优势更多在于开发模型的省力,而不在性能。此外,"轻量线程" 这个名字有一定误导的成分,协程作为用户态线程,需要的上下文信息与系统线程几乎无异。如果说阻碍系统线程 scale 的要素是内存(一个系统线程的栈几乎有 10mb 虚拟内存,线程的数量受虚拟地址空间限制),那么用户态线程的栈如果使用得不节制,也需要同量的内存。
$ ulimit -s
10240
也就是10M;修改的方法如下:
linux查看修改线程默认栈空间大小 ulimit -s 1、通过命令 ulimit -s 查看linux的默认栈空间大小,默认情况下 为10240 即10M 2、通过命令 ulimit -s 设置大小值 临时改变栈空间大小:ulimit -s 102400, 即修改为100M 3、可以在/etc/rc.local 内 加入 ulimit -s 102400 则可以开机就设置栈空间大小 4、在/etc/security/limits.conf 中也可以改变栈空间大小: #<domain> <type> <item> <value> * soft stack 102400 重新登录,执行ulimit -s 即可看到改为102400 即100M
至于并发量导向的业务,一般也是状态上下文较少的业务,比如推送,这时 callback hell 基本可控,使用协程相比事件循环依然更容易编程,但效益并不显著。
最后尝试总结一下个人的想法:
协程不是趋势,它是一个在历史中被挖掘出来的、对现有问题的一个有用的补充。
适用的场景:
- 高性能计算,牺牲公平性换取吞吐;
- 面向 IO Bound 任务,减少 IO 等待上的闲置,这其实和高性能计算领域内的优势是一致的;
- Generator 式的流式计算;
- 消除 Callback Hell,使用同步模型降低开发成本的同时保留更灵活控制流的好处,比如同时发三个请求;这时节约地使用栈,可以充分地发挥 "轻量" 的优势;
- 如果栈使用得不节制,消耗的内存量和系统线程无异,甚至内存管理还不如系统线程(系统线程可以动态地调整虚拟内存,用户线程的 Segmented Stack 方案存在严重的抖动问题,Continous Stack 方案管理不当也会抖动,为了避免抖动则成了空间换时间,而内核在这方面做了多少 heuristic 呢);
- IO Bound 任务可以通过调线程池大小在一定程度上缓解,目标是把 CPU 跑满即可,这点线程池的表现可能不完美,但在业务逻辑这个领域是及格的;
- 此外,一般的 python/ruby 任务并不是严格的 IO Bound,比如 ORM 的对象创建、模版渲染、GC 甚至解释器本身,都是 CPU 大户;单个请求扣去 redis 请求和数据库请求的时间,其它时间是否仍不少呢?
- CPU 上长时间的计算,导致用户线程的调度变差,不能更快地响应,单个请求的平均时间反而可能更长(诚然并发可能更高);然而这在 python 这类 GIL 语言来看并不算劣势,甚至比 GIL 的调度更好,至少 gevent 可以知道各 IO 任务的优先级,而 GIL 的调度是事实上的 FIFO;
References
- Xiao-Feng Li: Thread mapping: 1:1 vs M:N
- http://thread.gmane.org/gmane.comp.lang.rust.devel/6479
关于协程的学习 & 线程栈默认10M