MyBatis踩坑实录：那些不报错但让你debug到深夜的Bug

笑四少 發表於 2025-12-24 09:38:00

MyBatis踩坑实录：那些不报错但让你debug到深夜的Bug

<blockquote>
早上刚到公司，打开电脑，写着需求听着歌。突然钉钉一响，测试发来消息："你那个接口报错了"。打开日志一看，MyBatis又炸了。
</blockquote>
说实话，MyBatis这玩意儿平时挺好用的，但有时候报的错真让人摸不着头脑。尤其是那种本地跑得好好的，一上线就炸的Bug，简直让人怀疑人生。今天就记录两个让我debug到深夜的坑，它们都有个共同特点：代码看起来完全没问题，但运行时就是莫名其妙地报错。
如果你也被MyBatis折磨过，这篇文章可能会让你会心一笑：原来不是我一个人踩过这些坑😂。
<img src="https://img2024.cnblogs.com/blog/3703499/202512/3703499-20251224093434309-1370579322.png">
<h2 id="坑位一arraysaslist-遇上老版本mybatis32x版本">坑位一：Arrays.asList() 遇上老版本MyBatis（3.2.x版本）</h2>
<h3 id="事故现场">事故现场</h3>
周五下午四点半（是的，Bug总是在快下班时出现），测试环境突然报了个令人头大的异常：
<pre><code class="language-java"> "org.mybatis.spring.MyBatisSystemException: nested exception is org.apache.ibatis.builder.BuilderException: Error evaluating expression 'userCode.size() > 0'. Cause: org.apache.ibatis.ognl.MethodFailedException: Method "size" failed for object
at org.mybatis.spring.MyBatisExceptionTranslator.translateExceptionIfPossible(MyBatisExceptionTranslator.java:73)
at org.mybatis.spring.SqlSessionTemplate$SqlSessionInterceptor.invoke(SqlSessionTemplate.java:364)
at $Proxy15.selectList(Unknown Source)
at org.mybatis.spring.SqlSessionTemplate.selectList(SqlSessionTemplate.java:194)
at org.apache.ibatis.binding.MapperMethod.executeForMany(MapperMethod.java:114)
at org.apache.ibatis.binding.MapperMethod.execute(MapperMethod.java:58)
at org.apache.ibatis.binding.MapperProxy.invoke(MapperProxy.java:43)
at $Proxy18.fetchOrder(Unknown Source)
at com.xx.xx.server.impl.XX.fetchOrderByUnitNo(RechargeCardBillServiceImpl.java:351)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:198)
at $Proxy26.fetchOrderByUnitNo(Unknown Source)
at com.ofpay.ofdc.task.AbstractRechargeTask.run(AbstractRechargeTask.java:65)
at java.lang.Thread.run(Thread.java:662)
</code></pre>
看到这个异常，我第一反应是：什么鬼？size()方法还能调用失败？
来看看出问题的代码：
<pre><code class="language-java">// Controller层
List<String> userCodes = Arrays.asList("aaa", "bbb", "ccc");
orderService.fetchOrderByUserCodes(userCodes);
</code></pre>
<pre><code class="language-xml">
<select id="fetchOrder" resultType="Order">
SELECT * FROM t_order
WHERE 1=1
<if test="userCode != null and userCode.size() > 0">
 AND user_code IN
 <foreach collection="userCode" item="code" open="(" close=")" separator=",">
 #{code}
 </foreach>
</if>
</select>
</code></pre>
这代码看起来没啥问题啊？userCode不为空，调个size()方法判断长度，天经地义。但它就是报错了，而且是偶现（一般偶现都有大坑）。
<h3 id="先说解决方案">先说解决方案</h3>
一顿ChatGPT + Google + Stack Overflow搜索后，找到了三种解决办法：
方案1：改入参类型（最快）
<pre><code class="language-java">// 把Arrays.asList返回的"假ArrayList"转成真正的ArrayList
List<String> userCodes = new ArrayList<>(Arrays.asList("aaa", "bbb", "ccc"));
</code></pre>
改完重新发布，问题秒解决。测试验证通过，终于可以下班了。
方案2：改XML表达式（不改Java代码）
<pre><code class="language-xml">
<if test="userCode != null and userCode.length > 0">
AND user_code IN ...
</if>
</code></pre>
这个方案也能work，而且不用改业务代码，改完就能用。
方案3：升级MyBatis版本（治本之策）
<pre><code class="language-xml">
<dependency>
<groupId>org.mybatis</groupId>
<artifactId>mybatis</artifactId>
<version>3.2.8</version> 
</dependency>


<dependency>
<groupId>org.mybatis</groupId>
<artifactId>mybatis</artifactId>
<version>3.5.13</version>
</dependency>
</code></pre>
不过这个方案需要做全面的回归测试，周五晚上就算了，留到下周慢慢搞。
<h3 id="刨根问底这到底是个啥坑">刨根问底：这到底是个啥坑？</h3>
线上问题解决了，但总感觉哪里不对劲。周末闲着没事，决定把这个诡异的异常刨根问底搞清楚。翻了半天资料，终于明白是怎么回事了。
第一层问题：类型不同
<code>Arrays.asList()</code> 返回的不是我们熟悉的 <code>java.util.ArrayList</code>，而是 <code>java.util.Arrays</code> 的一个私有静态内部类 <code>Arrays$ArrayList</code>。
写个简单的测试验证一下：
<pre><code class="language-java">List<String> list1 = Arrays.asList("a", "b", "c");
List<String> list2 = new ArrayList<>(Arrays.asList("a", "b", "c"));

System.out.println(list1.getClass());
// 输出: class java.util.Arrays$ArrayList

System.out.println(list2.getClass());
// 输出: class java.util.ArrayList
</code></pre>
看到没？一个是<code>Arrays$ArrayList</code>，一个是<code>ArrayList</code>，虽然都实现了List接口，但类型完全不同。
第二层问题：访问权限异常
MyBatis用OGNL表达式引擎来解析XML中的条件判断（比如 <code>userCode.size() > 0</code>）。当OGNL尝试通过反射调用 <code>Arrays$ArrayList</code> 的 <code>size()</code> 方法时，发现这个类是 <code>private static class</code>（私有静态内部类）。
虽然 <code>size()</code> 方法本身是 <code>public</code> 的，但因为类本身是 <code>private</code> 修饰符，OGNL在反射访问时需要调用 <code>setAccessible(true)</code> 来绕过权限检查。问题就出在这里！
第三层问题：并发Bug（重点来了！）
老版本MyBatis在处理反射时有个并发问题：当需要调用私有类的方法时，会先设置 <code>accessible = true</code>，调用完再设回 <code>false</code>。但这个操作没有加锁！（非原子性）
想象一下这个场景：
<ul>
<li>线程A：设置 <code>accessible = true</code>，准备调用方法</li>
<li>线程B：也设置 <code>accessible = true</code>，然后调用方法，再设回 <code>false</code></li>
<li>线程A：此时去调用方法，发现 <code>accessible</code> 已经被B改成 <code>false</code> 了，boom！💥</li>
</ul>
这就是为什么这个Bug偶尔才出现，因为它本质上是个并发问题！只有在高并发场景下，多个线程同时调用这个接口时才会触发。
GitHub上有人早在2014年就提了这个issue：mybatis/mybatis-3#384
后来MyBatis在3.3.x版本修复了这个问题，对反射操作加了同步控制，确保 <code>accessible</code> 的设置和方法调用是原子操作。
<hr>
<h2 id="坑位二参数传0sql条件神秘消失之谜">坑位二：参数传0，SQL条件神秘消失之谜</h2>
<h3 id="又一个周五的故事">又一个周五的故事</h3>
是的，又是周五下午（墨菲定律：Bug永远在周五出现😭）。需求很简单：查询所有"待支付"状态（status=0）的订单。十分钟写完代码：
<pre><code class="language-java">// Service层
public List<Order> queryPendingOrders() {
return orderMapper.queryOrderByStatus(0);// 0表示待支付
}
</code></pre>
<pre><code class="language-xml">
<select id="queryOrderByStatus" resultType="Order">
SELECT * FROM t_order
WHERE 1=1
<if test="status != null and status != ''">
 AND status = #{status}
</if>
</select>
</code></pre>
本地测试，完美运行。提交代码，合并主干，发布测试环境。心想这次稳了，准备提前收拾东西下班。
结果半小时后，测试同学发来消息："这个接口有问题啊，怎么把所有状态的订单都查出来了？我要的是status=0的订单。"
我一脸懵逼：？？？不可能啊，我刚测过的，明明没问题！
打开测试环境日志，执行的SQL是：
<pre><code class="language-sql">SELECT * FROM t_order WHERE 1=1
</code></pre>
WHERE后面的status条件呢？被吃了？
<h3 id="debug之旅">Debug之旅</h3>
我在本地打断点，一步步调试：
<ol>
<li>Controller层传入的参数：<code>status = 0</code> ✅</li>
<li>Service层收到的参数：<code>status = 0</code> ✅</li>
<li>MyBatis执行的SQL：<code>WHERE 1=1</code> ❌</li>
</ol>
问题肯定出在XML的if判断上。盯着这行看了好几分钟：
<pre><code class="language-xml"><if test="status != null and status != ''">
</code></pre>
突然灵光一现：会不会是 0 被判定成了空字符串？
赶紧改成这样试试：
<pre><code class="language-xml"><if test="status != null">
AND status = #{status}
</if>
</code></pre>
重新发布，问题解决！测试环境查询status=0的订单，正常返回了。
<h3 id="原理揭秘ognl的类型转换陷阱">原理揭秘：OGNL的类型转换陷阱</h3>
这又是一个MyBatis（准确说是OGNL）的经典坑。这个坑比第一个还隐蔽，因为它不会报错，而是悄悄地把你的条件吃掉。
OGNL的求值逻辑
MyBatis的 <code><if></code> 标签用的是OGNL表达式引擎。当你写 <code>status != ''</code> 时，OGNL内部会经历这样的判断流程：
<ol>
<li>先通过 <code>OgnlCache.getValue()</code> 获取表达式的值（这里表达式返回了false）</li>
<li>然后在 <code>ExpressionEvaluator.evaluateBoolean()</code> 中判断这个值，根据返回的不同类型作不同判断，最终返回boolean类型结果。</li>
</ol>
先看第二步！OGNL对不同类型有不同的判断逻辑：
<pre><code class="language-java">// ExpressionEvaluator.evaluateBoolean()方法 OGNL的判断逻辑
public boolean evaluateBoolean(String expression, Object parameterObject) {
// 这里value返回的是false
Object value = OgnlCache.getValue(expression, parameterObject);
if (value instanceof Boolean) {
// 因此会走到这里，返回false
return (Boolean) value;
}
if (value instanceof Number) {
return new BigDecimal(String.valueOf(value)).compareTo(BigDecimal.ZERO) != 0;
}
return value != null;
}
</code></pre>
类型转换的坑
当你写 <code>status != ''</code> 时，从<code>OgnlCache.getValue()</code>往下不断追溯，OGNL最终会调用 <code>compareWithConversion</code> 方法做类型转换比较。这个方法会把两边的值都转成同一类型再比较：
<ul>
<li>数值 <code>0</code> 会被转成 <code>double类型：0.0</code></li>
<li>空字符串 <code>""</code> 也会被转成 <code>double类型：0.0</code></li>
</ul>
结果就是 <code>0 == ""</code> 被判定为 <code>true</code>，导致 <code>status != ''</code> 返回 <code>false</code>，你的if条件不成立，SQL条件就没了！
为什么本地测试没问题？
是因为我本地测试时传的参数是 <code>status=1</code> 或其他非0值，而测试环境刚好传了 <code>status=0</code>。这种Bug特别隐蔽，因为它不会报错，只是查询结果不符合预期。
这个坑的适用范围：
<ul>
<li>参数是数值类型（Integer、Long等）的 0</li>
<li>XML中写了 <code>!= ''</code> 的空字符串判断</li>
<li>字符串"0"不受影响（<code>"0" != ''</code> 正常判定为true）</li>
</ul>
感兴趣的可以自己去看看MyBatis源码中的 <code>ExpressionEvaluator</code> 类和OGNL的 <code>OgnlOps.compareWithConversion</code> 方法，就能明白整个转换过程了。
<h3 id="正确姿势大全">正确姿势大全</h3>
根据不同场景，我总结了几种写法：
场景1：参数是Integer/Long等包装类型
<pre><code class="language-xml">
<if test="status != null">
AND status = #{status}
</if>
</code></pre>
场景2：参数可能是数值也可能是字符串
<pre><code class="language-xml">
<if test="status != null and (status != '' or status == 0)">
AND status = #{status}
</if>
</code></pre>
场景3：字符串类型参数
<pre><code class="language-xml">
<if test="userName != null and userName != ''">
AND user_name = #{userName}
</if>
</code></pre>
<h3 id="避坑建议">避坑建议</h3>
<ol>
<li>
数值类型参数，别用空字符串判断
<pre><code class="language-xml">
<if test="count != null and count != ''">


<if test="count != null">
</code></pre>
</li>
<li>
记住数值类型和字符串类型要区分对待
<ul>
<li>数值类型（Integer、Long）：只判<code>!= null</code></li>
<li>字符串类型：判<code>!= null and != ''</code></li>
</ul>
</li>
<li>
确实需要兼容的场景，明确写出0的判断
<pre><code class="language-xml"><if test="value != null and (value != '' or value == 0)">
</code></pre>
</li>
<li>
升级MyBatis版本并不能解决这个问题（因为这是OGNL的特性，不是bug）
</li>
</ol>
<hr>
<h2 id="总结与最佳实践">总结与最佳实践</h2>
这两个问题虽然表现形式不同，但都源于OGNL表达式引擎的特殊行为。理解这些陷阱背后的机制，能帮助我们写出更健壮的MyBatis代码。
<h3 id="核心要点">核心要点</h3>
<ol>
<li>
Arrays.asList()的陷阱
<ul>
<li>
<code>Arrays.asList()</code> 返回的不是真正的ArrayList，是Arrays的私有静态内部类
</li>
<li>
老版本MyBatis（3.3.x之前）的OGNL表达式引擎：反射访问私有静态内部类的public方法时，在设置 <code>accessible = true</code>参数时会有并发问题
</li>
<li>
解决方法：包装成真正的ArrayList或升级MyBatis版本
</li>
</ul>
</li>
<li>
「if」标签：数值0判空的陷阱
<ul>
<li>
OGNL会将数值0与空字符串做类型转换比较
</li>
<li>
<code>status != ''</code> 会返回false，导致「if」表达式条件不满足，数值0的查询条件被过滤
</li>
<li>
解决方法：数值类型只判断<code>!= null</code>，不要判断空字符串
</li>
</ul>
</li>
</ol>
希望这篇文章能帮你避开这些坑，让周五下班不再是奢望 😄
<hr>
<blockquote>
文章的最后，想和你多聊两句。
技术之路，常常是热闹与孤独并存。那些深夜的调试、灵光一闪的方案、还有踩坑爬起后的顿悟，如果能有人一起聊聊，该多好。
为此，我建了一个小花园——我的微信公众号「[努力的小郑]」。
这里没有高深莫测的理论堆砌，只有我对后端开发、系统设计和工程实践的持续思考与沉淀。它更像我的数字笔记本，记录着那些值得被记住的解决方案和思维火花。
如果你觉得今天的文章还有一点启发，或者单纯想找一个同行者偶尔聊聊技术、谈谈思考，那么，欢迎你来坐坐。 
<img src="https://img2024.cnblogs.com/blog/3703499/202601/3703499-20260105210259813-964799315.jpg">
愿你前行路上，总有代码可写，有梦可追，也有灯火可亲。
</blockquote> 
来源：https://www.cnblogs.com/xzqcsj/p/19390256

頁: [1]

琼殿技术论坛's Archiver

MyBatis踩坑实录：那些不报错但让你debug到深夜的Bug