@GuuJiang 你作为一个旁观者，可能 会忽略 那四个字，因为他不是在喷你。 所以你的注意力会在 他指出的问题上，因为这个问题跟你产生了一定的共鸣。

但是，我连续熬夜 2 个多星期 做出来的一个项目，他说我自娱自乐，你觉得我能忍吗？

我跟你聊了那么多个来回，甚至我都明确回复了 [没数据确实是个问题，非常感谢] 我都这样回你了，你居然还以为我不知道这个问题。 我心里苦啊。

你最后那句 [正确认识自己确实不是一件容易的事] 让我有点寒心。

@GuuJiang 我知道是同一个问题， 我反驳他是因为他 出言不逊， 我反驳的是他的不尊重，而不是 他指出的问题。

如果他后面不加那句“自娱自乐” 我是不会反击他的。 反倒是他自己，连续三次 在最后 说出了“自娱自乐”这三个字，及其的不尊重人。 就这样 还指望我能用好态度对他啊。

但是你指出的问题，我已经在修复中了，甚至有可能会彻底改变架构，对你我是表示感激的。

@GuuJiang

还有一点，对于你说的 网络层和协议层， 为什么你不这么看待呢？ NIO 就是网络层啊，而我写的这个东西就是协议层啊。

可能我在对他的定位 用词不当，导致你把他当做一个网络层来看待了，所以觉得这个架构 很荒谬。

你不妨就把他当做你口中的协议层， 他就是一个协议层， 基于 NIO 开发的一个服务器，支持 http，websocket，UDP 三种请求方式，仅此而已。 就是 NIO 到应用层的 一个中间的 数据解析工具。

@GuuJiang 而且你也看一下这个项目的创建时间，这才写了几天哦。

@GuuJiang

有问题就改嘛，直到成熟为止。什么东西不是一点点积累起来的呢，至于你说越走越偏 那基本是不可能的，因为错的东西总会有暴露的时候，暴露出来后 我就会立刻去改。 我想不会有人来捧我这个 素不相识的人吧？ 所以那种温水煮青蛙的情况 你大可不必担心。

我发出来就是为了 有你这样的人可以给我指点， 所以你不必为我听得进去而感到惊讶。

然后可能我对这个东西的定位 跟 真正的网络包 产生了冲突， 这个应该是用词不当带来的问题。 我对这个项目的定位就是一个 支持 http，udp，webwocket 的 服务包， 我从来就不是走的 netty 的那条路，netty 应该是 二次封装后的底层，可以比喻成 BIO,NIO,AIO 之后的又一个 IO （虽然那他是基于 NIO 的）。 但是我做的这个是偏应用层的，你可以看做是一个 极其微小的 tomcat，jboss 等。 所以他不是你印象中的那种网络包，只是我用词不当导致的。

最后，你说线程池 是错的，我有点不敢苟同， 如果你把每个线程看作一台服务器，吧往队列里丢任务的那个进程看做是 nginx，你就大概明白这个思路了。 如果这个算错误，那负载均衡不也是错的？ 有些服务器可能收到的请求比较轻松他执行的很快，有些服务器收到请求比较大 执行缓慢，不也会导致部分服务器被堵死吗？ 所以负载均衡这种架构也是错的吗？

这个问题，我觉得加一个超时控制，或者把线程和队列分开？ 让空余线程来轮询或者随机消费其中一个队列？ 优化一下就好了嘛，只是一个有 bug 的东西，不至于彻底否认吧。

有问题就改问题，所以 你如此的语重心长，苦口婆心 ，我是听进去了，但你不至于这样，这只是一个有 bug 和设计缺陷的不成熟项目而已， 改就是了。

而且版本号你也应该看过吧，1.1.5, 这才哪到哪，现在基本只是处于一个能跑的状态，你对他的期望值过高 也是我们产生矛盾的 一个点。

@D3EP 然后你再看一看 parsingByByteBuffer 这个方法里 是怎么判断 该不该停止的，去看看吧。好吗？

求你认真看完 再喷。 不要为了喷去看代码，而是看了代码发现了槽点 再来提。

你现在的这种心态就是 找茬，根本不是真心了解这个项目。

我是哪得罪你了吗？ 要你如此大费周章的 找我茬 来喷我？

@D3EP 一个 http 请求至少 有第一行的三个符号 以及部分请求头，channel 会没数据吗？ 你这个空转怎么得来的？

喷也要 有点技术含量好吧？

@D3EP

空转？？ 除非 channel 里没数据。否则怎么会空转？ parsingByByteBuffer 这个方法被你吃了？

每次读出来的数据 不会超过 readBuffer 的长度， 你发送一个 http 请求 数据大小如果超过缓冲区长度，你一次能读完吗？ 不得多读几次？ 连这个 while 的意思都看不懂？？？？

@D3EP 空转？？ 除非 channel 里没数据。都这怎么会空转？ parsingByByteBuffer 这个方法被你吃了？

@guyeu

又发现个不足点， 非常感谢。

@GuuJiang 对， 如果数据没有发送确实是个问题。

我再来优化一下吧。 非常感谢。

@GuuJiang 问题是 已经有个业务线程在读写他了， 如果再读写一次直接抛异常， 而且也不该 被多个线程读写吧。

请求来了，业务线程工作了， 结果你又叫别的业务线程来处理这个 channel， 有点不合逻辑吧。

不过这个思路我可以研究一下。

然后，http 的读 我是根据 content-length 来判断读没读完的，所以一旦开始了 read 就会读到结束。 否则就会一直读。

websocket 也是根据长度判断的，但是同一个通道 会有很多数据进来，如果发送太快会发生粘包问题， 这个我也在想办法处理。

@GuuJiang

accept 确实是阻塞住的， 对于防止空转 我还是很重视的， 自测过好几次。

因为 block 设置为 false 我是设置在 socketChannel 上的，

而我监听的是 serverSocketChannel 的 accept 方法 这个的 block 我设置的是 true 。

@GuuJiang

remove 是有的， 不是 selectionkey 这个集合里 有重复数据， 而是再次执行 selector.select （） 方法后 重新获取的 selectionkey 集合里 有正在被处理的 channel，

while （ true ）｛
selector.select （）；

while （）｛
如果这里开了线程，内部这个 while 没问题， 但是等内部 while 结束后， 外部 while 开始下一次循环后， 获取到的那个新的 selectionkey 里会有正在处理的 channel
｝
｝

一开始我就是用的 选择器， 如果在 while 里开线程能解决问题，我还这么大费周章干嘛呢。

而且 UDP 我也是用的选择器， 因为不用响应，我可以同步读完后，用线程去处理 handler 。

accept 是在有连接进来的阶段。 选择器里如果发现了 这个状态的 key 不就会立刻注册成 op_read 状态吗？ 代表可以读了

然后你也不用道歉，我那个帖子是怼那两个喷子的， 并不是针对你，对于正确讨论的人 我很少闹情绪。 今天白天 主要是你一上来看错了代码，我才那样的。