越努力越幸运~~ Java领域从业者；CSDN新兴创新博主；Java领域优质创作者；书写奋斗者故事;欢迎交流学习进步；

哦，好像跑题了，反正总之，加锁是为了安全，我有钥匙，我就有所有权，你没有，你就看着别动。但是现在有十条队伍(多线程)，首先来说，你无法保证十条队伍中哪个队伍最先进去，也无法保证进去的数量，a进去，修改了屋子里的账本，恰好b也进去了，也修改屋子里的账本，那么账本在他们退出的时候，被修改的结果是有风险(处理结果有错误的)的。然后其他队伍只能等待，只有等a出来了，其他队伍才能有机会进去，虽然现在进去的顺序无法保证，但是却能保证每次只有一个队伍修改账本，而且修改后，其他队伍再进去，这样就变得有顺序，安全了起来。

死锁发生了。Lock wait timeout exceeded; 超过锁定等待超时，也就是死锁了，两个线程同时争夺资源，没有先后顺序，这就造成了死锁。产生死锁的原因有很多，更容易在多线程、线程池、多条sql操作同一张表分开来写。有必要对这些容易产生死锁的接口用jemet性能测试。文中告诉你，错误来自UPDATE mch_user SET is_admin=? WHERE id=?### 这条，当然sql语句没有错，id是主键索引，is_admin就一普通字段。它说错误可能存在com.shuwei.me

原有：三层循环去删除，并且使用错了delete方法，实际走的是逻辑删除，只是修改状态。所谓死锁：是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用，它们都将无法推进下去.此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。导入excel表的有许多重复的名称，刚好1进来去delete（可能是逻辑删除，可能是物理删除）这个重复shopId。之前主要是导入7000店铺的时候，大量重复名称店铺导致了高并发死锁的这个场景。改造的方法最后是这样的。

6379配置类@Bean}}使用@Servicetry{//TODO业务逻辑}}}方式2依赖https配置文件application.properties（这种方式完全兼容SpringBoot配置）使用@Servicetry{//TODO业务逻辑}}}依赖配置文件application.properties配置类@Bean}}使用@Servicetry{......