不带分片 key ，当然扫全表了。
要么先查出来分片 key ，用分片 key 挨个查。
要么再搞个数仓，去数仓查
要么异构索引表

@RotJun #5 他这个这么便宜是什么原理

@Chinsung #10 commit;
这种最明显，别的都有点玄学

个人感觉 begin;
insert……

这种都是要看取舍的。
首先，你描述的这种情况，并不是死锁，因为并没有互相等待对方持有的资源。watchdog 不释放，唯一的情况也就是其他后续的线程一直去争抢和尝试获取这个锁，但是这里 redisson 还有优化，用了 redis 的订阅机制来解决，后续到达的线程都会直接挂起自己等待订阅机制来唤醒。
如果死循环的话，上游或者下游一般总有一个会触发超时机制，无非是时间可能会比想象的要长非常多罢了。
宕机的话，redisson 续约的线程也会宕机，就不会触发续约，其他机器就能拿到这个锁，所以也不存在问题。
说到底，你是用这个机制的本意就是希望“锁不要在任务没有执行完之前就释放”，然后反而又要求“万一永远执行不完，还是要释放掉”。最终的考虑就是在这 2 种情况间，哪种情况出现的后果更麻烦，你就选择解决对应问题的方案

@iyaozhen #53 不懂就问，字节的推荐算法这些很厉害，但是业务复杂在哪里，会比金融和 ERP 这些还复杂吗？

加密和你说的无关。
http 一般就 https+报文加签
银行系统的对外通信，一般都是通过包体加签的方式来保障安全的，报文除了入参之外，额外有个签名字段。
https 本身不出问题的话，其实 https 就够了

这种确定层级的，直接 map 塞就完事了吧，没必要非用树

可以升，不过 3.1 的话原来的破解都不行了，得换个方法
正版随便升，目前用起来没什么问题

@joffey #23 一般删掉.idea 文件夹，然后从新打开项目就行

@golangLover #4
不支持协程，并发吞吐差 ---------这两者是一回事吗？并发吞吐差体现在哪里？
只支持一个包名的一个版本，不能共存，时常版本被覆盖 -------------我挺好奇哪个语言支持同一个同名类多版本存在。。
操作复杂 json 想吐 --------------如果 JSON 序列化框架你全用 map 接，那大概和你想要的效果差不多，而且 fastjson 封装了一些 json 对象来操作，我觉得便利性还可以
没有原生热更新 ----------------------真的吗真的吗，你要是了解 jvm 的 classloader ，你就会知道这个恰恰是比较优雅的热更新
没有 async await ------------juc 的包是写的不够好吗。。。能看到内部实现的并发工具类难道不比语言直接提供的一个关键字要靠谱点？

@Chinsung #30 不过这样会在编译期有问题

可以用 java agent 的方式，去扫描你自定义某个包下的所有 do 类，然后通过字节码框架，比如 bytebuddy 这种，生成所有的 mapper 类

给正则构建一个树，一万个正则之间肯定有互斥的和包含关系，根据正则之间的关系简单分组，在正则树上匹配查找。

以前就有插件，新版本只是自动提醒你安装而已。
安装了后不是很习惯，主要是一些教程之类的你会发现反而更难对照和理解了

@zhoudaiyu #14 这个得找 linux 大佬看了，我简单看了下 oom_killer 的机制，是进程向内核 malloc 的时候触发的，底层的网卡事件可能不包括在内

你这个，一般的字节码框架都不一定有 api 去方便的支持吧。
不过可以去找下，bytebuddy 有没有方便的 api 。
实在不行，jst 肯定能解决。

这种情况，什么都满了，网卡收到包后内核也没法创建进程或者线程去响应吧