也许，你即使加了锁，也未必能防止并发的出现，往往，惊喜就隐藏在背面，转过身，你就会发现真实，不要让表面美好现象蒙了你的双眼 。

背景

       先说背景吧，我们是接收第三方数据，从数据过来到数据入库经过三个服务，第一个服务是老大的数据接收在保存到文件中的同时Push给我，我经过初次解析，将需要的数据属性发送给雷明的data-bus-java。

       在项目即将上线之前，老大让我加大测试力度，因为行业的缘故，我们的数据都是晚上数据异常的多，白天数据几乎没有，所以，我们都是晚上跑数据，白天的时候检测项目的准确性和稳定性。所以，有天晚上，索性一次性预定了同一个时间点的10场数据。期待第二天能带来惊喜。

发现

       果然，第二天，比较这10场数据，验证正确性的时候，出现了异常。入库的数据，有一个自定义的第三方id，这个第三方id是由固定的一些值产生的，正确性来说不应该重复，但是，现在数据中的数据重复了。查日志吧，排除老大那里可能产生的问题，比较我和雷明之间的问题，发现，我这里发给雷明的数据是正确的，没有异常。紧接着我和雷明找data-bus-java，排查它的入库日志，的确数据重复入库了，这样产生的问题可能在以下两个方面。

分析

       第一个方面，入库之前的过滤重复数据，没有过滤掉，第二个方面，数据在插入时出现错误，在插入的时候，我们要先查询，同要入库的数据对比，过滤后，将非重复的数据入库，难道是这里出错了？

       我们反复检查分析代码，发现并没有什么问题。难道是Memcache出问题了，我又查了下其他两场数据，也出现了数据明显重复的问题，不可能一个晚上，Memcache出现错误这么多次吧。我问雷明，是不是咱在读写的时候发生了并发啊，我记得当时雷明给准确的答复是不可能，因为那块他已经做了限制，其实，我也看到了，的确是做了防止并发，做了相关的逻辑处理的。可是这个问题出现在哪里呢？

       还好，不久，雷明就给我发来一张截图，说，的确并发了，找不到截图了，我就简单描述下吧。

       先看下我们的代码小部分截图：

       

       如果不发生并发，我们这里的日志应该是连续的，类似这样

        

      但是，我们看到的日志却是类似这样的：（抱歉没有截图，只能描述）

      在exec-3下的开始过滤处理中，和exec-3下的保存完成中，夹带了其他线程，比如exec-4的过滤处理或者exce-5线程的保存完成。

       原因找到了，如何解决，我看下这块的代码，分析了下，因为用的是Lock加锁，我们设置了锁住的时间为3s和锁的请求时间30s。简单分析下：

       exec-3线程通过查询比较后需要保存数据1 2 3，三条数据，此时锁住3秒，3秒过后，释放锁，此时1 2 3 三条数据还没有入库，这时exec-4拿到锁，经过查询比较还是需要入库1 2 3 三条数据，就这样，线程exec-3和exec-4的线程保存1 2 3 这三条数据的时候，保存了两次，数据当然会重复。

      还好，没有发现少数据的情况，说明我们设置的锁的请求时间30s不会有问题。为什么呢？这还得详细了解Lock的锁机制。有兴趣的自己看吧，或者，关注后面的博客，也许我会分析然后分享，嘻嘻。

      进一步分析，为什么锁住3秒的时间不够，也是因为后面的逻辑，我们在入库之前为了保证数据一致性，我们有一个查询并比较的过程，这个处理的时间比较长。

解决

      这些都是原因，剩下的就是优化了，我们采用的解决方案是：延长锁时间，延迟锁请求时间。

      至此，问题解决，也没再发现这个情况了。

总结

       大量的测试暴露项目的真实情况，美好事务的背后隐藏着真实的内心，转过身，发现事实，分析解决，又回归美好。