@xuanbg 要不你再好好想想？匹配的是子串，不是子序列

这其实是一个非常有意思的问题，不知道真实的密码锁是怎么实现的，但是假如让我来设计一个密码锁的话，我会采用下面的方案
当设置密码时，将设置的密码编译为一个 AC 自动机(当然由于只有一个关键词，所以实际退化成了 KMP，不过也可以支持多密码)，这样每按一个键时实际是在自动机中进行转移，当到达终结状态时就开门，这有个巨大的好处，无论前面输入的无效内容有多长，都不会带来时间和空间上的额外开销，理论上可以支持的无效内容长度没有上限
假设密码锁真的采用了这样的方案，那么确实可以认为是明文存储的，虽然没有直接地存储密码本身，但是获得了完整的自动机等价于获得了密码，不过对于密码锁这种必需要物理接触才能使用的系统来说，直接暴力破坏恐怕都比试图读取存储要容易得多，所以是否明文存储已经不是那么重要了

那要不试试你们心目中的产品之神 telegram 呗？家里的老人，不会发文字，微信只拿来视频用，是直接点击任意一次通话的气泡方便还是选择菜单-“视频通话”方便？至少我用过的 IM 全都是这个逻辑

虽说在 v 站黑张小龙才是政治正确，但这个功能真的没什么黑点吧？系统通讯录的通话记录不也是一样的逻辑？对于一些经常视频很少发文字的联系人来说反而很方便

@zhoudaiyu 后者

@zhoudaiyu 你这样一说就明白你的疑惑来自哪里了，实际情况是，发送“握手”使用的那个 http 总得要先有个 tcp 连接对吧，姑且称他为 A，“握手”的请求并不是为了开启一个新的连接 B，而是接着使用 A，只不过在 A 上承载的应用层协议摇身一变切换为了 ws 协议了

1. 从历史进程来看，websocket 是晚于 http 诞生的，你想象下如果自己就是制定标准的那班哥们，现在面临一个新任务，需要设计一种浏览器能使用的，能够保持连接，且服务端能够主动发送数据的协议，那么你有两种选择，一种是基于 TCP 设计一个全新的协议，一种是看看能否在现有的 http 的基础上 hack 一下完成目标，于是一拍大腿，http 本来就基于 TCP，把这个现成的连接拿来用不就完事了，于是只需要设计出一种方法，通过一个 http 请求让双方都知道“现在我给你发了一个 http 请求，你处理完这个请求后咱们这次请求时使用的那个 TCP 连接先别关，且从现在开始，在这个连接上咱们开始玩一个新的协议，这个协议不如就叫它 ws 协议吧”，这就是第一个 http 请求里的“Connection: Upgrade”干的事，这样有个很大的好处，就是当服务端版本比较旧，还不支持 websocket 时，它收到的仍然是一个合法的 http 请求，只不过忽略了“Connection: Upgrade”而已，这样不会带来什么大的兼容性问题
2. 原因同上
3. 同上，这时候 nginx 相当于个中间人，于是它需要干两件事，一是自己处理“Connection: Upgrade”，将上游到 nginx 的连接切换为 websocket，二是把“Connection: Upgrade”忠实地传递下去，让下游能够处理，从而将 nginx 到下游的连接也切换为 websocket，当存在多级 nginx 时同理，每一级都要正确地完成这两件事，整个链条才能串起来
4. 是可以的，如果做 4 层转发那么上面完全透明，而如果是应用层，就像 nginx 这样，那就需要像上面提到的这样，不光耀转发 Upgrade，同时自己也需要能够响应 Upgrade
5. 在应用层最好不要随便使用“挥手”这个词，以免带来更多的误解，虽然我知道你真正想表达什么，答案也很简单，因为从处理完 Upgrade 那一刻开始，协议已经切换成 websocket 了

就是字面意思“好看”啊，对人类友好的展示方案
拿 json 举例，未 pretty 的 json 全部挤在一行，因为计算机解析时只需要标记就够了，而经过 pretty 以后就加入了额外的换行、tab 等排列成我们常见的那个树形格式，换行和 tab 对于解析来说是并不需要的，单纯就是为了让人类更容易看

@coderstory 我来帮你翻译下你的问题吧
你的意思无非就是 B 唤醒 A 以后自己并不是马上进入 wait，而是继续执行，由别的条件来让 B 进入 wait，这段时间 A 和 B 是同时执行的，由此可以推论所有只用一把锁(此处指广义的锁，无论是 synchronized 、j.u.c.Lock 、单 Lock 多 Condition 等)的方案通通都是不可行的，这些方案实现的两个线程互相唤醒的效果从时间线上看都是交替执行，这里顺便纠正一下你以及楼里部分人对 wait/notify 的一个常见误解，并不是说 B 调了 notify/notifyAll 以后 A 就开始执行了，B 调 notify 仅仅是让 A 开始进入锁的竞争，直到 B 进入 wait 、或者结束执行等其它方式离开临界区，A 成功竞争到锁后才真正开始执行的
回到你的问题来，再结合你下面说的应用场景，我觉得这大概率是个 XY 问题，先不说“前端调试后端”这个是否有误入歧途，光说前面这个问题，站在 B 的角度，从宏观上来说，你真的关心在 B 从调了 notify 到 wait 的这段时间 A 是不是真的开始执行了吗？这个对 B 来说理应是作为黑盒无感知的才对，如果你对这个有刚需，非要他们有一段并行的时间，那么一定是哪里出了问题，不要继续花心思在解决 Y 问题上了

@moooookey 用不用 callkit 唯一的区别就是接听界面是应用内的还是系统的，通话流量都是自己实现，不存在苹果代理这种说法

@qwertyzzz 这里指的是覆盖索引，简单说就是不需要回表，只要你查询的列全都属于索引自然就满足覆盖索引
@iminto 你才是属于以讹传讹吧，明明是你自己理解错误，谁说最左原则指的是在 where 里的顺序了？其实这是个简单的逻辑问题，如果 ABC 的组合是有序的，那么单独取出 AB 或者 A 仍然是有序的，这就是索引能继续发挥作用的原因，但是单独取出 B 、C 、BC 则不再是有序的，索引自然也就起不到作用了，这才是“最左原则”的本质

@PeakFish ？？？

重新定义“分割”

@3dwelcome 只要一个东西是固定长度的，就不可能存在 100%不重复，鸽笼原理了解一下？

其实理论上所有的硬件都需要驱动，甚至包括 CPU，是的，你没看错，包括 CPU，倒回去十多年前，重装完系统后依次安装各种驱动简直就是家常便饭，甚至还因此而诞生了类似驱动之家这样的软件来简化这个过程，那为什么最近这几年主动去安装驱动这件事开始变得陌生了，一是因为操作系统本身已经内置了大量通用的驱动，并且硬件也趋于标准化，所以操作系统内置的驱动已经足以满足了，但是各种硬件定制化的新功能仍然还需要在安装特定的驱动后才能使用，最典型的例子就是刚装完系统时只能设置比较低的分辨率，等装完显卡驱动后才能设置更高的分辨率，二是因为系统本身以及各种 XXX 电脑管家具有联网自动查找并安装驱动的功能，在如今的网速下这个过程已经对用户无感了

更正一下，甚至我自己说的“自旋锁只是其中一种手段”这句话都是不准确的，自旋并不是锁的必要条件，锁也不是靠自旋实现的，有没有自旋，自旋多少次都不影响锁行为的正确性，自旋的存在仅仅是作为“预期能够很快得到锁，自旋的代价小于 wait 的代价”这一前提下的一种优化手段而已，既然是优化，那自然是可以调整其参数甚至去掉的
如果“预期能很快得到锁”这个条件满足，那么自旋带来的收益就是正的，如果条件不满足，那还不如不自旋，而在单核条件下这个条件显然是不可能满足的，那关掉自旋(其实就是把自旋次数改为 0)也是一种很自然的选择

@raysonx 这就是你和其他所有人分歧的出发点，没有人说过去掉锁啊，锁是目的，自旋锁只是其中一种手段，去掉自旋 != 去掉锁，不管怎么说，也改变不了在单核环境中自旋就是被优化掉了这个事实

这篇帖子生动地展示了什么叫作“你在第二层，你以为我在第一层，实际我在第五层”
按照“是不是只能等 A 执行完毕”这样的表述，提问者应该在第一层，估计还没有形成时间片这个概念，于是第二层的人敏锐地意识到了这一点，指出了不管是不是单核，实际都有并发，但是这个帖子好巧不巧提到了自旋，于是引来了第五层的人，指出了在单核环境下自旋是无意义的，但是第二层的人无法区分第一层和第五层，把所有第五层的对手都当第一层的来辩论

其实跟各种软件自带一大堆重复的 dll 同样的理由，站在开发者的角度，肯定是统一的依赖管理更合理，然而站在小白用户的角度，更看重的是开箱即用，最终形成了这个恶性循环的局面