netty的使用记录

最近做一个项目，第一次接触到netty,使用之前就听说过netty的高性能，在做这个项目中也有一些体会，但对netty的理解仍然还不是很清楚...

netty的高性能原因之一在于采用的是异步非阻塞通讯/IO多路复用，通过把多个IO的阻塞复用到同一个select的阻塞上，从而使得系统在单线程的情况下可以同时处理多个客户端请求。与传统的多线程/多进程模型比，I/O多路复用的最大优势是系统开销小，系统不需要创建新的额外进程或者线程，也不需要维护这些进程和线程的运行，降低了系统的维护工作量，节省了系统资源。

同时，netty采用reactor线程模型：boss线程就相当于mainReactor，负责监听server socket，accept新连接，并将建立的socket分派给subReactor。subReactor负责多路分离已连接的socket，读写网 络数据，因为ChannelHandler链的执行过程是在 subReactor中同步的，所以如果业务处理handler耗时长，将严重影响可支持的并发数,对业务处理功能，其扔给worker线程池完成。

所以基于netty的开发，重点在对业务处理线程池的开发，但是却遇到不少的问题。

多线程的并发处理 导致逻辑混乱。在并发测试的过程中，导致执行的顺序和数据混乱了，每个客户端连接后的逻辑流程并未像事先设定的流程那样。通过调试，发现因为多线程的问题导致有些操作执行了多次。最后慢慢理流程，把几乎所有的业务处理的执行的方法都加上了锁synchronized，执行完立即改变执行状态，每次执行前也先判断执行状态。这样并发重复执行的问题基本上算是解决了。

上述问题解决了之后，又有新问题，就是因为上锁的原因，线程池在执行的过程中阻塞情况却比较严重，上线玩家4000，但是最终顺利执行完的玩家却总是只有39xx多，日志记录也没有报任何错误。然后又试了下把业务逻辑的线程池的线程数量改为1（即只有1个线程在处理业务逻辑），玩家上线4000，顺利执行的完的玩家也是4000。看来这个仍然是多线程资源竞争引起的...但至今尚未找到原因

将业务处理线程改为单线程，也有问题，就是在并发4000的样子，单线程处理一轮的用户请求可能忙不过来，因为服务器针对玩家处理的每个响应都有一个超时时间，所以单线程的时候后台的离线检测会检测到很多玩家响应超时了而把该玩家转为了离线用户（但其实玩家是即时响应了的，只不过单业务现象线程还没来得及处理）...

根据测试情况，单线程处理的综合效果最好，目前仍然是这种方式，但存在上述第三种情况...待以后解决

并发4000时，netty的nio线程还是比较空闲的，关键是自定义的业务处理线程阻塞情况比较严重。出现这种情况，就只能尽量去优化业务逻辑处理（如本例中优化了获取在线用户的方法，直接map.get代替for循环查找），减少处理时间，提高代码效率，同时，增加服务器的硬件配置（目前是在自己的开发电脑上测试的，4000 cpu基本上90%以上了）。

通过本次的开发也让自己对多线程的编程更加了解：1.对临界资源的使用，修改\获取时synchronized，synchronized的位置也非常重要；2.同步，wait\notify；3.volatile。同时对reactor的主从模型的也可以运用到以后的很多方面来提高性能。