NIO开发错误

ERROR - com.utstar.omco.nml.mpls.intf.LspSyncCheckProcessor - com.utstar.omco.nml.mpls.intf.LspSyncCheckProcessor@a7e66b
   Sync check LSP begin at: Wed Jan 08 20:26:32 CST 2014
ERROR - com.utstar.omco.nml.mpls.intf.UILspMgrRemoteImpl$1 - com.utstar.omco.nml.mpls.intf.UILspMgrRemoteImpl$1@8bca78
   Sync check 0 lsps cost time 234 ms.
ERROR - com.utstar.omco.nml.mpls.intf.PwSyncCheckProcessor - com.utstar.omco.nml.mpls.intf.PwSyncCheckProcessor@2223ed
   Sync check PW begin at: Wed Jan 08 20:28:32 CST 2014
ERROR - com.utstar.omco.nml.mpls.intf.PwSyncCheckProcessor - com.utstar.omco.nml.mpls.intf.PwSyncCheckProcessor@2223ed
   Sync check PW end at: Wed Jan 08 20:28:33 CST 2014
ERROR - com.utstar.omco.nml.mpls.intf.UIPwMgrRemoteImpl$1 - com.utstar.omco.nml.mpls.intf.UIPwMgrRemoteImpl$1@1372938
   Sync check 0 pws cost time 3688 ms.
Exception in thread "Reactor" java.lang.OutOfMemoryError: Java heap space
at java.nio.HeapByteBuffer.<init>(Unknown Source)
at java.nio.ByteBuffer.allocate(Unknown Source)
at com.utstar.omco.jnti.imp.tcp.TCPLink.handleOutput(TCPLink.java:341)
at com.utstar.omco.jnti.imp.tcp.Reactor.handleEvent(Reactor.java:351)
at com.utstar.omco.jnti.imp.tcp.ThreadReactor.run(ThreadReactor.java:66)
at java.lang.Thread.run(Unknown Source)
ERROR - com.utstar.omco.nml.cesvc.intf.CeSyncCheckProcessor - com.utstar.omco.nml.cesvc.intf.CeSyncCheckProcessor@623808
   Sync check CE begin at: Wed Jan 08 20:30:32 CST 2014
CRITICAL - com.utstar.omco.nml.cesvc.intf.UICeMgrRemoteImpl$1 - com.utstar.omco.nml.cesvc.intf.UICeMgrRemoteImpl$1@f4908c
   Sync check 0 ce cost time 453 ms.

当我在client端，for循环多次登录server服务器的时候，会出现上面的错误。

查看出错的方法

public int handleOutput()
	{
		long _t1 = 0;
		boolean isPrint = false;
		if (null == m_sendBuf || ( /*m_sendBuf.head.remaining() <=0 &&*/ m_sendBuf.content.remaining() <= 0))
		{
			if (m_sendBuf == null)
			{
				shead = ByteBuffer.allocate(Packet.HEAD_SIZE);
				if(srv) scontent = ByteBuffer.allocate(L_BFS);
				else scontent = ByteBuffer.allocate(S_BFS);
				m_sendBuf = new Packet(shead, scontent);
			}

			MsgInfo m = m_session != null ? m_session._sendMsg() : null;
			if (m == null)
			{
				m = m_session != null ? m_session._sendMsg() : null;
				if (m == null)
				{			
					clrOP(SelectionKey.OP_WRITE);
					return 0;
				}
			}

			long _t0 =  System.currentTimeMillis();
			try
			{
				m_sendBuf.fromMsg(m);
			}
			catch (RuntimeException e)
			{
				Debug.logOut(Debug.ERROR, this, e);
				return -1;
			}
			
			_t1 = System.currentTimeMillis();
			isPrint = (_t1 - _t0 > 500);

public static final int L_BFS = 20 * 1024 * 1024;

java.nio中引入了一个主要的类：ByteBuffer，来做这件工作。（我的直觉是它应当和ACE的MessageBlock感化很像，然则厥后发明接口悬殊。）
ByteBuffer是一个笼统类，它有两种完成：HeapByteBuffer 和 DirectByteBuffer。java.nio.ByteBuffer.allocate(int)返回的是HeapByteBuffer，java.nio.ByteBuffer.allocateDirect(int)返回的是DirectByteBuffer。
HeapByteBuffer分配在jvm的堆（如重生代）上，和别的工具同样，由gc来扫描、收受接管。DirectByteBuffer则是经过底层的JNI向C Runtime Time经由过程malloc分派，在JVM的GC所办理的堆以外。
上面会商HeapByteBuffer。
每一个HeapByteBuffer外部有一个byte[]存储数据。这个byte[]在机关HeapByteBuffer的时间分派好，长度不会主动增加。
HeapByteBuffer内部有四个指针(offset)：
capacity：核心这个byte数组的巨细(byte[]的length)。
mark:相称于书签，初始值为-1。需要配置的时候mark()一下，需要跳归去的时候用reset()要领。
position：指向下一个读取/写入地位。初始值为0，读/写 数据的时刻主动今后挪这个指针。
limit:初始值即是 capacity。
它们一直知足如许的干系：mark
flip操纵：用在读写操纵转换的时辰。
limit = position;
position = 0;
mark = -1; //清算掉书签
示例用法：
buf.put(magic); // 先往buffer内里写入一个包头(packet header)
in.read(buf); // 然后从另一个input stream中读入包体，并写入到buffer中
buf.flip(); // Flip buffer。适才是往ByteBuffer里写数据，下面要转换成读数据。
out.write(buf); // 把全部buffer里的有用数据（包头+包体）读进去，写入output stream中。
但是调用这个方法以前必然要注重，不要多挪用了一次。好比，把下面的第三行代码复制一遍，那么
buf.put(magic); // 先往buffer里面写入一个包头(packet header)
in.read(buf); // 然后从另一个input stream中读入包体，并写入到buffer中
buf.flip(); // Flip buffer。position=0。
buf.flip(); // Flip buffer。limit=0！
out.write(buf); // 甚么也不会写入。
假设让你实现一个readfile这样的函数，你会在函数的末端调用buf.flip吗？
void readfile(File f,ByteBuffer bb){
f.read(bb);
bb.flip(); //Do it or not do it ? That’s a question。
}
你会在这个函数的接口解释那边说“我没挪用flip!!!”吗？
ByteBuffer的toArray()？