基于ANTLR语法树编写解释引擎最佳实践
【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Tiny模板引擎的实现方式原来是采用的编译方式,最近发生了一些问题,因此我觉得有必要把编译方式调整为解释方式,为此就开始了此次实现活动。 编译方式存在的问题 当时采用编译方式,主要是考虑到编译方式在运行时不必再去遍历语法树,因此就采用了编译方式。但是在实际应用当中,出现了如下问题: 文件路径冲突的问题 由于采用的是编译方式,这个时候就存在在一个选择,即:Java源代码落地或不落地的选择。如果Java文件不落地,则在有问题的时候,如果想要进行代码调试(虽然这种场景并不多见),那么就没有源代码可供调试。如果Java代码落地,则会存在一个问题,那就是资源文件在磁盘文件中产生冲突的问题。 同样的问题对于class文件也存在,如果不落地,那么每次应用重启动的时候,都要重新编译这些文件以产生class文件;如果落地,则也会产生冲突的问题。 当然,Tiny模板引擎通过增加一个配置项,解决了这个冲突的问题,但是由于增加了一个配置项,从客观上增加了维护人员的工作量,也容易造成当维护人员不了解这里面的道道,忘记设置从而导致在一台服务器中部署多个Tiny应用时多个应用中的模板文件生成的java文件和class文件的冲突,从而导致出现问题。 PermSize内存占用问题 采用编译方式的时候,由于每个模板文件都要生成一个类