背景:
之前的 一篇介绍mina的博客中,提到通过mina来传输文件的demo,
具体的demo地址在这:
http://guoliangqi.iteye.com/blog/628063
当时的评论回复里面,有一个同学说用我的这个demo传输图片特别慢,是特别慢,不是慢。
我当时没在意就随手回了下,说nio对于传输这种单文件的优势并不明显。
但是我重新运行了这段代码,传输一个大概52K的图片的时候,真的很慢,差不多要30秒才传完,
当时我就震惊了,绝对是哪个地方不对导致的。于是就开始了一段找问题之路。
如果有兴趣看解决的过程的,可以看前面几个步骤,没兴趣的直接看最后的【正解&原因分析】吧
解决问题:
【算了,我自己都懒得写这个过程了!】
步骤一:
步骤二:
正解&原因分析:
问题出在使用的ObjectSerializationCodecFactory上,打开ObjectSerializationCodecFactory的源码,
查看在其编码的一段代码是这样写的。
public void encode(IoSession session, Object message,
ProtocolEncoderOutput out) throws Exception {
if (!(message instanceof Serializable)) {
throw new NotSerializableException();
}
//主要是这里
IoBuffer buf = IoBuffer.allocate(64);
buf.setAutoExpand(true);
buf.putObject(message);
int objectSize = buf.position() - 4;
if (objectSize > maxObjectSize) {
throw new IllegalArgumentException(
"The encoded object is too big: " + objectSize + " (> "
+ maxObjectSize + ')');
}
buf.flip();
out.write(buf);
}
可以看到这里,默认是用64bit来进行数据的解码,
而我的demo里面传输文件,用的是:
byte[] a = new byte[1024 * 4];
很明显,这个要比默认的那个64b长很多,导致内部需要进行频繁的操作之后,才能发送出去。
看到了这里,就修改了下以前用来传输的代码。
byte[] a = new byte[64];
然后再运行这个传输文件的demo,瞬间传输完。问题解决!
扩展:
后来看了下mina官方手册的,遇到这种问题,如果还需要传输大的字节数据,肯定不能用默认的这个ObjectSerializationCodecFactory来传输了,要么自己写一个继承他,修改下对应的decode方法,
要么自己来定义传输结构,重新进行codec的编写。
想要自己编写codec,可以参考这里:
http://mina.apache.org/tutorial-on-protocolcodecfilter-for-mina-2x.html