Mybatis 一级缓存引发的bug

• 文章目录

  前言

  一、代码结构

  二、问题分析

  ---

---

前言

   为了更快捷的进行开发，很多项目会在service层中会引入mybatis plus来进行代码的编写。在使用mybatis plus进行分页的时候，稍不注意就会死循环。而这一切的真凶竟然是mybatis的一级缓存。

一、代码结构

 代码接口如下，大家看看这个代码有什么问题？这个代码只列出业务处理和service层。业务层主要功能是，分页查询服务中的用户，如果查不到用户就跳出for循环。 而service层，则用mybatis plus的分页插件进行分页查询。大家look，look一下。

      1.业务层

@Component
public class AiTaskRemindDailyHandler {

    @Autowired
    private AiUserServiceService aiUserServiceService;


    @Transactional
    public void getNeedSendUserId() {
        long pageSize = 1000;
        for (long currPage = 1; currPage < Integer.MAX_VALUE; currPage++) {
            //分页查询在服务中的用户
            List<Long> needSendTaskRemindUserIds = aiUserServiceService.selectUserJoinServiceByPage(currPage, pageSize);
            if (CollectionUtils.isEmpty(needSendTaskRemindUserIds)) {
                return;
            }
            //业务处理
            //。。。。。。。。。
        }
    }
}

      2. service 层
      2.1 接口：

public interface AiUserServiceService extends IService<AiUserServiceEntity> {
    List<Long> selectUserJoinServiceByPage(long currPage, long pageSize);
}

    2.2 接口实现：

@Service
public class AiUserServiceServiceImpl extends ServiceImpl<AiUserServiceDao, AiUserServiceEntity> implements AiUserServiceService {

    public List<Long> selectUserJoinServiceByPage(long currPage, long pageSize) {
    		//分页
        Page<AiUserServiceEntity> pageQuery = new Page<>(currPage, pageSize);
        pageQuery.setSearchCount(false);
			//查询条件
        QueryWrapper<AiUserServiceEntity> wrapper = new QueryWrapper<>();
        wrapper.lambda()
                .select(AiUserServiceEntity::getUserId)
                .eq(AiUserServiceEntity::getUserJoinStatus, CommonConstant.INT_1)
                .eq(AiUserServiceEntity::getDisabled, DisabledEnum.ENABLE.getStatus());
         //分页查询
        IPage<AiUserServiceEntity> page = this.page(pageQuery, wrapper);

        List<Long> userIds = page.getRecords().stream()
                .map(AiUserServiceEntity::getUserId).distinct()
                .collect(Collectors.toList());
        return userIds;
    }
}

直接看结果：
        结果是业务层中的for循环不会停止，会一直死循环，跳不出for循环。此时一万个为为什么在心中回旋。

二、问题分析

         通过dug进去源码发现。会发现分页查询的时候，如果sql一样，会一直从localCache一级缓存中取缓存的结果值，而不去查mysql数据库。源码路径在org.apache.ibatis.executor.BaseExecutor#query中。
    
    疑问一：分页查询的时候，不是每次传入的currPage和pageSize都不同，为什么sql会一样？
    这个问题其实是我们用mybatis plus分页插件导致，这个 Page<AiUserServiceEntity> pageQuery = new Page<>(currPage, pageSize)，不会拼在sql中，而是在mybatis plus的拦截器中起作用，源码在com.baomidou.mybatisplus.extension.plugins.PaginationInterceptor#intercept中。真实的sql大概如下

 select * from 表名 where user_join_status=1 and disabled=0

因此会一直从localCache一级缓存中取。

疑问二： mybatis一级缓存，什么时候会失效，我们什么时候才不会去查一级缓存，而是去查mysql数据库。

缓存失效情况

• 一级缓存在执行commit，close，增删改等操作时，就会清空当前的一级缓存；
• 当对SqlSession执行更新操作（update、delete、insert）时会清空其自身的一级缓存，若再执行commit会清空二级缓存。

 而我们业务层代码贴了@Transactional事务注解，所以不会commit提交事务，源码在org.mybatis.spring.SqlSessionTemplate.SqlSessionInterceptor#invoke中。所以不会去清除一级缓存中的值。所以会一直从一直缓存中取，造成for循环死循环。