@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 状态吗？ 代表可以读了

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

@GuuJiang 接着上一条回复，

我重新回答一下这个问题吧： [在一个循环里依次对一堆 channel 进行 read”这个做法，相比起被你否定掉的 NIO，优势在哪里？]

你可以把我的模型 理解成，可以用配置来 决定同时有几个循环在 以此消费 selectionkey 。 把单线程变成了 可以指定数量的多线程。

说白了，NIO 的 while 相当于单机， 而我这个相当于负载均衡。 这个理解吧？

虽然 没有彻底异步， 也不可能彻底异步，否则就会出现一个请求一个线程 带来上下午切换的问题。 但他确实 解决了一些问题吧？

当然了，如果 NIO 有自带的 api 来做这件事， 你可以说出来反驳我。。

我有情绪是针对喷子的， 对于你这种正确交流的人 我是很友好的，你可以放心说话。

@GuuJiang 好的， 我会去看的。

然后回答一下你的问题， 当没有数据进来的时候，我这个程序是等待状态，accept 自动阻塞住了 不会返回任何东西 就停在那。 队列的 take 方法也阻塞住了，就停在那。 整个程序除了主线程挂在那，就没任何动作了。

然后我问你一个问题， 消费 selectionkey 的那个 while 是不是有被业务阻塞的可能？ 你可能会说 在 while 里开线程 让业务线程去处理。 但问题是 在业务线程跑完之前 channel 是不能关的。 因为 http 客户端需要等待响应， 必须等业务跑完 并把响应写入 channel 才能关吧。 而 channel 不关的话，while 会进入下一次循环，select 方法会再次为这个连接生成 selectkey， 这样一来就出现重复处理了。 这个问题是我真实遇到的问题。 如果你有办法解决， 那你可以说出来。

多路复用器 是系统层面的， 到了应用层 就是单线程在一个个消费 selectkey， 如果这个你觉得不对也欢迎 指正。并说出具体哪里不对。

最后你可以去看一下 nio 的 Reator 的分发模型， 是不是跟我这个有点像。

@guyeu 不过，第 5 点 是支持的， 监听两个端口即可。

@msaionyc 分享和推广的 分界线 本身就是模糊的吧？ 同样是这件事，我如果自始至终用的词语都是 分享，你还会找到这个刺吗？

第二，你得注意语境， 反驳喷子的时候 说出来的话 是可以如此理性的看待的吗？

@guyeu

说实话，你这段话有点感动到我了。真的。

我会认真考虑你的建议，并在后面尽可能优化上。

@learningman 我只是做了一个支持 这三个协议的包，你跟我扯 网络模型干嘛？ 没东西喷了 就来吐槽我的目录结构吗？

@D3EP

1. 队列的 take 方法 会自动检查队列是否为空，如果为空是不返回的 ，直接阻塞在那，所以不存在空转。

2. 多路复用，那是系统层面的，到了应用层还是一个线程在消费。Selector 确实是一个线程 可以处理多个 TCP 连接，但是他是在 while 里排队一个个处理的。 这跟我的模型区别不大吧？ 我也是每一个线程 都在处理排着队的多个 tcp 。

3. 配置几个线程 就是几个线程同时跑，不会因为请求多了就线程暴增，怎么会打满 CPU ？

4. 你说的线程没有隔离 可否详细一点？ 对于这一条，我是真的想虚心请教的。

@Resource 是您主动跟我争的，谢谢。

@Resource 最后 请您解释下 为什么 这种应该丢到垃圾桶？ 是您觉得 spring 不配被研究原理呢，还是 spring 不配被称为技术？

@Resource

你搞清楚一件事啊，我现在并不是在抱怨没人用我的东西。 所以 跟姿势有啥关系？ 而且我如果不提高姿势 我能写出项目来？

而是，明明在分享一个正儿八经的开源项目，却要被喷 是我所不能理解的。