Grizzly NIO框架

Grizzly框架 貌似在国内没有中文文档，在这里个人因为项目使用了一段时间，在此编写一段简单的体验笔记，下图是官网首页的结构图，从中可以看到Core Framework（核心框架）中拓展了HTTP、AJP、SPDY、WebSocket……可以说非常强大，而且对我来讲它的IOStrategies（IO策略）是最关键的部分，针对不同的项目使用不同的策略，而MemoryManager则是最重要的部分，良好的内存管理可以减少GC，提高并发和响应速度。下面我们针对官网开放的资料进行一个个组件的学习，个人英文不是很好，还请见谅，哈

 

1、Memory Management Overview（内存管理）

Grizzly框架中的内存块基于Buffer接口，制定了两种内存管理器：

ByteBufferManager、HeapMemoryManager

ByteBufferManager是针对ByteBuffer的封装管理，一般如果使用direct bytebuffer的时候才会用。另外HeapMemoryManager是针对byte[]的管理。两者效率对比，是HeapMemoryManager的效率高。

另外在分配内存的策略上，做了线程池缓存的机制，提高复用率。

 

2、IOStrategies（I/O 策略）

 

Worker-thread IOStrategy.

该模式Selector专门负责消息接受和发送，Worker异步处理请求。注意，是消息的异步，而对于Worker线程，同一个连接的消息还是逐个处理，不会出现两个Worker线程同时接受同一个Connection的消息。在这种模式下，响应会收到影响，因为我的项目是做arpg游戏，所以没有使用这个模式。对于请求零散并且庞大、以及响应要求不高的情况下可以使用当前模式。

Same-thread IOStrategy.

直接在Selector线程接受消息的过程中处理消息，而Worker线程就没有使用，对于响应要求比较高的项目可以使用该模式，比如我的arpg项目。注意，不能在处理过程中使用耗时较长的逻辑，比如数据库操作。

Dynamic IOStrategy.

这是上面两个策略的结合版本，至于这个怎么用，个人暂时还没有什么想法。对于它的理念貌似挺好，但是实际效果就不清楚了，哈，希望有哪位大牛可以给点意见。

 

 

Leader-follower IOStrategy.

对于这个感觉和Worker线程没啥区别，只是增加了切换功能，Worker可以处理请求而变成Selector线程继续处理IOEvent