说实话，作为一名在Java开发领域摸爬滚打多年的老兵，我对MyBatis这个框架感情挺复杂的。平时用它写业务代码，那叫一个丝滑，SQL控制力强，XML配置起来也顺手。但是一旦遇到那种“kan起来逻辑完美无缺，跑起来却莫名其妙”的诡异Bug，它绝对Neng让你在深夜的办公室里怀疑人生。

今天要聊的这两个坑，dou是我亲身经历过的“血泪史”。它们dou有一个共同点：代码写得人模人样，甚至本地测试dou通过了结果一上测试环境或者高并发场景，立马给你脸色kan。Ru果你也曾被MyBatis折磨过不妨来kankan这些场景，说不定你会会心一笑：原来不是我一个人这么倒霉。

事情发生在一个周五的下午，大概四点半左右——没错，就是程序员Zui容易出事的“魔鬼时刻”。钉钉突然响了测试同学带着焦急的语气发来消息：“哥，那个订单查询的接口报错了日志里全是异常，你快kankan。”

我心里咯噔一下赶紧打开测试环境的日志服务器。满屏红色的报错信息扑面而来核心异常信息大概是这样的：

org.apache.ibatis.builder.BuilderException: Error evaluating expression 'userCode.size> 0'. 
Cause: org.apache.ibatis.ognl.MethodFailedException: Method "size" failed for object  

kan到这个报错，我第一反应是懵圈的。什么鬼？size方法可是List接口Zui基础的方法了怎么可Neng调用失败？而且提示说是非法访问异常，这明明是个public方法啊！

为了搞清楚状况，我回过头去kan业务代码。Controller层的逻辑非常简单，就是接收前端传来的几个字符串，转成List传给Service：

// Controller层
List userCodes = Arrays.asList;
orderService.fetchOrderByUserCodes;

对应的XML映射文件里SQL也是中规中矩：

    SELECT * FROM t_order
    WHERE 1=1
    
        AND user_code IN
        
            #{code}
        
    

这代码kan起来简直无懈可击。userCode不为空，调个size方法判断一下长度，完全是天经地义的操作。但它就是报错了而且还是偶现的——这种偶现的Bug通常意味着背后藏着geng深层的机制问题。

我盯着这行代码kan了足足五分钟，手里的咖啡dou凉了。突然灵光一闪，我想到了一个被hen多开发者忽略的细节：Arrays.asList的返回值。

大家平时可Nengdou习惯性地以为Arrays.asList吐出来的就是那个标准的java.util.ArrayList，其实大错特错！它返回的是java.util.Arrays类内部定义的一个私有静态内部类——Arrays$ArrayList。

我们Ke以写个简单的测试来验证一下：

List list1 = Arrays.asList;
List list2 = new ArrayList<>);
System.out.println);  // 输出: class java.util.Arrays$ArrayList
System.out.println);  // 输出: class java.util.ArrayList

kan到了吧？虽然它们dou实现了List接口，但在JVM眼里它们的“户口”完全不同。一个是Arrays的私有亲信，一个是正儿八经的ArrayList。

这就引出了问题的核心。MyBatis在解析XML中的时底层使用的是OGNL表达式引擎。当OGNL尝试通过反射去调用Arrays$ArrayList的size方法时它发现这个类是private static修饰的。

虽然size本身是public的，但因为它的“主人”是私有类，OGNL在反射访问时必须先调用setAccessible来暴力破解权限检查。问题就出在这个操作上！

在老版本的MyBatis中，这个反射操作存在一个严重的并发隐患：设置accessible为true、调用方法、再设回false，这一连串操作并不是原子性的，而且没有加锁保护！

想象一下线程A正在修改这个类的访问权限，线程B同时也跑过来要修改。两个线程互相干扰，导致权限状态混乱，Zui终抛出了IllegalAccessException。这就是为什么这个Bug在本地hen难复现，而在流量稍大的测试环境却偶尔炸雷的原因。

找到了病根，治病就简单多了。我有三个方案供你选择：

方案1：Zui稳妥的改法

在Java代码里把那个“假ArrayList”转成真正的ArrayList。这样OGNL访问起来就毫无压力了。

// 把Arrays.asList返回的"者"转成真正的ArrayList
List userCodes = new ArrayList<>);

方案2：改XML表达式

Ru果你不想动业务代码，也Ke以在XML里绕个弯子。OGNL对数组类型的处理逻辑不同，我们Ke以利用length属性替代size方法：

    AND user_code IN ...

方案3：升级MyBatis版本

    org.mybatis
    mybatis
    3.5.15

后来的MyBatis版本在3.4.1之后修复了这个issue，对反射操作加了同步控制，确保accessible的设置和方法调用是原子操作。不过升级依赖这种事，周五晚上还是别折腾了容易引出新问题，还是留到下周再慢慢搞吧。

// Service层
public List queryPendingOrders {
    return orderMapper.queryOrderByStatus;  // 0表示待支付
}

    SELECT * FROM t_order
    WHERE 1=1
    
        AND status = #{status}
    

SELECT * FROM t_order WHERE 1=1

    AND status = #{status}

    AND status = #{status}