本文探讨了在多线程环境中如何处理ElasticSearch数据重建的同步问题，以避免并发冲突。作者从最初的想法——使用`synchronized`关键字，到遇到的问题——线程等待而非拒绝执行，再到解决方案——引入模板模式和特定对象加锁，逐步展示了一个更优雅的处理方式。通过创建一个单独的对象来管理同步锁，并抽象出可复用的模板方法，提高了代码的可维护性和安全性。
需求背景
我们的项目，是 Mysql+ElasticSearch 做的一个数据库和搜索引擎，项目经理提出需要做一个用于重建 ES 搜索数据的接口，这个任务很光荣的交给了我。
在功能的编写过程当中，我突然思考这样一个问题，因为我们 Web 项目本身是多线程的，那如果在同一时间段，有多个请求同时发起，那同时发起 ES 的重建，对于 ES 来说，可能会产生一些莫名其妙的问题。
所以我感到非常高兴，因为这个问题，似乎不是听起来的那么简单。于是乎我想到了，要加入同步锁了。
最开始的思考：
最开始我只是很简单的想，直接在对应的 Service 层写一个方法，然后直接加一个
synchronized(this)
在整个方法体上。
@Override
public synchronized int rebuiltBountyData() throws Exception {
...
}
最低0.47元/天 解锁文章
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
