MyBatis是Java程序员最为常用的一个ORM框架，相对传统的JDBC来说，极大的提升了开发效率。在MBG（MyBatis Generator）、MP（MyBatis Plus）等工具的帮助下，一些单表的SQL都可以自动生成。框架的意义就在于此，将繁琐的程式化行为进行封装，以便让开发人员将精力投入到业务代码当中去。

然而，凡事有利就有弊。框架在提供了便利的同时，也会让开发人员忽略一些信息。本文就来一起盘点一下，MyBatis在使用过程中需要注意的那些“坑”。

SqlSession.selectOne/selectList 与 OOM

踩坑过程：

在和其他系统进行联调测试时，经常会出现"java.lang.OutOfMemoryError：GC overhead limit exceeded"的错误。Error的调用栈指向了selectOne方法，在分析内存快照时也发现某pojo的实例数占比很高。经查，由于在调用selectOne方法前，未对查询条件进行空值判断，导致进行了全表查询（约800W数据量），导致程序抛出了OOM错误。

原理分析：

通过阅读selectOne方法的源码，不难发现selectOne只是对selectList的一个包装。在selectList方法执行时，最终会遍历结果集，并使用ArrayList来保存映射后的对象。当结果集包含的数据量很大时，程序会不断的向ArrayList中塞数据，ArrayList本身又是一个数组结构，会占用连续的内存空间，导致不断触发GC。当GC回收时间过长（超过98%的时间都在用来做GC并且回收了不到2%的堆内存）时，就会抛出之前描述的错误。

避坑指南：

清楚原因后，我们就知道该如何规避这个问题了。主要是要养成良好的规范编码，编码过程需要更加严谨。

SqlSession.update 与 多线程覆盖

踩坑过程：

在一次执行更新账户余额操作时，程序正常执行完成，但是查看数据库，发现余额并没有更新成功。起初怀疑是事物问题，遂检查了autoCommit的配置和事务的配置，发现配置一切正常，同时再次尝试更新余额时，余额更新成功了。因此，怀疑更新后的数据又被覆盖，通过数据库查看sql的提交记录，发现确实在更新余额完成后，又有一个会话对数据进行了覆盖。

原因分析：

在使用MBG或MP时，不知道有多少同学写过类似的代码：

Object obj = daoService.selectOne(xx);
obj.setXXX(1);
daoService.update(obj);

看代码貌似没什么问题，但是在多线程的环境下，这里就可能会出现问题。问题出现的原因是daoService.update在执行时，不仅仅会更新新赋值的字段，调用selectOne查得的字段也会一并更新到数据库，从而导致数据被覆盖。

避坑指南：

这里有两点需要关注，1、仅查询/更新必要的字段，MBG或MP的动态SQL中包括了对全量字段的判断，在使用时需要注意；2、在更新金额、积分类字段时，最好使用增量运算的方式对字段进行修改，或者通过for update 加锁后进行修改。

总结：以上就是近期发现的关于MyBatis的坑，由于项目都是采用完全外包的方式进行开发，自主把控的程度较弱，很难对代码进行走查。对我来说，这次就当做是自省吧！

大家在使用框架时，还遇到过哪些“坑”呢？一起来交流吧~

原创，更多精彩请关注：@空心小窝头