mybatis 3.3.0之前版本的一个空指针BUG

　　OgnlCache.getValue()方法的源码比较简单，思路和我们使用其他表达式框架（如google的aviator）类似，即为已经编译好的表达式构建一个缓存并尝试从该缓存中获取编译后表达式，如果未能获取到则进行编译并存入缓存：

　　可以看到，表达式被编译成一个Node对象，查看一下接口Node的源码，发现其具有parent、child相关方法，因此可以大胆猜测Node应该是一个树状结构：

　　使用IDEA自带的功能，我们简单查看一下Node的子类，种类还是挺丰富的，对应了mybatis标签中各式各样的表达式语法：

　　接下来开始debug，一路前进来到Ognl类的getValue方法，如下图所示：

　　Debug控制台中的信息证实了我们之前关于Node的猜想：“表达式编译后的Node为一棵树”，展开这颗tree，详细看看树的结构：

　　由此，我们推测表达式的计算顺序应该是沿着叶子节点向其父节点的顺序逐层递归求值，最终在根节点求得整颗树的值。进入上面图片中断点停留的“Object result = ((Node)tree).getValue(ognlContext, root)”方法，调用栈跳转到SimpleNode的getValue方法，并最终进入同一个类的evaluateGetValueBody方法：

　　到这里就能明显看出问题了，这段神奇的代码在没有锁等同步措施保护的情况下，直接修改非并发安全的共享成员变量constantValueCalculated、hasConstantValue、constantValue的值，明显的竞态条件，但根据这个并不足以得到产生空指针异常的原因，我们继续向前debug：

　　根据控制台信息，当前执行的表达式是ASTAnd，由于它并不是一个常量，因此this.isConstant(context)返回false并赋值给成员变量hasConstantValue（它的默认值也是false），可以看到，无论constantValueCalculated值为true还是false，非常量表达式最终都会通过上图中的高亮行来求得表达式的值，所以对于非常量表达式，这段代码其实没有并发安全问题；但反之，对于常量表达式，这段代码有并发安全问题，因为hasConstantValue会被更新为true，那么在并发的情况下，会出现一个线程通过执行上图中131行代码求得常量值，另外一个线程只“看到”了constantValueCalculated和hasConstantValue的最新值true而没有“看到”constantValue的最新值，导致执行135行代码返回null。