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()？