@hunterzhang86 https://juejin.cn/post/7152475973412847630

可以看看 [PowerMock]( https://juejin.cn/post/7152475973412847630)，基本上够用了。

腾讯云买个轻量服务器，可以直接预装 k3s ，基本上玩的话足够了，我自己应用就部署在这个 k3s 上面。

是不是调用超时了

用语雀吧，yuque.com

有用 apollo 类似的配置中心么？这种可以考虑做一个环境配置的标识。

ifb.me 最近写了个 Java 知识图谱，持续优化中。

我一般用 LinsteningExecutorService 和 CountDownLatch 结合起来做，在 onSuccess 和 onFailure 里面使用 countDown()方法，这样便于捕获到异常情况。

SPI 主要是给用户提供扩展点用的，IOC 是控制反转，主要用来实现对象之间的解耦，两个没有半毛钱关系

多看书，不断的总结形成自己的知识架构，我的 Java 知识图谱正在更新中： http://www.ifb.me/

@ligudo 试试 telnet broker 对应的端口看通不通，还有发送的测试最好不要写 UT 的方式去发送，直接 main 方法启动 Java 进程发送比较好。

什么错都没报吗？理论上这种网络的问题可能性比较大。

不嫌弃简单的话，可以参考我的博客： http://www.ihunter.me/2014/09/23/config-hexo-in-windows/ ，图床和评论都用的 github

相关主题： https://github.com/hunterzhang86/hunter

回来看一下，其实确实 select for update 这个加锁其实是没有必要的，建议把这个去掉，死锁也就解决了。

select * table_b from where id = xx for update 这个如果查不到数据，会加上间隙锁，而如果能查到数据，select * table_b from where id = xx for update 和 update table_b set xxx=xxx where id =xx 都需要 X 锁，所以如果两个 session 同时拿到间隙锁，后面的 update 语句又需要 X 锁，就造成了死锁。而其他 session 如果执行 select * table_b from where id = xx for update 也会出现拿不到锁的情况。注意这里的间隙锁的区间包含了 X 锁的 id。
可以考虑改一下数据库的隔离级别为 RC 解决这个问题。
参考： https://time.geekbang.org/column/article/75173

@YuJianrong 正解