类魂，别看这几年那么疯，实际上大多数人买了玩不了，还是让它赶紧静静的死去吧。老头环这种魂系的机制配上类似古墓丽影、刺客信条那样的探索地图，更特么是劝退大坑——几个小时的探索结果，一个突然冒出来的 boss 再加一个不小心的跳崖，就全都没了。就更别说那英转日再转中的脑残翻译了。

@MoYi123 #29 消息队列读写分离了，可以单独只对读那一瞬间加锁。10 楼说得明明白白。

@catamaran #29
@kenvix #31
上了高层面，数据设计上就要区分事务性数据和分析性数据了。用于常用业务的事务性数据，数据量往往十万都到不了，这时候离散的 UUID 就是首选。偶尔数据量上去的事务性数据，比如 twitter 这种体量的用户，也是换用雪花 ID 来同时保持离散跟顺序，不搞顺序而不离散的数字。分析性数据，用 UUID 就不合适。

@Vegetable #25
update table set status = 'work' where id = 1 and stats = 'ready'
id = 1 怎么来的：是 select id from table where stauts= 未处理 limit 1 得到的
那要是 select 语句跟 update 语句之间，其他线程已经提前做了 update 呢：这个 update 会返回 0 ，本线程处理失败
接着呢：如果你当失败处理，那么这个线程没了；如果你重新 select ，那么大部分时间要消耗在 select -> update return 0 -> select 的死循环中了。

我对 @MoYi123 第一个回复确实是错了，不是表锁，而是乐观锁。但乐观锁不解决问题，详见我上面对 yjhatfdu2 的回复。

楼主这个场景要加锁，你只能对 「 where stauts= 未处理 」，或者「全表」加锁，加了之后多线程从并发变排队，形同单线程。

@yjhatfdu2 #18
https://stackoverflow.com/questions/53288584/select-for-update-skip-locked-in-repetable-read-transactions
看下 skip locked 的效果，可以重复加锁，但是事务提交的时候要判定数据有没有被更改过，如果已经更改，那么本事务要失败。这就是个乐观锁，先提交的成功，后提交的失败，使用场景是并发修改的机率不高的场景。如果你在多线程并发场景中用乐观锁，那没跑几步就会只剩一个线程活着，其他线程全部出错终止（加了出错之后重启机制，效果会更差，绝大部分性能将被浪费在失败重启上）。

事务不是一句「开事务」就完事大吉的。什么时候开事务，开什么样的事务，都是有考究的。最常见的错误，就是认为开了事务就不怕并发数据冲突了。事务的隔离性是分级别的，序列化级别才能保证完全不出现并发数据冲突——但同时也没并发了。常用的隔离级别是可重复读，只在并发数据是确定的单行/多行数据的时候才能保证无并发冲突，当并发数据是表，或者表中不确定的数据时，还是要加锁处理并发冲突的。

而怎么加锁，也是有考究的。楼主的场景是没法加锁的，因为它的并发数据是「 stauts = 未处理」的表，不是「主键 = xxx 」的行。加常规悲观锁就让线程排队，等同于失去并发。加乐观锁，就是开玩笑。

@qviqvi #21 不要只找简单答案，容易错。Karte 那三个方案才是正确的。

@Vegetable #20 看好取数的查询条件，不是 select * from t by id ，而是 select * from t where stauts= 未处理（以及未锁定） 中的第一条。两个线程之间的共享对象，不是一行数据，而是所有未处理数据，你要加锁或者占坑，也只能这么占。加锁之后的结果就是，多个线程只能轮流处理，跟单线程一个效果，无法并行。

楼主你要得，应该不只是「同一条数据不能被多个线程同时取出」，而且还要是，「一条数据被一个线程处理时，其他线程顺序取下一条数据处理」

@rekulas #1
@Vegetable #4
取数逻辑是未处理数据中的第一个，行锁管不了（意味着非序列级别的事务也管不了），表锁和序列级别事务又管得太多了——写回前都会阻塞另一个线程取数，这样的话无论多少线程都跟单线程没啥区别。

@MoYi123 #8 你这个其实就是变相的表锁

我这没有方案，不过可以确定单靠数据库是解决不了了。上面两个用队列的方案，看起来就星了。

第一，常态化加班到 10 点 可不是只到 10 点，是下不了班（ 10 点下班，通常都是 10 上 24 下，简单说就是除了回家睡觉你一直都在干活）。不按标准加班费计算的加班，跟家暴只有零次跟很多次一样，只有不加班跟加班到死两种区分。既然已经打破规则了，那当然要打破到低。（友情提示：996 以前的加班标杆——华为，人家加班是按标准计算加班费的）

第二，就算真是 10 点 下班，你好好算算，那也是降薪。

矮轴跟常规轴的关系，就是笔记本跟台式机的关系，属于不同场景，比具备相互比较性。

@drymonfidelia #11 囧，搞了半天，你所说的大整数，只是 32-64 之间的整数。这在 Java 、.NET 等大多数语言中，早就是常态整数了。而编程语言之外的东西，除了 Mysql 这个用 Java 当底层的，压根就不关心你是 32 位还是 64 位，甚至是不是整数都不不安心，像 Oracle 和 json 就只有 number 。

至于兼容性，这要遵循最大适应性原则和协商原则，现在更明显的是，你这个接受不了 int64 的 C++跑偏了。

先说是不是，再说有没有。忠诚是一种下对上的关系，爹妈要是教儿子女儿结婚后要忠诚，那特么是有病。别把现代婚姻的契约关系，跟古老的君臣忠臣关系，搞混了。

第零，对外展示 ID ，跟其存储类型，没啥关系，超过 20 个长度的数字，它明显也得字符串存储。
第一，亿级数据量，性能考虑的比重很大。
第二，这些 ID ，并不是单纯的整数，往往都是同时兼顾离散性、顺序性、生成快速性的特殊序列。

听说，只是听说：不是让你选购的，是只管掏钱，别人给啥你用啥（不管用你自己再想办法）。

感觉你不像是写 Java 的，Java 只能 Maven Gradle 二选一，一个 XML ，一个 Groovy ，都不能自洽，但没有第三个选择。

XML 比 Java 更通用，还是静态、对象语言，虽然是另一种语言，但比 Java 还更母语，只要 XML 能干，它永远都是作为 Java 的辅助配置的第一语言。于是 Maven 自然在大多数时候都能让 Gradle 靠边站——并不需要 gradle 有什么不好。

至于你的问题，一般人用不到，一般公司也遇不到。不过 Spring 是遇到了，它换了 Gradle 。

作为一个挺/黑果、米、华的都见多了的人，还是不明白 maizero#4 #31 jdkxnktkdkxod#14 marc2017 #54 这些楼能收到那么多感谢，这几楼甚至连辩论都没有，就是直接攻击楼主。

更离谱的是，后面「下头男」这词都蹦出来了，

早睡早起，这个你应该自从上学就开始被听到了，办到了吗。这玩意跟北京、互联网都没啥关系，人的本性，再加上界限不明确（实际上是不愿明确界限）的中国特色管理方式，造成的全局情况。这正应了那句话，（在界限不明确的前提下）弹性上班等于下不了班。

钟摆被打破后回自行恢复，「晚 XX 晚 XX 」的因，正是「早 XX 早 XX 」的钟摆恢复。举个例子：原本都是正常上下，这时候 A 早上早下了，A 的伙伴就被打乱节奏了，B 需要 A 协助就在 A 该下班的时候拉着不让走，C 看到 A 今天早做完了就想着今天加班做一下明天好调休，D 一看你们这么乱我干脆等你们都完事了我才开始干活，于是最后全员晚上晚下了。