1,ByteBuffer.allocate 使用的是堆内内存,改为ByteBuffer.allocateDirect可以利用零拷贝提高性能
2,循环读取没必要全部读完,全部读完再处理有OOM的风险,可以读一部分就开始处理,具体的“拆包”逻辑可以交由具体基于TCP的协议解析器负责
3,
这个位置不会抛出异常,没必要try…catch
public TCPServer(EventGroup ioEventGroup, EventGroup workerEventGroup) {
try {
this.ioEventGroup = ioEventGroup;
this.workerEventGroup = workerEventGroup;
this.tcpServerConfig = new TCPServerConfig();
} catch (Exception e) {
log.error("打开serverSocketChannel,出现异常", e);
}
}
4,
EventGroup下面的所有EventRunner都公用一个线程池,建议中间这几个都删了,改为forkjoin线程池直接提交吧,也自带工作窃取
5,TCP server读,写,连接都在单线程中,瓶颈较大,可以尝试改为连接绑定某一线程单线读写,单线程做连接处理
这一段可以加入作为while的条件
if(ioEventGroup.getThreadPool().isShutdown()){
logger.error("ioEventGroup里的线程池关闭了,所以Selector也停止了");
selector.close();
serverSocketChannel.close();
return;
}
6,TCPServerMonitorTask#run()最后一行
我认为没有意义,这个操作是外部线程触发使得当前selector持有线程从select的阻塞 中唤醒,自己调用时已经是唤醒状态
7,TCP server是否与协议解析绑定太深?
8,EventLoop是个很好的模型,可以参考一些EventLoop的实现