Cindy 3.0中的Buffer设计

 

俗话说兵马未动，粮草先行，Cindy 3.0版本连影子还没见着，Blog倒是放出了好几篇……

 

为了以示区分，nio的ByteBuffer我简称为NB，cindy的Buffer我简称为CB。

 

现在对NB的理解比上次写 Redesign Buffer 这篇Blog时要更深入一些，所以在CB的设计上观念有了一些变化：

• 类似ByteArrayOutputStream/ByteArrayInputStream，容量不是固定的，可以自动扩展

如果CB容量是不固定的，则在自动扩展时需要进行内存拷贝，并且在实现中判断是否需要进行扩展会有许多额外的判断，还无法精确匹配应用的需求，降低了效率；但是对于某些特定的应用，该功能确实能带来一些便利。

所以在目前的设计中，CB的自动扩展并不是CB体系的一个基本功能，仅仅为一个特定实现。除了该实现外，其余的CB都不是自动扩展的，还是固定的capacity。

• 在早期的Cindy 3.0实现中，曾提供了一种WrappedBuffer的CB实现，可以把NB数组包装成一个单一的CB，现在该实现被取消

在我前面一篇Blog中可以看出，大部分应用在如果没有自己实现NB pool，正常情况下应该实例化成Non-direct NB，可是Non-direct NB聚集读写要比非聚集读写效率低。所以WrappedBuffer看上去节约了内存拷贝时间，可实际在写入和读取的时候要实例化不缓存的临时 Direct NB，反而降低了速度。

• 加入一种LinkedBuffer的CB实现，和WrappedBuffer不同的是，LinkedBuffer链接的是CB，而WrappedBuffer链接的是NB

这种特殊类型的Buffer其实并不是为应用准备的，而是为Cindy中的Session MessageRecognizer准备的。

在Cindy 2.x中，读数据的流程是（2.x还没有CB的设计）：

网络 --> Session内部缓存的NB --> MessageRecongizer读出数据识别成Message --> 应用

可以看到，对于应用直接从网络中读取数据，中间多了一层内存拷贝（先拷贝到Session内部缓存中，再到应用）。但是通过这一间接层，把所有的网络情况处理和异常处理都交给框架来处理了，减少了应用的负担，所以多出来的这一层的好处大于坏处。

在Cindy 3.x中，由于Filter机制，读数据的流程是：

网络 --> 读出的CB块 --> 一系列的Filter转换后的CB块 --> Session内部缓存的CB，把读出来的CB块重组 --> MessageRecongizer读出数据识别Message --> 应用

可以看到，相对Cindy 2.x来说，引入了许多间接层。那么效率能否不降低呢？

首先在默认情况下，内置的Filter不会转换读出的CB块（除非你自己加入特定的Filter，如SSLFilter，把收到的数据包解密给普通数据包），所以在Filter转换后的CB块和原来的CB块是同一个，没有额外的开销。

Session内部的CB将收到的一系列CB块重组（比如TCP连接，第一次收到了 abc，MessageRecognizer没有识别出来，第二次收到了def，这次收到的def应该加在abc后面，即abcdef，再让 MessageRecongizer识别），如果还是采用原始的设计，在这个地方就多了一次内存拷贝，而且如果缓存容量不够的话，还得重新生成一个容量足 够的CB，再把收到的一系列CB放进去，效率肯定会有所降低。这个时候就是LinkedBuffer发挥威力的地方。

LinkedBuffer把收到的CB包连接起来，对外看上去好像只有一个CB，不需要进行内存拷贝，也不会有缓存容量不够的 情况出现（因为仅仅是把若干个CB链接起来）。MessageRecongizer直接从LinkedBuffer中读入数据，等到某CB块上的数据被 Message读入完毕后，再把该CB块从链上去掉即可。

所以即使中间多了两层，但是效率仍然不会降低。更何况中间多加的两层具有非常好的可扩展性，极端情况下，你甚至可以在Filter这一层就把接收到的CB直接拿出来使用，而不传给后面的Filter，这样连Cindy 2.x中那一次内存拷贝都省了：）

 

在最后说一个不是太好的消息。原计划12月底发布3.0 a1版，现在看来是来不及了，甚至连Reactor模型我都还没由HSHA改成LF……况且月底圣诞、元旦两个比较大的节日，还是要多去享受享受生活的……

在此向各位关注Cindy的朋友们致歉，这个版本应该会在1月中旬出来的，到时还请多多提一些建设性意见：）