groovy优化

groovy语言的动态性，决定了groovy非常适合用在业务逻辑变更非常频繁的场景中，例如规则系统，一些实时接口，因此往往都会去做一个groovy引擎来执行这些脚本，本文提供一些方法优化groovy引擎

1，groovy源码预编译并本地缓存class类

    很显然，这是常见的优化方法，你不可能每次都去读取文件，或者从数据库读取脚本字符串来直接执行吧，这样效率太低，每次都会编译，生成一个新的类加载到内存里执行，这不仅浪费时间，而且增加了gc压力。所以合适的做法就是系统初始化时读取所有的脚本文件，编译后将字节码缓存到本地内存中，你可以使用一个hashmap来做，也可以用其他集中式缓存系统来做；编译后会转换成Script对象的实例，执行groovy时需要做一个engine单例来执行，由于脚本都是缓存起来的字节码且是单例，执行起来不用担心内存泄露。

2，DefaultGroovyMethods调用优化

     众所周知，groovy中很多函数调用都是通过反射进行的，而在java语言中，通过反射调用方法，比直接调用方法慢上几倍。那么dmg调用优化的思想就是在groovy代码中通过直接调用来代替反射调用，而要实现直接调用，则需要为DGM中的每个方法生成一个从MetaMethod派生的包装类，该类的invoke方法将直接调用DGM中对应的方法。

 

  那为什么不为用户写的Groovy程序的每一个方法，在运行时动态的创建这样直接调用的包装类，来提高每个方法的调用效率呢？那是因为这样会产生大量的类，由于每个类都是需要占用内存的，所以会对JVM用于存放类信息的PermGen内存区域造成压力，容易产生OutOfMemoryError。而DGM方法是Groovy程序中大量被调用的方法(即热点)，而且数量只有不到1000个，因此适合为其生成包装类。 

3，自定义metaclasses优化

groovy的方法查找策略，默认先从this.getClass的metaClass里找，再从上下文里找。

当把一个java method放入groovy后，会自动被包装为org.codehaus.groovy.runtime.MethodClosure，如果本身就是java类，则无包装替换metaClass

    我们自定义一个MetaClassWrapper extends groovy.lang.MetaClassImpl，覆盖其public Object invokeMethod(Object object, String methodName, Object[] originalArguments)；方法。注意把script脚本类注入进来，拿到binding对象；本方法体内先查找binding内的方法如果有话直接反射调，否则调父类的this.invokeMethod(theClass, object, methodName, args, false, false);

写了一段java代码，纯函数调用和常见的字符串操作，没有任何对外调用，数据是

转载于:https://my.oschina.net/glarystar/blog/333292