震惊！什么bug居然要改5个小时

背景1

我们公司有一个业务是这样的，用户给公司提供的一个企业微信号发送文章，并在三秒内发送一个标签就像这样

那么我后端要做的啥呢，就是把这个文章解析出来，然后把内容总结一下再次发送给用户，就像这样（这里展示的是生产环境的样子）
but
看到测试环境的那个#开头的文字了吗，那个就叫做用户对这个文章发送的一个自定义标签，如果他在三秒内发送了这个标签，那么我就需要把这个标签存到这个文章中。

背景2

我们新开发了一个推荐标签的功能，也就是服务根据这篇文章总结出合适的标签

背景3

由于AI总结速度很慢，我们希望用户可以先看文章，AI总结可以放到后面，所以我这里做了一个异步的操作，把文章的保存和总结分离开，保存依然是同步执行，但是总结是放在线程池中异步执行

问题

我们发现我们服务自动推荐的标签会把用户自己写的标签给吞掉

排查问题

时间：18:47
首先我一眼就看到了List.of()这个方法，他把原有的标签用这个方法包裹成了一个List，而我这里需要把服务自动推荐的标签添加到这个List里，我大脑飞快的搜索我的记忆，在0.0.1秒内我直接想到了List.of是坑，他创建的不是真正的List，而是一个ImmutableCollections，各位请注意啊，这是一个巨坑，这个类看名字也能知道啥意思，不可变集合，对的，不可变，他是不可变的，所以你想在这个结合里添加元素，那必然是乌龟办住校，憋住了。

解决问题?

时间：19:10

以我的聪明智慧，呵呵，这种东西秒解决！随手写了一个jdk8的语法糖

搞定！收工！下班！
那是不可能的，作为一个严谨的程序员，我必然是要测试一番

信誓旦旦的测试

然后傻眼
诶？怎么和没改一样？

肯定是自动化部署的问题（因为上次已经出现过了）

所以我信誓旦旦的去服务器上重新打包，重新部署
来回反复7次左右
我意识到有些不对劲

于是我写了一个测试的接口，再次部署，如果这个接口存在，说明自动化部署没问题

然后果然接口安安稳稳的出现了

严丝合缝的证明了我绝对没改好这个bug

再次排查问题

时间：21:28

这一次我谨慎了很多，总共将近两千行的代码我一步一步的调试，一点一点的寻找蛛丝马迹
但是徒劳无功
我想到了放弃，这一块我甚至想要交给公司的另一位大佬程序员解决
但是，我既然开始做这个事情，就不能轻言放弃，所以我决定继续排查

时间：23:00

我疯狂的给测试环境发送数据，希望能得到一点进展
但是显然，没有用
这时我灵光乍现，会不会是线程安全问题
我突然又想起，背景3
于是我再次发送消息，观察数据的变化
终于，我发现了，标签在总结发出的前一刻出现过，而且出现的很随机，跟文章的保存好像没有一点点关系

我猛然想起，对啊，保存文章的是一个线程，总结的是另外一个线程，我在这个线程里给文章打了标签，另外一个线程里也打了标签，但是线程之间我没有做通信！

换而言之，假如两个人炒菜，一个人已经放盐了，但是没告诉第二个人说我已经放盐了，第二个人也傻乎乎的放盐，最终导致的就是菜咸了。

解决问题！

时间：23:05

既然排查到了问题，那就知道咋解决了

首先，既然是线程没有通讯的问题，那么我只需要在总结那里做的保存再查一遍数据

然后把推荐的标签加进去，就可以搞定

但是事情真的这么简单吗？

作为一个刚踩过线程安全坑的程序员，自然是极其警惕的，这里如果我查完之后，还没开始保存，那边突然又保存了，相当于我这里拿的还是老数据（虽然说出现几率很小，但是会出现），那么还是会出现上面那个情况

打个比方，还是两个人炒菜，a已经放盐了，b问了一下a你放盐没，a思考了一会儿，刚要回答说放了，b就等不及把盐放进去了，盐又放多了

所以这里我加了一个锁，考虑到分布式的因素，所以这里直接用了redis作为分布式锁的实现方案，利用redis的setNx，让两个保存逻辑去竞争这把锁。

打个比方，依然是两个人炒菜，a要放盐的时候把锅护住，b也想放盐，b必须得听到a说他放盐了或者没放盐，b才能决定去不去放盐，期间锅只能被a拿着，b你别想插队

测试

时间：23:43

最终测试没有问题

我也终于经过五个小时的折磨后光荣下班