基于ANTLR语法树编写解释引擎最佳实践

Tiny模板引擎的实现方式原来是采用的编译方式，最近发生了一些问题，因此我觉得有必要把编译方式调整为解释方式，为此就开始了此次实现活动。

编译方式存在的问题

当时采用编译方式，主要是考虑到编译方式在运行时不必再去遍历语法树，因此就采用了编译方式。但是在实际应用当中，出现了如下问题：

文件路径冲突的问题

由于采用的是编译方式，这个时候就存在在一个选择，即：Java源代码落地或不落地的选择。如果Java文件不落地，则在有问题的时候，如果想要进行代码调试（虽然这种场景并不多见），那么就没有源代码可供调试。如果Java代码落地，则会存在一个问题，那就是资源文件在磁盘文件中产生冲突的问题。

同样的问题对于class文件也存在，如果不落地，那么每次应用重启动的时候，都要重新编译这些文件以产生class文件；如果落地，则也会产生冲突的问题。

当然，Tiny模板引擎通过增加一个配置项，解决了这个冲突的问题，但是由于增加了一个配置项，从客观上增加了维护人员的工作量，也容易造成当维护人员不了解这里面的道道，忘记设置从而导致在一台服务器中部署多个Tiny应用时多个应用中的模板文件生成的java文件和class文件的冲突，从而导致出现问题。

PermSize内存占用问题

采用编译方式的时候，由于每个模板文件都要生成一个类，每个宏也要生成一个类，在宏调用过程中，也要生成一些类。（本来是可以不生成这些类的，但是由于Tiny模板引擎支持了一些非常有用的特性，所以宏调用时时采用编译方式，就要生成一些内嵌类来完成）。这样，就会生成大量的Java类，从工程非常大的时候，就会导致PermSize战胜非常大。尤其是在系统还在调试的时候，模板文件变化的时候，就要重新编译生成新的类，为了避免必须重新启动应用服务器才能生生效，因此采用了自己编写ClassLoader的方式来达到即时刷新的问题，但是由于Java的垃圾回收机制，决定了垃圾不是及时回收的，但是由于每个类都要有一个ClassLoader来支持，以便及时替换，因此这会进一步放大内存的占用。

加载速度比较长的问题

由于Tiny模板引擎中提供了宏，而这些宏可以独立存在，因此在应用启动的时候就必须加载所有的宏到内存中，以便查找。所以就导致第一次启动的时候，由于要编译所有的宏文件并加载之，导致启动速度非常慢。在以后的启动的时候，也必须检测模板文件与生成的类是否一致，是否有被修改过，当a项目规模比较大的时候，这个时间也是比较长的。尤其是在开发期，启动时间增加10秒，都会让开发人员感觉到难以忍受。

访问速度的问题

采用编译方式的问题，在访问上也有一些问题。

为了提升应用启动时间，只有宏文件是在启动时预选编译好并加载了的，而模板文件和布局文件则没有这种待遇，这就导致如果在访问的时候，第一次访问的时候，需要编译模板文件为java文件，再把java文件编译为class文件，如果这次访问还用到了布局文件，还import了其它的模板文件，那么悲剧了，第一个访问者可能要多等待几秒钟的时间。同时，为了避免多次编译情况的地生，还要增加同步锁，这样会进一步影响到访问的效率。

具体还没有测试过ClassLoader太多对性能有多大的影响，但是毛估估是有一定影响的，毕竟要增加查找的层数。干的活多了，干的活慢了也是自然的，人是这样，计算机也是同样的道理。

采用解释方式带来的好处

由于采用解释方式，因此不必生成java源文件和class文件，因此也就不存在文件路径冲突的问题；同样也不存在PermSize和众多ClassLoader大量占用内存的问题。

由于采用解释方式，第一次加载，只定性扫描部分关系的内容即可，因此扫描速度非常快；只有在直接执行的时候，才需要更详细的处理，同时由于不需要进行编译，不需要做同步处理，因此加载速度会比编译方式高许多，尤其是和编译方式的第一次加载时间相比。

访问速度方面的问题，我原来的感觉来说，感觉编译方式会快一些，毕竟它不用再云遍历语法树，但是实际执行下来，感觉解释方式大致有一倍左右的提升，我分析了一下原因，大致可以认为是如下原因：1.由于Java的优化策略，导致使用频率高的访问会进行深度性能优化，采用解释方式，由于用到的就是那几个函数，因此可以很快满足Java虚拟机的要求，更早的进行深度优化；2.由于解释方式和编译方式相比，可以采用更优化的解决方案，因此遍历语法树的时间由避免做一些事情弥补回来了，因此感受性能反而更高一点点。总之，这次编译改解释，的效果还是明显的，各方面全面让我满意，尤其是前面担心的执行效率方面也有大概50%左右的提升是让我喜出望外的。还有一个意外之喜是通过把编译方式改成解释执行方式，代码规模缩小了近一半，由原来的8000+行，变成4000+行。同时，由于不必要依赖JDT，antlr也只要依赖runtime包即可，还顺便减少了3M的WAR包大小。

OK，说了这么多，那就说说这次改造过程。

由于团队去岛国旅游，当时把这个任务交给一个留守同学来完成，但是前后两周的时候，没有提交出我满意的结果，由于看不到后续完成的时间节点，没有办法，只好我老先生亲自动手来完成了，OK开工，相信仔细阅读下面一节内容的同学，会对ANTLR解释引擎的开发有深入了解，甚至拿我的代码照葫芦画瓢，直接就可用。

解释引擎改造实录

解释引擎总控类

解释引擎总控类是解释引擎的核心，由于这个东东是为了Tiny模板引擎定制编写的，因此如果有同学要拿来改造，请照葫芦画瓢即可。由于类不大，我就直接贴源码上来，以便亲们理解和我下面讲解。

?


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

public class TemplateInterpreter {

    TerminalNodeProcessor[] terminalNodeProcessors = new TerminalNodeProcessor[200];

    Map<Class<ParserRuleContext>, ContextProcessor> contextProcessorMap = new HashMap<Class<ParserRuleContext>, ContextProcessor>();

    OtherTerminalNodeProcessor otherNodeProcessor = new OtherTerminalNodeProcessor();

 

 

    public void addTerminalNodeProcessor(TerminalNodeProcessor processor) {

        terminalNodeProcessors[processor.getType()] = processor;

    }

 

    public void addContextProcessor(ContextProcessor contextProcessor) {

        contextProcessorMap.put(contextProcessor.getType(), contextProcessor);

    }

 

    public TinyTemplateParser.TemplateContext parserTemplateTree(String sourceName, String templateString) {

        char[] source = templateString.toCharArray();

        ANTLRInputStream is = new ANTLRInputStream(source, source.length);

        // set source file name, it will be displayed in error report.

        is.name = sourceName;

        TinyTemplateParser parser = new TinyTemplateParser(new CommonTokenStream(new TinyTemplateLexer(is)));

        return parser.template();

    }

 

    public void interpret(TemplateEngineDefault engine, TemplateFromContext templateFromContext, String templateString, String sourceName, TemplateContext pageContext, TemplateContext context, Writer writer) throws Exception {

        interpret(engine, templateFromContext, parserTemplateTree(sourceName, templateString), pageContext, context, writer);

        writer.flush();

    }

 

    public void interpret(TemplateEngineDefault engine, TemplateFromContext templateFromContext, TinyTemplateParser.TemplateContext templateParseTree, TemplateContext pageContext, TemplateContext context, Writer writer) throws Exception {

        for (int i = 0; i < templateParseTree.getChildCount(); i++) {

            interpretTree(engine, templateFromContext, templateParseTree.getChild(i), pageContext, context, writer);

        }

    }

 

    public Object interpretTree(TemplateEngineDefault engine, TemplateFromContext templateFromContext, ParseTree tree, TemplateContext pageContext, TemplateContext context, Writer writer) throws Exception {

        Object returnValue = null;

        if (tree instanceof TerminalNode) {

            TerminalNode terminalNode = (TerminalNode) tree;

            TerminalNodeProcessor processor = terminalNodeProcessors[terminalNode.getSymbol().getType()];

            if (processor != null) {

                returnValue = processor.process(terminalNode, context, writer);

            } else {

                returnValue = otherNodeProcessor.process(terminalNode, context, writer);

            }

        } else if (tree instanceof ParserRuleContext) {

            ContextProcessor processor = contextProcessorMap.get(tree.getClass());

            if (processor != null) {

                returnValue = processor.process(this, templateFromContext, (ParserRuleContext) tree, pageContext, context, engine, writer);

            }

            if (processor == null || processor != null && processor.processChildren()) {

                for (int i = 0; i < tree.getChildCount(); i++) {

                    Object value = interpretTree(engine, templateFromContext, tree.getChild(i), pageContext, context, writer);

                    if (value != null) {

                        returnValue = value;

                    }

                }

            }

 

        } else {

            for (int i = 0; i < tree.getChildCount(); i++) {

                Object value = interpretTree(engine, templateFromContext, tree.getChild(i), pageContext, context, writer);

                if (returnValue == null && value != null) {

                    returnValue = value;

                }

            }

        }

        return returnValue;

    }

 

    public static void write(Writer writer, Object object) throws IOException {

        if (object != null) {

            writer.write(object.toString());

            writer.flush();

        }

    }

}

这个类，所以行数是80行，去掉15行的import和package，也就是65行而已，从类的职能来看，主要完成如下事宜：

  1. 管理了TerminalNodeProcessor和ParserRuleContext
  2. parserTemplateTree：解析文本内容获取语法树
  3. interpret：解释执行语法树
  4. interpret：遍历所有节点并解释执行之
  5. interpretTree：如果是TerminalNode那么找到合适的TerminalNode执行器去执行，如果找不到，则由OtherTerminalNodeProcessor去处理--实际上就是返回字符串了；如果是ParserRuleContext节点，那么就由对应的执行器去执行，执行完了看看是不是要执行子节点，如果需要，那么就继续执行子节点，否则就返回。如果这两种都不是，那就遍历所有子节点去解释执行了。

所以逻辑还是比较清晰，最复杂的核心算法也只有30行，不管是什么样层级的同学，看这些代码都没有任何难度了。

需要交待的一件事情是：为什么ContextProcessor的处理类是用Map保存的，而TerminalNodeProcessor则是用数组？这里主要是为了考虑到TerminalNode都有一个类型，用数据的方式速度更快一些。

上面说到有两个接口，一个是处理TerminalNodeProcessor,另外一个是处理ContextProcessor的，下面交待一下这两个接口。

TerminalNodeProcessor

?


1

2

3

4

public interface TerminalNodeProcessor<T extends ParseTree> {

    int getType();

    Object process(T parseTree, TemplateContext context, Writer writer) throws Exception;

}
  1. getType：用于返回处理器可处理的类型，用于解释引擎检查是不是你的菜
  2. process：真正的处理逻辑实现的地方

ContextProcessor

?


1

2

3

4

5

6

7

8

public interface ContextProcessor<T extends ParserRuleContext> {

    Class<T> getType();

 

    boolean processChildren();

 

    Object process(TemplateInterpreter interpreter, TemplateFromContext templateFromContext, T parseTree, TemplateContext pageContext, TemplateContext context, TemplateEngineDefault engine, Writer writer) throws Exception;

 

}
  1. getType：用于返回处理器可处理的类型，用于解释引擎检查是不是你的菜
  2. processChildren：用于告诉引擎，你的儿子们是自己处理好了，还是让解释引擎继续执行。返回true表示让引擎继续处理
  3. process：真正的处理逻辑实现的地方

至此，整个解析引擎的框架就搭好了，剩下要做的就是去写这些处理器了。

TerminalNodeProcessor实现类示例

其实这些实现类真的太简单了，我都不好意思贴出来，为了让大家看明白，贴几个说说意思就好

DoubleNodeProcessor

?


1

2

3

4

5

6

7

8

9

10

11

12

13

14

public class DoubleNodeProcessor implements TerminalNodeProcessor<TerminalNode> {

    public int getType() {

        return TinyTemplateParser.FLOATING_POINT;

    }

 

    public boolean processChildren() {

        return false;

    }

 

    public Object process(TerminalNode terminalNode, TemplateContext context, Writer writer) {

        String text=terminalNode.getText();

        return Double.parseDouble(text);

    }

}

这货的意思是：如果是Double类型的数据，就把字符串转换成Double值返回。

StringDoubleNodeProcessor

?


1

2

3

4

5

6

7

8

9

10

11

12

13

14

public class StringDoubleNodeProcessor implements TerminalNodeProcessor<TerminalNode> {

    public int getType() {

        return TinyTemplateParser.STRING_DOUBLE;

    }

    public boolean processChildren() {

        return false;

    }

    public Object process(TerminalNode terminalNode, TemplateContext context, Writer writer) {

        String text=terminalNode.getText();

        text=text.replaceAll("\\\\\"","\"");

        text=text.replaceAll("[\\\\][\\\\]","\\\\");

        return text.substring(1, text.length() - 1);

    }

}

这货的意思是，如果是双引号引住的字符串，那么就把里面的一些转义字符处理掉，然后把外面的双引号也去掉后返回。

其它的和这个大同小异，总之非常简单，想看的同学可以自己去看源码，这里就不贴了。

ContextProcessor类的实现示例

这里面的处理，说实际的也没有什么复杂的，主要原因是原来在写模板引擎的时候，把运行时的一些东西，进行良好的抽象，因此这里只是个简单的调用而已。这里贴2个稍微复杂的示范一下：

ForProcessor

?


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

public class ForProcessor implements ContextProcessor<TinyTemplateParser.For_directiveContext> {

 

    public Class<TinyTemplateParser.For_directiveContext> getType() {

        return TinyTemplateParser.For_directiveContext.class;

    }

    public boolean processChildren() {

        return false;

    }

    public Object process(TemplateInterpreter interpreter, TemplateFromContext templateFromContext, TinyTemplateParser.For_directiveContext parseTree, TemplateContext pageContext, TemplateContext context, TemplateEngineDefault engine, Writer writer) throws Exception {

        String name = parseTree.for_expression().IDENTIFIER().getText();

        Object values = interpreter.interpretTree(engine, templateFromContext, parseTree.for_expression().expression(),pageContext, context, writer);

        ForIterator forIterator = new ForIterator(values);

        context.put("$"+name + "For", forIterator);

        boolean hasItem = false;

        while (forIterator.hasNext()) {

            TemplateContext forContext=new TemplateContextDefault();

            forContext.setParent(context);

            hasItem = true;

            Object value = forIterator.next();

            forContext.put(name, value);

            try {

                interpreter.interpretTree(engine, templateFromContext, parseTree.block(),pageContext, forContext, writer);

            } catch (ForBreakException be) {

                break;

            } catch (ForContinueException ce) {

                continue;

            }

        }

        if (!hasItem) {

            TinyTemplateParser.Else_directiveContext elseDirectiveContext = parseTree.else_directive();

            if (elseDirectiveContext != null) {

                interpreter.interpretTree(engine, templateFromContext, elseDirectiveContext.block(), pageContext,context, writer);

            }

        }

        return null;

    }

}

这里解释一下它的执行逻辑：

  1. 首先获取循环变量名
  2. 接下来获取要循环的对象
  3. 然后构建一个循环迭代器，并在上下文中放一个循环变量进去
  4. 然后真正执行循环，如果有在循环过程中有break或continue指令，那么就执行之
  5. 如果最后一个循环也没有执行，那么检查 else 指令是否存在，如果存在就执行之

是不是非常简单？

MapProcessor

?


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

public class MapProcessor implements ContextProcessor<TinyTemplateParser.Expr_hash_mapContext> {

    public Class<TinyTemplateParser.Expr_hash_mapContext> getType() {

        return TinyTemplateParser.Expr_hash_mapContext.class;

    }

    public boolean processChildren() {

        return false;

    }

    public Object process(TemplateInterpreter interpreter, TemplateFromContext templateFromContext, TinyTemplateParser.Expr_hash_mapContext parseTree, TemplateContext pageContext, TemplateContext context, TemplateEngineDefault engine, Writer writer) throws Exception {

        List<TinyTemplateParser.ExpressionContext> expressions = parseTree.hash_map_entry_list().expression();

        List<TinyTemplateParser.ExpressionContext> expressionContexts = expressions;

        Map<String, Object> map = new HashMap<String, Object>();

        if (expressions != null) {

            for (int i = 0; i < expressions.size(); i += 2) {

                String key = interpreter.interpretTree(engine, templateFromContext, expressions.get(i), pageContext,context, writer).toString();

                Object value = interpreter.interpretTree(engine, templateFromContext, expressions.get(i + 1),pageContext, context, writer);

                map.put(key, value);

            }

        }

        return map;

    }

}

这个是个构建MAP的处理器，它的执行逻辑是:

  1. 新建个MAP对象，然后循环往MAP里put数据即可以了。
  2. 最后返回map对象

我已经拿了最复杂的两个来讲了，其它的就更简单了，因此就不再贴了，关心的同学们可以去看源代码。

总结

  1. 实际上用Java写个新的语言啥的，没有什么难的，难的是你心头的那种恐惧，毕竟现在的一些开源框架如Antlr等的支持下，做词法分析，语法树构建是非常容易的一件事情，只要规划并定义好语法规则，后面的实现并没有多复杂。
  2. 好的设计会让你受益颇多，Tiny模板引擎由编译换成解释执行，没有什么伤筋动骨的变化，只是用新的方式实现了原有接口而已
  3. 对问题的分析的深入程度决定了你代码编写的复杂程度，上次和一个人讨论时有说过：之所以你写不简单，是因为你考虑得还不够多，分析的还不够细
  4. 至此此次重构完成，正在测试当中，将在近日推出。

有关Tiny框架的内容，请访问官网：http://ww.tinygroup.org

Tiny在线文档网站，请访问：http://www.tinygroup.org/confluence/pages/viewpage.action?pageId=557323

如果想获取Tiny的源代码，请访问：http://git.oschina.net/tinyframework/tiny直接fork代码，喜欢的话，请点击watch和star关注我们的动态，支持我们。

如果你喜欢我的博客，也可以在http://my.oschina.net/tinyframework/blog查看到我写的更多的博客，必须精品；也可以到http://my.oschina.net/tinyframework/blog关注我，这样我的博客就可以第一时间推送给也，也可以看到我发的动态，绝对没有@红薯 连早晨起来解个小手也要发一下的内容，要发的必须是与Tiny息息相关的内容。

时间： 2024-11-02 12:22:29

基于ANTLR语法树编写解释引擎最佳实践的相关文章

编写react组件最佳实践

我最开始学习react的时候,看到过各种各样编写组件的方式,不同教程中提出的方法往往有很大不同.当时虽说react这个框架已经十分成熟,但是似乎还没有一种公认正确的使用方法.过去几年中,我们团队编写了很多react组件,我们对实现方法进行了不断的优化,直到满意. 本文介绍了我们在实践中的最佳实践方式,希望能对无论是初学者还是有经验的开发者来说都有一定的帮助. 在我们开始之前,有几点需要说明: 我们是用es6和es7语法 如果你不了解展示组件和容器组件的区别,可以先阅读这篇文章 如果你有任何建议.

IBM PureApplication System 中的模式采用最佳实践

简介 过去几年,我们见证了中间件操作执行方式上的一次真正变革的开始.首先是发布了 IBM WebSphere CloudBurst Appliance 版本,然后推出了 IBM Workload Deployer 和 IBM PureApplication System 的后续版本,引入了基于模式的部署方法,这些已帮助客户在 IBM 中间件的计划.部署和管理方式上实现了根本改变.我们亲眼看到,此方法已改变了系统操作形势,还对采用它的公司中的开发和操作之间的关系产生了重大影响.这些基于模式的方法与

编写 React 组件的最佳实践

本文讲的是编写 React 组件的最佳实践, 当我一开始写 React 的时候,我记得有许多不同的方法来写组件,每个教程都大不相同.虽然从那以后 React 框架已经变得相当的成熟,但似乎仍然没有一种明确的写组件的"正确"方式. 过去一年在 MuseFind 工作中,我们的团队写过了无数的 React 组件.我们也在不断的改善方法直到我们满意为止. 这篇指南是我们建议的编写 React 组件的最佳方式.不管你是初学者还是有经验的人,我们希望它对你有用. 在开始之前,一些注意事项: 我们

基于Renascence架构的SQL查询引擎设计

基于Renascence架构的sqlite查询优化 sqlite查询优化方案是一开始是在Hw时设计的,但当时只实现一些简单case,并未完成sql的普遍支持.后面考虑到这可以做为 Renascence 架构的一个实验场景,因此将其方案做了一番修改,代码也重写了一遍,现在做成一个能支持普通sql查询的demo. sqlite架构 参考:http://wiki.dzsc.com/info/7440.html sqlite是移动设备广泛使用的轻量级数据库引擎.它主要由前端--虚拟机--后端三部分组成,

Dreamweaver中编写CSS的“最佳习惯”

由于"可视化"和操作简便,在DreamWeaver中编写CSS的朋友很多,今天我们介绍一些在Dreamweaver中编写CSS的"最佳习惯",希望对大家有所帮助. CSS正在改变网站设计的进程.为迎合不断增长的倾向于CSS的设计人员的需求,Macromedia DW MX引进了一些新的及改善过的CSS相关的特性.有了这些新的特性,你可以为未来的更新作好计划,开发与W3C标准更加兼容的站点.本文讨论在DreamWeaver中使用CSS以及突出某一特定CSS特性时的一些

编写React组件的最佳实践

在我第一次编写 React 代码的时候,我见发现许多不同的方法可以用来编写组件,不同教程教授的内容也大不相同.尽管从那时候起框架已经相当成熟,但并没有一种固定的"正确"方式指导. 在 MuseFind 工作的一年里,我们的团队编写了许多 React 组件,后期我们对方法进行了优化直到满意为止. 本指南描述了我们推荐的最佳实践,不管你是一名初学者还是有经验的老手,希望它能对你有所帮助. 在我们开始之前,有几个地方要注意一下: 我们使用的是 ES6 和 ES7 的语法. 如果你对于现实和容

JavaScript语法树与代码转化实践

JavaScript 语法树与代码转化实践 归纳于笔者的现代 JavaScript 开发:语法基础与实践技巧系列文章中.本文引用的参考资料声明于 JavaScript 学习与实践资料索引中,特别需要声明是部分代码片引用自 Babel Handbook 开源手册;也欢迎关注前端每周清单系列获得一手资讯. JavaScript 语法树与代码转化 浏览器的兼容性问题一直是前端项目开发中的难点之一,往往客户端浏览器的升级无法与语法特性的迭代保持一致;因此我们需要使用大量的垫片(Polyfill),以保证

SQLServer · 最佳实践 · 开发基于.NET CORE的LINUX版本的数据库应用

title: SQLServer · 最佳实践 · 开发基于.NET CORE的LINUX版本的数据库应用 author: 石沫 背景 最近有客户在基于.NET CORE的LINUX版本连接数据库的应用程序,在开发中,会遇到一些问题,客户会错误地将原因定位到我们的SQL SERVER,陆续收到一些工单,因此,我们需要有计划增强这个方面的能力,同事正确引导用户使用SQL SERVER. 部署环境 1. 服务器版本:ubuntu 14.04 2. .NET CORE 版本:1.0 3. 安装过程 3

基于Redis 千万级用户排行榜最佳实践

基于Redis 千万级用户排行榜最佳实践 前言 Redis 是一个开源的,内存中的数据结构存储系统,可以用作数据库.缓存和消息队列中间件.它支持多种类型的数据结构,如 字符串(string), Hash, 列表(List), 集合(Set), 有序集合(Sorted Set) . 内置了 复制(replication),LUA脚本(Lua scripting), LRU驱动事件(LRU eviction),事务(Transactions) 和不同级别的 磁盘持久化(Persistence), 并