HTTL质量分析

阅读更多

抽空写了下对HTTL质量分析的过程，已经加到 http://httl.github.com第4章。

性能和设计，理论上也是质量的一部分，但之前已经分析过了，这里不再复述，
请参见： http://httl.github.com第2章和第3章。

先来看看静态代码的分析：

1. 单元测试

单元测试覆盖率: (分析工具EclEmma)



HTTL对所有语法，指令，函数，都有相应模板进行测试，参见：

https://github.com/httl/httl/tree/master/src/test/resources/comment/templates

2. FindBugs检测

已通过FindBugs最新版本(2.0.2)检测，零发现。参见FindBugs能发现的问题： http://findbugs.sourceforge.net/bugDescriptions.html

3. JDepend检测

已通过JDepend检测检测，无环依赖，稳定度与抽象度比正常，参见4.1.3分包设计章节。





我们再来看看运行时的稳定性分析：

4. 稳定性测试

在长时间重复运行所有单元测试后，CPU保持平稳：(分析工具JVisualVM)



内存也保持平稳，以YoungGC为主：



虽然HTTL大量使用字节码生成以提升性能，但因为有全量缓存，Perm区也是稳定的：



因设置的内存只有500M，而常规已占400多M，在OLD区几乎快满情况下，也只发生3次FullGC：(分析工具jstat)





从下面Dump后的数据可以看出，JDK编译占用了171M内存，如果开启-Xlint:unchecked编译参数会更大。
如果你觉得JdkCompiler内存占用过多，也可以通过配置换成Javassist编译。(分析工具jmap + MAT)





5. Profile分析

5.1 CPU分析

测试用例为长时间跑模板渲染过程，因解析后有缓存，所以CPU几乎全耗在渲染过程，
解析过程占比较小，符合预期：(分析工具JProfiler)



因同时测试了Writer和OutputStream两种场景，所以上图中各分一半。

展开其中一个渲染过程，各模板比较均匀，占比都不大，没有出现绝对热点，符合预期：



从上图可以看上，相对而言，xml.httl和include_withfilter.httl较慢，展开如下：



可以看出，主要消耗在xstream的parseXml解析和filter的escapseXml转义上。

XML的解析和处理本身就很耗时，在可接受范围内，并且不是核心组件。

长时间运行后，因样本少，xstream解析数据被缓存，所以时间都集中到了escapseXml的charAt上。



注意，上面的图中，浅红色表示当前方法消耗，深红色表示子函数消耗总和。

即然占比如此大，我们来看下代码：

首先String.charAt只是一个char[]下标取值，已经足够简单，不存在性能问题：

public char charAt(int index) {
    if ((index < 0) || (index >= count)) 
        throw new StringIndexOutOfBoundsException(index);
    return value[index + offset];
}

那再来看看HTTL的escapseXml：

public static String escapeXml(String value) {
    if (value == null || value.length() == 0) {
        return value;
    }
    int len = value.length();
    StringBuilder buf = null;
    for (int i = 0; i < len; i ++) {
        char ch = value.charAt(i);
        switch (ch) {
            case '&':
                if (buf == null) {
                    buf = new StringBuilder(len * 2);
                    if(i > 0) {
                        buf.append(value.substring(0, i));
                    }
                }
                buf.append("&");
                break;
            case '<':
            	if (buf == null) {
                    buf = new StringBuilder(len * 2);
                    if(i > 0) {
                        buf.append(value.substring(0, i));
                    }
                }
                buf.append("<");
                break;
            case '>':
            	if (buf == null) {
                    buf = new StringBuilder(len * 2);
                    if(i > 0) {
                        buf.append(value.substring(0, i));
                    }
                }
                buf.append(">");
                break;
            case '\"':
            	if (buf == null) {
                    buf = new StringBuilder(len * 2);
                    if(i > 0) {
                        buf.append(value.substring(0, i));
                    }
                }
                buf.append(""");
                break;
            case '\'':
            	if (buf == null) {
                    buf = new StringBuilder(len * 2);
                    if(i > 0) {
                        buf.append(value.substring(0, i));
                    }
                }
                buf.append("'");
                break;
            default:
            	if (buf != null) {
                    buf.append(ch);
                }
                break;
        }
    }
    if (buf != null) {
        return buf.toString();
    }
    return value;
}

从代码中可以看出escapseXml已经做了一些优化：

* 在没有发现特殊符前，不创建StringBuilder对象。
* 在发现第一个特殊符时，将将之前的内容，一次性拷到StringBuilder中。
* StringBuilder对象以两倍长度创建，防止扩容带来数据迁移。
* 通过switch每字符，以最短路径分发处理逻辑。

因escapseXml在没有发现特殊符时，只是通过charAt遍历字符串，不会做其它动作，所以长时间运行后，会显得charAt比较热，要过滤至少要遍历一遍，这已经是最低复杂度，所以并不是什么问题。

在压测Apache开源commons-lang中的StringEscapeUtils中的escapeXml后，发现性能甚至不如HTTL的实现。

那也看下commons-lang的StringEscapeUtils源代码：(注释中有说明它慢的原因)

public static String escapeXml(String str) {
    if (str == null) {
        return null;
    }
    return Entities.XML.escape(str);
}

public String escape(String str) {
	// 这里总是创建StringWriter，如果str没有特殊符，这样首先会浪费创建Writer对象的成本。
	// 其次浪费将一个个字符写到writer中，再toString回来的大量性能，而且没有特殊符是大概率事件。
	// HTTL在没有特殊符时是直接返回原始串的，不创建任何对象，不做任何来回拷贝。
	// 另外，StringWriter里面封装的StringBuffer，它的所有方法是带同步锁的，而HTTL采用无锁的StringBuilder。
    StringWriter stringWriter = createStringWriter(str);
    try {
        this.escape(stringWriter, str);
    } catch (IOException e) {
        throw new UnhandledException(e);
    }
    return stringWriter.toString();
}

public void escape(Writer writer, String str) throws IOException {
    int len = str.length();
    for (int i = 0; i < len; i++) {
        char c = str.charAt(i);
        // 这里使用map的hash查找实体的名称，比HTTL的switch慢。
        String entityName = this.entityName(c);
        if (entityName == null) {
            if (c > 0x7F) {
                writer.write("&#");
                writer.write(Integer.toString(c, 10));
                writer.write(';');
            } else {
                writer.write(c);
            }
        } else {
            writer.write('&');
            writer.write(entityName);
            writer.write(';');
        }
    }
}

当然，如果你有更好的实现，欢迎提供，非常感谢。

你可以通过配置切换实现：

value.filters=com.your.YourEscapeXmlFilter

5.2 内存分析

内存中以char[]和String最多，因为模板本身是大量文本处理，符合预期：(分析工具JProfiler)



过滤HTTL自身的类，因Context为会话域模型，每次执行都会创建Context，所以Context类最多，它比较轻量，符合预期：



长时间运行后，Context等实例数保持稳定，并没有爆炸式增长，表示可有效回收，符合预期：