讲个笑话，golang 生态是有池化 goroutine 的 （狗头

synchronized 关键字和 threadlocal 的问题还没解决。。。。

B 处理完之后往特定通道发送通知消息，谁感兴趣谁订阅处理。

有两个原因，展开讲一下第一个原因。

这个例子中有两个关于锁的队列，一个是 CLH 锁队列，即：获取和释放锁时的队列。还有一个是条件队列，即 notify/wait/signal/await 这种。

在需要所但是没有获取到锁的时候，线程进入锁队列。当线程获取到锁又 wait/await 的时候，它会做两个动作
1. 释放锁
2. 线程转移到条件队列，不再在所队列中。

这个例子中会出现问题：

1. 在初始队列为空，假设当生产线程添加 1 个元素、notify 并退出同步代码块之后，那么会有多个消费者线程从条件队列转移到了锁队列中，并且有一个消费者线程获取到了锁。

2. 如果不用 while ，而是用 if ，那么当获取到锁的消费者线程消费完，队列为空，此时消费者释放锁，这会导致其他消费者线程重新竞争锁。因为它们现在是在锁队列中，而不是在条件队列中。不幸的是，现在队列中唯一的元素已经被消费了。

3. 用 while 就不一样了，用 while ，虽然有多个消费者线程重新竞争锁，并且有一个竞争成功，但是它在判断队列为空之后，又会因为 await/wait 进入条件队列

这种场景可以在恢复后先清空缓存，清空后再给应用使用

@haleclipse 都很牛哈哈，感谢

@Nitroethane 好牛啊哥，你咋知道的

@giiiiiithub 修正：因为很少有场景只是增删改 、遍历，而没有随机访问

因为很少有场景只是 append 、遍历，而没有随机插入、访问

人家两个说的是“假设”啊，有啥问题？

可以考虑下预计算（当然，复杂的话不一定可以

可怕。。。

问他裸聊照片有没有流出（狗头

stationId 如果事实不可能为空的话，你让他给你造一个 null 出来试试。

可能为空的话就 filter 一下完事。

另外,判断 list 是否 empty 有点多余了(前提 list 不为 null ）

json 就是 json ，前端要用，后端也要用 (狗头