skynet服务的设计
统观整篇文章，不难发现：
每个skynet服务都是一个lua state，也就是一个lua虚拟机实例。而且，每个服务都是隔离的，各自使用自己独立的内存空间，服务之间通过发消息来完成数据交换。
架构图如下：
图片取自spartan1的skynet任务调度分析
lua state本身没有多线程支持的，为了实现cpu的摊分，skynet实现上在一个线程运行多个lua state实例。而同一时间下，调度线程只运行一个服务实例。为了提高系统的并发性，skynet会启动一定数量的调度线程。同时，为了提高服务的并发性，就利用lua协程并发处理。
所以，skynet的并发性有3点：
1、多个调度线程并发
2、lua协程并发处理
3、服务调度的切换
skynet服务的设计基于Actor模型。有两个特点：
1. 每个Actor依次处理收到的消息
2. 不同的Actor可同时处理各自的消息
skynet服务的缺陷
并发问题
这要从skynet一个服务霸占调度器的极端例子说起。
-- main.lua local skynet = require "skynet" skynet.start(function() print("Server start") skynet.newservice("simpledb") -- 发消息给simpledb服务 skynet.send("SIMPLEDB", "lua", "TEST") -- 死循环占据cpu local i = 0 while true do i = i>100000000 and 0 or i+1 if i==0 then print("I'm working") end end skynet.exit() end)-- simpledb.lua local skynet = require "skynet" require "skynet.manager" -- import skynet.register local db = {} local command = {} function command.TEST() print("Simpledb test") return true end skynet.start(function() print("Simpledb start") skynet.dispatch("lua", function(session, address, cmd, ...) local f = command[string.upper(cmd)] if f then skynet.ret(skynet.pack(f(...))) else error(string.format("Unknown command %s", tostring(cmd))) end end) skynet.register "SIMPLEDB" end)配置文件 configroot = "./" thread = 1 logger = nil logpath = "." harbor = 1 address = "127.0.0.1:2526" master = "127.0.0.1:2013" start = "main" bootstrap = "snlua bootstrap" standalone = "0.0.0.0:2013" luaservice = root.."service/?.lua;"..root.."test/?.lua;"..root.."examples/?.lua" lualoader = "lualib/loader.lua" snax = root.."examples/?.lua;"..root.."test/?.lua" cpath = root.."cservice/?.so"
注意了，这里特地把 thread 设置为1，表示只启动一个调度线程。
现在，启动skynet执行我们的例子，结果如下：可以看出，simpledb 没有机会处理TEST消息，一直是main模块占据着cpu。
这和skynet的调度机制有关。skynet使用全局队列保存了要调度的服务，调度算法是先来先服务。如果某个服务有新消息，就把这个服务加到调度队列中，然后等待调度线程调度。而skynet服务的调度切换依赖于协程的挂起，如果当前调度的服务没有主动挂起或退出，就会一直执行，不调度其他服务了。
这种机制的好处就是实现简单，有利于长作业，上下文切换较少，缺点就是并发效率低，而且像这种长作业的服务超过调度线程数量，就可能导致其他服务饿死。内存隐患
细心的同学会发现，在服务处理新消息时，是通过创建新协程来处理的（见co_create），虽然协程会被重复利用，但在当前版本下，这种不断创建协程来消息的方式本身存在不稳定因素：
1、协程只增加不减少，意味过了某个并发高峰后内存不会降下来。
2、创建协程也有一定开销，容易触发GC，也占用内存，协程的数量规模不容易控制
3、如果解决第1点，最槽糕的情况是，不断要创建协程，不断要销毁协程，频繁触发gc
这里有一个极端的例子：
如果服务a不断给服务b发消息，但服务b的处理过程存在长时间挂起，这样，对于服务a发来的消息，服务b会不断创建协程去处理，就导致内存被大量占用的情况出现。
但是skynet也提供办法解决这个问题，方法是主动调用GC：
skynet.send(service,"debug","GC")
另外，有兴趣的同学，不妨看下实现代码：
-- debug.lua return function (skynet, export) -- 处理 GC 消息 function dbgcmd.GC() export.clear() -- export 是 skynet.debug 的传入参数 collectgarbage "collect" -- 执行GC end local function _debug_dispatch(session, address, cmd, ...) local f = (dbgcmd or init_dbgcmd())[cmd] -- lazy init dbgcmd f(...) end skynet.register_protocol { name = "debug", -- 注册处理服务收到的 "debug" 消息 id = assert(skynet.PTYPE_DEBUG), pack = assert(skynet.pack), unpack = assert(skynet.unpack), dispatch = _debug_dispatch, } end而什么时候调用了 skynet.debug 呢？看这里
-- skynet.lua local function clear_pool() coroutine_pool = {} -- 清空协程的引用 end -- debug设置回调处理函数 local debug = require "skynet.debug" debug(skynet, { dispatch = skynet.dispatch_message, clear = clear_pool, suspend = suspend, })就是说，但给服务发送GC消息时，就会清空协程池，随后执行底层GC接口。这样，不再有内容引用到这个协程，所以，协程会在GC时被清理。
至于协程只是挂起没有结束，为什么会被清理？
因为从协程池移走后，那些协程就变成了不可达的协程了，没有方法能 coroutine.resume 激活他们了，所以就会被gc掉。
同步问题
同步也是skynet存在的问题，当一个服务call其他服务时，当前协程会挂起，但是这个服务还可以接受并处理其他消息。如果多个协程改到同一个数据，你不做同步处理就无法确定这个数据会是多少。
这样的例子特别常见，比如，服务正当处理玩家login请求，刚好遇到call挂起，这时候又有新的请求到来，比如logout，服务就会转去处理logout消息。那玩家究竟是login，还是logout？
参考：http://blog.csdn.net/mycwq/article/details/47379277