@GuuJiang 这题要有解，两侧必须是有界的，换句话说你想求的其实不是“直线”，而是线段，否则的话就以你在#8 发的那个反例来说，最开始的两个点在图里看起来不满足，但是只要往右边延伸足够长度，又变成满足的了，继续往右延伸，再次变成不满足，且正解变到了它们的右侧，所以必须要先定义范围

首先你得定义整个范围的左右边界，找出其中点 m，然后找到 y 最大的点，如果 m 在其左侧则逆时针旋转，在右侧则顺时针旋转，找到下一个碰到的点，如 m 介于两点的 x 之间，则中止，者两点就是所求，否则 m 必然位于两点同侧，那继续在哪侧就像哪侧旋转，重复直至 m 位于两点之间

@Joker123456789 #43 指出的问题和我一直在说的是同一个问题，如果这个弯转不过来那你永远不可能写出正确的 NIO，你自己 debug 看一下是不是客户端没有发数据的时候也在读，然后读到 0 字节？
试图用协议层去驱动网络层就是导致你所有这些错误的根源，换句话说你可能用了下 NIO，但是以一种错误的姿势在使用，然后觉得是框架自身的问题，于是准备解决这个“问题”，你有没有想过如果真的存在如此低级的问题，别人就不会发现吗？难道所有人都在默默忍受？
正确认识自己确实不是一件容易的事，言尽于此，我也不会再继续回复了

既然难得你听得进去，那我就再多啰嗦几句

你这个东西不是基于现在已经指出的问题修修补补就能完成的，只能推倒重写，因为你的根本思路就是反的
作为一个网络框架，它的职责是什么，是负责网络 IO，所以要做的事情就是用尽量少的资源管理尽量多的连接，负责网络数据的读写，对于上层协议应该一无所知，也就是只实现 TCP/UDP 层，有数据可读就读，读到的数据直接丢给上层协议，至于协议数据什么时候完整，如何划分边界，得到业务数据后怎么进行业务处理，用什么线程模型，这些通通都是上层协议的事情，已经和网络层无关了，而你现在的思路是由协议层来主导读，我是一个 http 协议，所以我主动调 read 方法直到读到一个完整的 http 请求，我是一个 websocket 协议，那我就定时读取数据，这种思路首先只适用于 bio，其次也不推荐，这也就是我一开始说的，从 bio 到 nio 并不只是一个简简单单的 configureBlocking(false)就完事了，而是思路的转变

你真的想要实现一个网络框架，那最基本的能力之一就是使用者能自由扩充应用层协议，你确实可以内置一部分常用协议，但这种扩充应该是无侵入性的，更大的意义在于让使用者能开箱即用，同时对扩展协议提供参考
再回过头来看你图里的后半部分，我为什么管它叫线程池的雏形，因为它确实跟线程池的基本原理有点类似，但是很可惜实现也是错误的，你的队列和线程是一一对应的，这就导致线程无法得到充分利用，会出现有的线程空闲，而有的任务又被堵塞得不到处理，你可以去看看正确的线程池实现方式，给你点提示，看看队列和线程之间到底是什么关系

综上所述，你的这个东西，网络层和协议层之间的关系是错的，对 NIO 的使用方式是错的，线程池实现也是错的，并且这些错误都属于非常基础非常低级但是在初学者身上又很容易出现的，说实话，我发完第一条回复后好奇点了下你的发帖历史，我就已经后悔了，因为我看得出来你对自己的开源项目是非常自信的，但是很可惜你实际写出来的东西和你的自我认知之间存在非常巨大的差距，这样说也许很残忍，但是如果你继续在这条路上越走越偏直到哪天摔下来的时候，在隔壁帖子里对你表示过支持的所有人都有责任

accept 阻塞的是 connect 阶段，我说的是客户端 connect 后没有发数据，假设你总共有 n 个线程，现在有 n 个客户端连接上但是只发了一个完整 http 请求的一部分数据，这时候第 n+1 个以后的客户端是不是永远被卡住得不到处理了？你这个完全就是同时抛弃了 bio 和 nio 的优势，结合了二者的劣势，bio 虽说占用线程数多点吧，好歹还能继续处理后续的客户端，并且没数据可读时是在阻塞，而你这个本质上还是一个线程服务一个连接，并且没数据时也在空转，而且线程数还是有上限的，所以连最原始的 bio 都不如

“selector 里有正在处理的 channel”这个没有任何问题啊，你可能误解了 selector 的含义，每一次 select 操作返回的是处于就绪状态的 channel，所谓的就绪对于 read 操作来说就是有数据可读，那你读就行啊，内层 while 是错误的，你还停留在 bio 的思想，有数据可读不代表能完整地读到一个上层协议所需要的结构，你能读到多少读多少，至于什么时候得到上层所需要的完整数据这又是另一个话题了，暂时按下不表，所以一个 channel 多次出现在 select 的结果中是再正常不过的行为
你画个时序图，模拟下多个连接同时存在，然后以随机的间隔发送下一个数据片段，然后对比下在这种情况下你的程序和 nio 的区别
要知道，一个 channel 不是你想读就能读到数据的，而 select 的存在就是保证了你只在真正有数据可读时才去读

@Joker123456789
第一句话就错了，你再好好看看 tcp 里 accept 到底是在哪个阶段
至于你说的 select 重复处理的问题，在看到代码之前不好下结论，不过我猜十有八九是没有调 remove，因为这个是个很典型的错误
早期版本的 jdk 安装后有个 samples.zip ，里面就有一个用 nio 实现的 echo server 的例子，建议你多读几遍，而实际应用到真实项目中时，只需要把直接 reply 的那一行代码换成投递到工作线程池即可，这也是业界通用的做法
我在 16 楼的那句话可能刺伤了你，对此我道歉，但是等你弄明白所有这些问题之后相信你能体会当时的心情，换作你也会无话可说的

估计你今天情绪上很难接受，为此还专门另开一个贴抱怨下，以你现在对网络 IO 的认知，我很难跟你一一讲明白你的错误在哪里，但是明眼人都看得出来，真心建议你静下心来好好找点资料看看网络基础，各种多路复用方案到底在解决什么问题，等你看完了如果还是不服气，欢迎你回来对线
你可以先带着这个问题去看
“当客户端没有发数据时，你的程序在干什么，而其他正确实现了的网络框架，包括（ BIO 、NIO 、netty 等）又在干什么”

到时候你就会明白，你这个东西称之为“一个异步非阻塞的网络编程包”，是多么的荒谬

你开心就好

@Joker123456789
这个包结构本身就是另一个槽点了，证明了你对 tcp/http/websocket 三者关系的理解都是混乱的，这个暂且不表
你只需要回答一个问题，“在一个循环里依次对一堆 channel 进行 read”这个做法，相比起被你否定掉的 NIO，优势在哪里？

折腾的精神可嘉，但是。。。容我给估计还沉浸在造完轮子的喜悦中的你泼点冷水，相信我，再过几年，你会希望自己没有留下过这段黑历史的
首先，你所谓的 Selector 的“缺点”，证明你并没有真正理解 Selector 的意义，并不是说 configureBlocking(false)就可以称为 NIO 了，恰恰相反，Selector 才是 NIO 的灵魂，让我们来看下你是怎么做的吧，用一个每 100ms 执行的定时任务，循环对每一个 channel 进行 read，这点实在是槽点太多无从吐起，建议你自己先去看看 select 、epoll 、iocp 等的基本原理，如果看完还有疑问的话欢迎回来讨论
至于“如果业务比较耗时，会造成整个循环被堵住”，这个跟是否用 Selector 根本没关系，而是使用者自己应该保证不在 IO 线程里处理耗时业务，再看看你是怎么解决这个所谓的“问题”的，我猜这个 BlockingQueue 应该是你最引以为傲的一部分了吧，恭喜你，你重新发明了线程池……的雏形版
总的来说，这个东西作为一个关于 NIO 以及线程池的概念验证的课后实验还是可以的，但是实际应用的话，价值为零

这不就是 rebase 的典型使用场景嘛
首先确认你的修改还没有 push 到远程分支(如果已经 push 了但是确认这个远程仓库只有你一个人在使用的话也可以，只不过最后需要进行一次 push -f 操作)
1. 确认 git status 处于 clean 状态
2. 找到修改第 2-10 行和 90-100 行的那次提交，记下 commit hash
3. 执行 git rebase -i "commit hash"^，commit hash 为上一步中记录的值，注意不要漏了最后的^
4. 在出现的界面中把那次提交前面的 pick 修改为 edit，其他的提交保持 pick
5. 保存退出
6. 修改文件，把对 90-100 的修改还原
7. 使用 git commit --amend 提交，此时有需要的话可以顺便修改提交说明
8. 执行 git rebase --continue，如果后面的提交中没有再修改过 90-100 行，那么就到此结束，否则就会停下来提示你产生冲突，此时再次修改文件解决冲突(把对 90-100 行的修改还原)，然后执行 git add，git rebase --continue，重复这个过程直到没有冲突为止

到这一步后就达到了你想要的效果了，既保持了完整的提交历史，同时 90-100 行就好像从来没有动过一样

@quxinna 看到你连发了几个帖子都是关于 md5 的，感觉有点钻牛角尖了，有几点个人建议仅供参考
1. 不清楚你为什么要在每个问题里都带上 blueimp，md5 是一个公开的算法，任何一种语言的具体实现都遵循同样的算法
2. 在深入具体实现细节之前，你应该系统性地学习一下摘要算法的基本概念，摘要算法还有很多，而你存在认知错误的几个性质是所有摘要算法都具备的基本性质，与是不是 md5 无关，事实上对于大多数工程应用来说，首先要当作黑盒，充分了解算法的背景及适用场景，有兴趣再去深究具体实现
3. 关于你说的一一对应问题，用简单的鸽巢原理就可以得出结论，md5 的值域是有限的，而定义域是远大于值域的，必然不可能是一一对应，找到碰撞极难是因为这个值域虽然有限，但是对于人类来说还是太大了，想单纯靠碰运气的方式找到碰撞可以认为几乎不可能，这也从侧面体现了分散性的良好
4. 理论上任何一个把任意长度信息映射到固定长度信息的算法都可以称为摘要算法，只是性质有好坏之分，主流的 md5 、sha 等算法之所以能被实际应用在安全领域，是因为它们具备下面这些良好的性质：原文中任意一个位置的改变都会导致结果的改变，原文中任意一个小的改变都会导致结果的大幅度改变，实现细节中的各种操作及常数的选取都是为了实现这两个目标，至于为什么能做到你可以去找别人总结好的背后的数学原理相关的文献看，但是恕我直言按照你现在的理解看这些还为时尚早，毕竟老祖宗也说过，思而不学则殆

满心激动地点进来，满怀失望地退出去

国内的一样有，注意前提，当题目的输入为树时才有

既然准备用于 leetcode，难道就没发现 leetcode 自带这个功能吗？
输入为 TreeNode 的题目里，在输入框的右边就有个“Tree Visualizer”的开关

@GuuJiang 不小心发出来了，接上文
用反证法，假设真的存在 O(lgN)的基于比较的计算 rank 的算法，那么只需要运行一遍这个算法，同时按照计算得到的 rank 把元素放到目标数组的相应位置，于是你就得到了一个基于比较的 O(lgN)的排序算法，然而众所周知，基于比较的排序算法复杂度下界为 O(NlgN)

不清楚题目里说的 rank 是哪一种定义，假如表示的是在有序序列中的索引，那么结论是不可能的

@yyttll #10 唉，前面所有人都白回复了，你还是没看懂，不管 10 号发还是 15 号发，发的都是上月 1 号-31 号的工资，当然是一样的了