sql 要改一下，有个子查询导致 for update 的行锁没加上
SELECT id,state FROM test_list
WHERE id >= ((SELECT MAX(id) FROM test_list )-(SELECT MIN(id) FROM test_list )) * RAND() + (SELECT MIN(id) FROM test_list )
AND state = 0
LIMIT 5 for UPDATE

最开始用的是 gradle，后来用 maven，感觉 maven 的命令真的是又臭又长

方式 2 出现的问题是 写偏差,用可序列化的事务级别可以避免。或加一张辅助表，也可以加一辅助列（值为 TASK_TYPE TASK_TYPE +BACKUP_COLUMN，使其有唯一性，然后加上唯一索引）。

看对方水平，人家水平不差用第一种搞不好人家还觉的磨叽，给予有一定难度的任务，如果他搞不定再帮忙提供思路。

gs65 吧，够轻薄 18mm 2kg 不到，性能也够用 i7 9750h 1660Ti 16G

目前公司用的是 thrift

省事点直接在 win10 商店里搜索 vpn

正常，每个星期也就那么 5、6 天不想上班

@lihongjie0209 别人写好的，猜他意图应该是任务来了不让排队，也不让拒绝，就阻塞在那等待消费，感觉和 SynchronousQueue 有点类似吧，业务场景是做 ETL，提交的任务必须跑不能丢弃。

靠自己是没戏了，等相亲了。。。

ExecutorService 里面的构造的线程的队列是无界的，按照阿里手册上的说法是不推荐直接使用，在并发量不大时我是直接用用这个。。。公司项目里是用 spring 配置的线程池 ThreadPoolTaskExecutor，之前公司有用 ExecutorService，在上面包装了一层加了个 Semaphore，线程数量超过最大值时阻塞不让排队。

死亡笔记 全程无尿点

看业务场景吧，类似提交订单、抢红包这种可以需要‘保证’处理，可以接受延迟处理的请求放 MQ 里等待消费返回信息是没问题的。一些如查询列表的请求把它放队列里保证服务器在能处理该请求意义不大吧，服务器响应不过来直接返回服务繁忙通知用户就好了。
1.你说的稳定是指服务器在繁忙时，请求可以在队列里堆积，不至于像直接调用那样返回失败，这个像上面说的看场景，一些不重要的请求失败就失败了，没必要确保服务端一定处理；
2.rpc 也可以做到负载均衡，例如 SpringCloud 里的 RestTemplate+Ribbon，通过注册中心 eureka 提供的信息做到负载均衡（我也只是看过官网的 demo,生产中并没用过，不知道它可不可以实现根据服务方的健康度做到带权重的负载均衡）；
3.kafka 这种分布式队列就是使用 zookeeper 做协调中心的，消费者、生产者都只需链接 kafka 集群。
以上是我的看法，不知道对不对:)

@Takamine 走 http 也算是 RPC 啊，RPC 可以通过 tcp http 等的方式实现，消息载体可以是 json、xml、二进制等

你是想把 MQ 当做请求的分发器，等于所有请求都先到了 MQ，然后再给服务端消费。以前公司做 ETL 时有个类似的场景，数据抽取转换后先扔到 kafka，每个入库的程序去 kafka 拉取数据存数据库。这种需要数据不丢失的场景下挺合适的，大多业务场景的请求当服务器响应不过来了就丢弃了，把请求持久化保存起来也没用。

这是发生幻读了吧，把数据库隔离级别设置成串行化，也可以用队列在业务层串行化，唯一索引貌似是最方便的。

好了，知道你有女朋友了，下一个

《 java 编程思想》（ Thinking in Java ）--> 《 java 并发编程实战》（电子工业出版社那本）--> 《深入理解 jvm 》
这些书有些年份了但很经典，看完后再查查 jdk 每个版本的变动。其他的再抽空看看设计模式、数据库、网络什么的。