庄周梦蝶

生活、程序、未来
   :: 首页 ::  ::  :: 聚合  :: 管理

高性能EL——Fel探秘,兼谈EL

Posted on 2011-09-17 12:52 dennis 阅读(8123) 评论(5)  编辑  收藏 所属分类: java源码解读计算机科学与基础
    Fel是最近javaeye比较火的关键词,这是由网友lotusyu开发的一个高性能的EL,从作者给出的数据来看,性能非常优异,跟前段时间温少开源的Simple EL有的一拼。首先要说,这是个好现象,国内的开源项目越来越多,可以看出开发者的水平是越来越高了,比如我最近还看到有人开源的类似kestel的轻量级MQ——fqueue也非常不错,有兴趣可以看下我的分析《fqueue初步分析》。

    进入正文,本文是尝试分析下Fel的实现原理,以及优缺点和aviator——我自己开源的EL之间的简单比较。

    Fel的实现原理跟Simple EL是类似,都是使用template生成中间代码——也就是普通的java代码,然后利用javac编译成class,最后运行,当然,这个过程都是动 态的。JDK6已经引入了编译API,在此之前的版本可以调用sun的类来编译,因为javac其实就是用java实现的。回到Fel里 面,FelCompiler15就是用 com.sun.tools.javac.Main来编译,而FelCompiler16用标准的javax.tools.JavaCompiler来编译的。

    文法和语法解释这块是使用antlr这个parse generator生成的,这块不多说,有兴趣可以看下antlr,整体一个运行的过程是这样:

    expression string -> antlr -> AST -> comiple -> java source template -> java class -> Expression 

    这个思路我在实现aviator之前就想过,但是后来考虑到API需要用的sun独有的类,而且要求classpath必须有tools.jar这个依赖包,就放弃了这个思路,还是采用ASM生成字节码的方式。题外,velocity的优化可以采用这个思路,我们有这么一个项目是这么做的,也准备开源了。

 

    看看Fel生成的中间代码,例如a+b这样的一个简单的表达式,假设我一开始不知道a和b的类型,编译是这样:

    FelEngine fel = new FelEngineImpl();  
    Expression exp 
=  fel.compile("a+b"null); 

    我稍微改了下FEL的源码,让它打印中间生成的java代码,a+b生成的中间结果为:

    package com.greenpineyu.fel.compile;  
      
    
import com.greenpineyu.fel.common.NumberUtil;  
    
import com.greenpineyu.fel.Expression;  
    
import com.greenpineyu.fel.context.FelContext;  
    
import org.apache.commons.lang.ObjectUtils;  
    
import org.apache.commons.lang.StringUtils;  
      
    
public class Fel_0  implements Expression{  
      
        
public Object eval(FelContext context) {  
            java.lang.Object var_1 
= (java.lang.Object)context.get("b");   //b  
            java.lang.Object var_0 = (java.lang.Object)context.get("a");   //a  
            return (ObjectUtils.toString(var_0))+(ObjectUtils.toString(var_1));  
        }  
    } 

     可见,FEL对表达式解析和解释后,利用template生成这么一个普通的java类,而a和b都从context中获取并转化为Object类型,这里没有做任何判断就直接认为a和b是要做字符串相加,然后拼接字符串并返回。

 

     问题出来了,因为没有在编译的时候传入context(我们这里是null),FEL会将a和b的类型默认都为java.lang.Object,a+b解释为字符串拼接。但是运行的时候,我完全可以传入a和b都为数字,那么结果就非常诡异了:

     FelEngine fel = new FelEngineImpl();  
      
    Expression exp 
= fel.compile("a+b"null);  
    Map
<String, Object> env=new HashMap<String, Object>();  
    env.put(
"a"1);  
    env.put(
"b"3.14);  
    System.out.println(exp.eval(
new MapContext(env))); 

输出:

    13.14 

    1+3.14的结果,作为字符串拼接就是13.14,而不是我们想要的4.14。如果将表达式换成a*b,就完全运行不了

    com.greenpineyu.fel.exception.CompileException: package com.greenpineyu.fel.compile;  
      
    
import com.greenpineyu.fel.common.NumberUtil;  
    
import com.greenpineyu.fel.Expression;  
    
import com.greenpineyu.fel.context.FelContext;  
    
import org.apache.commons.lang.ObjectUtils;  
    
import org.apache.commons.lang.StringUtils;  
      
    
public class Fel_0  implements Expression{  
      
        
public Object eval(FelContext context) {  
            java.lang.Object var_1 
= (java.lang.Object)context.get("b");   //b  
            java.lang.Object var_0 = (java.lang.Object)context.get("a");   //a  
            return (var_0)*(var_1);  
        }  
    }  
      
    [Fel_0.java:
14: 运算符 * 不能应用于 java.lang.Object,java.lang.Object]  
        at com.greenpineyu.fel.compile.FelCompiler16.compileToClass(FelCompiler16.java:
113)  
        at com.greenpineyu.fel.compile.FelCompiler16.compile(FelCompiler16.java:
87)  
        at com.greenpineyu.fel.compile.CompileService.compile(CompileService.java:
66)  
        at com.greenpineyu.fel.FelEngineImpl.compile(FelEngineImpl.java:
62)  
        at TEst.main(TEst.java:
14)  
    Exception in thread 
"main" java.lang.NullPointerException  
        at TEst.main(TEst.java:
18

 

    这个问题对于Simple EL同样存在,如果没有在编译的时候能确定变量类型,这无法生成正确的中间代码,导致运行时出错,并且有可能造成非常诡异的bug。

 

    这个问题的本质是因为Fel和Simple EL没有自己的类型系统,他们都是直接使用java的类型的系统,并且必须在编译的时候确定变量类型,才能生成高效和正确的代码,我们可以将它们称为“强类型的EL“。

 

    现在让我们在编译的时候给a和b加上类型,看看生成的中间代码:

    FelEngine fel = new FelEngineImpl();  
    fel.getContext().set(
"a"1);  
    fel.getContext().set(
"b"3.14);  
    Expression exp 
= fel.compile("a+b"null);  
    Map
<String, Object> env = new HashMap<String, Object>();  
    env.put(
"a"1);  
    env.put(
"b"3.14);  
    System.out.println(exp.eval(
new MapContext(env))); 

    查看中间代码:

    package com.greenpineyu.fel.compile;  
      
    
import com.greenpineyu.fel.common.NumberUtil;  
    
import com.greenpineyu.fel.Expression;  
    
import com.greenpineyu.fel.context.FelContext;  
    
import org.apache.commons.lang.ObjectUtils;  
    
import org.apache.commons.lang.StringUtils;  
      
    
public class Fel_0  implements Expression{  
      
        
public Object eval(FelContext context) {  
            
double var_1 = ((java.lang.Number)context.get("b")).doubleValue();   //b  
            double var_0 = ((java.lang.Number)context.get("a")).doubleValue();   //a  
            return (var_0)+(var_1);  
        }  
    } 

可以看到这次将a和b都强制转为double类型了,做数值相加,结果也正确了:

    4.140000000000001 

    Simple EL我没看过代码,这里猜测它的实现也应该是类似的,也应该有同样的问题。

    相比来说,aviator这是一个弱类型的EL在编译的时候不对变量类型做任何假设,而是在运行时做类型判断和自动转化。过去提过,我给aviator的定位是一个介于EL和script之间的东西,它有自己的类型系统。 例如,3这个数字,在java里可能是long,int,short,byte,而aviator统一为AviatorLong这个类型。为了在这两个类 型之间做适配,就需要做很多的判断和box,unbox操作。这些判断和转化都是运行时进行的,因此aviator没有办法做到Fel这样的高效,但是已 经做到至少跟groovy这样的弱类型脚本语言一个级别,也超过了JXEL这样的纯解释EL,具体可以看这个性能测试

 

   强类型还是弱类型,这是一个选择问题,如果你能在运行前就确定变量的类型,那么使用Fel应该可以达到或者接近于原生java执行的效率,但是失去了灵活性;如果你无法确定变量类型,则只能采用弱类型的EL。

 

   EL涌现的越来越多,这个现象有点类似消息中间件领域,越来越多面向特定领域的轻量级MQ的出现,而不是原来那种大而笨重的通用MQ大行其道,一方面是互 联网应用的发展,需求不是通用系统能够满足的,另一方面我认为也是开发者素质的提高,大家都能造适合自己的轮子。从EL这方面来说,我也认为会有越来越多 特定于领域的,优点和缺点一样鲜明的EL出现,它们包含设计者自己的目标和口味,选择很多,就看取舍。


评论

# re: 高性能EL——Fel探秘,兼谈EL  回复  更多评论   

2011-09-17 14:38 by GhostZhang
强人啊!

# re: 高性能EL——Fel探秘,兼谈EL  回复  更多评论   

2011-09-18 08:39 by tb
强人

# re: 高性能EL——Fel探秘,兼谈EL  回复  更多评论   

2011-09-19 11:06 by kino.lucky
前段时间,也看到Fel的介绍,对这个挺感兴趣的,但没研究过,谢谢你的文章。
对这个用途我有一点想法,在现在做互联网项目的时候,不管是前后端通信,还是做api的时候,用到json的地方越来越多,但后端生成json字符串的时候总感觉不够好,一是用各种java data bean 组装成一个JSONObject或Map,然后转化成一个json字符串,但这种方式一点都不直观,对后面维护代码和变更都不方便。后来就想到用模板文件,比如用FreeMarker或Velocity做一个Json的映射文件,这样是直观了很多,一目了然,修改也很方便,但是感觉FreeMarker和Velocity又不适合,性能不好也太重量级。记得去年就看到你的aviator(当时记得说到命名的由来,映像挺深的),发现性能不错,当时就想能不能用于json转换。所以我在想能不能开发一个额外的工具包,专门用于复杂Json对象的高效生成。呵呵,不知有没有人和我一样的想法?

# re: 高性能EL——Fel探秘,兼谈EL  回复  更多评论   

2011-09-19 21:30 by zkgale
不知道能不能分析一下nutz的el实现呢?
它主要思路是通过逆波兰进行转换,并生成一个执行链

# re: 高性能EL——Fel探秘,兼谈EL[未登录]  回复  更多评论   

2011-12-28 11:27 by James
拜读了大师的aviator源码,发现词法分析和语法分析是大师手工写的嗯,非常强大.由于编译原理学的不是很好,对于ExpressionParser里面的代码看的不是很明白,感觉上是根据BNF转换成的代码.
希望大师指点一二,提供一些参考资料.很想自己也写个类似的东东提高一下.

只有注册用户登录后才能发表评论。


网站导航: