在Apache MINA 2.0.0-M1 试用体会 里我提到了使用 org.apache.mina.transport.socket.apr.AprSocketAcceptor
代替 org.apache.mina.transport.socket.nio.NioSocketAcceptor 遇到的问题,
后来在 AprIoProcessor的 protected int read(AprSession session, IoBuffer buffer) 和
protected int write(AprSession session, IoBuffer buf, int length)方法里加上了System.out，然后瞎改代码，
后面终于看到错误码为：-120002 和-730054,在网上google一番，也没有头绪，后面静下心来，增加对IoBuffer的方法调用，
慢慢摸索。
联想到前面ProtocolDecoder所犯下用把while用成if的错误，想想这么容易出现问题的话，应该不是bug，Trustin Lee 这样的牛人不可能留下这么大的bug就发布 Apache MINA 2.0.0-M1。
通过多次定位，终于发现了问题所在，
我在 ProtocolEncoder的 public void encode(IoSession session, Object message,
ProtocolEncoderOutput out)里面写了
IoBuffer buf = IoBuffer.allocate(16, true);
这行代码最终调用的是ByteBuffer.allocateDirect这个方法：
参考：
http://gceclub.sun.com.cn/Java_Docs/jdk6/html/zh_CN/api/java/nio/ByteBuffer.html#allocateDirect(int)
先前瞎迷信自以为 直接字节缓冲区 的性能会好些，而且先前使用IoBuffer.allocate(16, true);时就曾经遇到过服务端返回的内容不对头的问题，可惜当时没在意，就半罐子水折腾。
再仔细阅读 javaDoc里的说明：
直接与 非直接缓冲区
字节缓冲区要么是直接的，要么是非直接的。如果为直接字节缓冲区，则 Java 虚拟机会尽最大努力直接在此缓冲区上执行本机 I/O 操作。也就是说，在每次调用基础操作系统的一个本机 I/O 操作之前（或之后），虚拟机都会尽量避免将缓冲区的内容复制到中间缓冲区中（或从中间缓冲区中复制内容）。
直接字节缓冲区可以通过调用此类的 allocateDirect 工厂方法来创建。此方法返回的缓冲区进行分配和取消分配所需成本通常高于非直接缓冲区。直接缓冲区的内容可以驻留在常规的垃圾回收堆之外，因此，它们对应 用程序的内存需求量造成的影响可能并不明显。所以，建议将直接缓冲区主要分配给那些易受基础系统的本机 I/O 操作影响的大型、持久的缓冲区。一般情况下，最好仅在直接缓冲区能在程序性能方面带来明显好处时分配它们。
allocateDirect
public static ByteBuffer allocateDirect(int capacity)
- 分配新的直接字节缓冲区。 新缓冲区的位置将为零，其界限将为其容量，其标记是不确定的。无论它是否具有
底层实现数组，其标记都是不确定的。 -
- 参数：
capacity– 新缓冲区的容量，以字节为单位- 返回：
- 新的字节缓冲区
- 抛出：
IllegalArgumentException– 如果 capacity 为负整数
再看相关代码：
ByteBuffer 的代码节选:
[code]
public static ByteBuffer allocateDirect(int capacity) {
return new DirectByteBuffer(capacity);
}
[/code]
DirectByteBuffer 的代码节选：
[code]
DirectByteBuffer(int cap) { // package-private
super(-1, 0, cap, cap, false);
Bits.reserveMemory(cap);
int ps = Bits.pageSize();
long base = 0;
try {
base = unsafe.allocateMemory(cap + ps);
} catch (OutOfMemoryError x) {
Bits.unreserveMemory(cap);
throw x;
}
unsafe.setMemory(base, cap + ps, (byte) 0);
if (base % ps != 0) {
// Round up to page boundary
address = base + ps - (base & (ps - 1));
} else {
address = base;
}
cleaner = Cleaner.create(this, new Deallocator(base, cap));
}
private Deallocator(long address, int capacity) {
assert (address != 0);
this.address = address;
this.capacity = capacity;
}
public void run() {
if (address == 0) {
// Paranoia
return;
}
unsafe.freeMemory(address);
address = 0;
Bits.unreserveMemory(capacity);
}
}
[/code]
可以看到java使用的是本地方法在管理相对应的内存：
public native long allocateMemory(long _long);
public native void setMemory(long _long, long _long1, byte _byte);
public native void copyMemory(long _long, long _long1, long _long2);
public native void freeMemory(long _long);
而Apr也是使用本地方法管理内存，可能这里目前存在一些没处理好的地方，因此导致了我遇到的问题。，
避免这个问题的办法就很简单了
direct使用false,即 ProtocolEncoder 中使用 IoBuffer buf = IoBuffer.allocate(16, false);。
当然 AprIoProcessor，的write方法已经做了buf.isDirect() 这样的判断，按理说是可以使用DirectByteBuffer的，
在没有完全明白其中缘由前，暂时先慎用ByteBuffer.allocateDirect以避免产生问题。
Tags: apache mina, APR, nio