alibaba fastjson(json序列化器)序列化部分源码解析-1-总体分析

    fastjson官方地址: http://code.alibabatech.com/wiki/display/FastJSON/Home
    从javaeye上看到了阿里一位人士写的fastjson,特别是其中如何将java对象序列化成json字符串这段。笔者比较关注,因为在笔者的项目中就用了一个json序列化器(造的轮子)。就下载下来看了一看,先不说和笔者所用的轮子有何区别,单就用了一个简单的测试器,来测试一下两者的处理速度。测试代码就不贴了,简单地说下测试结果。在jvm充分优化的情况下(for循环执行了很多次之后),笔者所使用的java序列化器处理速度不是很均匀,在结尾有短暂的变化(可能与虚拟机回收有关系);而fastjson在后面的处理过程当中,一般很均匀(后来发现与使用的buf分配方式有关)。最主要的区别莫在于,fastjson的速度那是不能对比了。
    经过分析源码之后,发现fastjson在处理json优化上面还是下了很大的工夫的。笔者准备从以下几个方面对fastjson作一个简单的解析,也让使用fastjson的同学对fastjson有一个简单的认识。
        1    总体分析    分析json序列化的总体思路和解析过程
        2    性能分析A  针对字符生产部分(即outWriter)对不同类型数据的处理和与性能相关处理部分
        3    性别分析B  针对序列化过程部分(即objectSerializer)对不同类型的序列化过程处理和与性能相关处理部分
        4    对象解析分析    对javaBean解析部分和针对字段输出部分的处理和解析
    源码分析基于1.0.5版本。

    总体分析,首先上图,即fastjson的总体处理思想,其实也是所有json序列化器需要考虑的问题。
    在这里,需要考虑的主要有两个部分,一是临时保存在序列化过程中用于储存数据的容器,二是处理对象序列化的序列化器。
    在fastjson中,保存数据的容器使用了wirter,字符输出流,而且是自实现的一个字符输出流。相对原来的writer,追加了很多需要输出的信息的实现,比如输出一个字符串,输出一个字符,输出一个long类型数据等。而处理对象序列化的序列化器,而使用了责任链模式和工厂模式,将不同类型的java对象分散到不同的序列化器当中。而每个序列化器只处理与自身类型相对应的数据信息,这样就避免了在处理时,各种情况交织在一块,逻辑混乱的问题。
    下面就源码本身作一个分析,其中结合两个部分进行分析。

继续阅读“alibaba fastjson(json序列化器)序列化部分源码解析-1-总体分析”

通过query解析hibernate中的resultTransformer

    任何包装jdbc的框架,都离不开将最终的数据封装成java对象的一个过程。在jdbc中,取得的数据被封装在resultset中,通过迭代resultset来一次次的取得相应的字段和数据值。数据库框架始终需要解决的问题在于将resultset中的字段名称信息和相应的字段值对应起来,然后封装成对象,最后将所有的对象形成一个集合,并最终返回给调用者。
    任何数据库框架都逃不过这中间的处理逻辑,只不过如何将这些逻辑分散在上下的处理中。在Hibernate中,同样也有类似的东西,这个接口就叫做ResultTransformer。

    Transformer的定义如下:

public interface ResultTransformer extends Serializable {

	public Object transformTuple(Object[] tuple, String[] aliases);

	public List transformList(List collection);
}

    其中第一个方法transformTuple,即是如何处理从数据库查询出来的字段值(可能经过了二次处理)和相对应的字段名称值,比如将字段值和字段名称组合成一个map。字段值,即在查询过程中查询的字段列表,而字段名称即是在查询时select的名称。
    第二个方法transformList,提供了对于从数据库返回结果,进行了封装之后,再对封装之后的数据列表进行最后一次处理。如进行去重等。

    为了说明ResultTransformer在Hibernate中的运用,我们从Hibernate中的查询入手,看ResultTransformer如何在其中运用的(以Hibernate3.6.3版本为例,在代码中不显示不必要的代码)。

继续阅读“通过query解析hibernate中的resultTransformer”

hibernate中的qbc(query by criteria)不支持having

    最近在做一次查询时,需要对查询的结果进行二次过滤,即分组之后再过滤,这种情况下,需要使用having。如以下的例子,我需要查询一个字段和另一个字段的和,并对记录进行分组,但结果集中并不需要总记录数为0的结果。sql语句如下所示:

select a, sum(b) as bsum from t where clause1=? group by a having and sum(b) > 0

    这种查询语句,使用hql能够很好地写出来,并且能够很好的运行。但如果条件数不定时,使用hql就需要动态的拼接hql,并且需要根据参数来设置参数。如下所示:

if(StringUtils.hasText("clause1"))
			hql += "clause1 = :clause1";
		//.....其它判断和处理
		if(StringUtils.hasText("clause1"))
			query.setString("clause1", clause1);

    在这种情况下,许多的if判断,无论是在编码还是在逻辑处理上都让人麻烦。对于不定的参数查询,qbc是最合适的(当然还有qbe)。但是对于qbc,处理having的这种情况即是不能处理的。
    不管使用任何处理情况,都不能从criteria中构建出这个having子句。

    经过google之后,网上有一个hibernate的bug报告HHH-1043,http://opensource.atlassian.com/projects/hibernate/browse/HHH-1043 。这个链接中,论述了在hibernate中的问题,并且提供一些解决方案,但这些解决方案都不能很容易的理解和解决问题。

    最根本的问题在于,qbc中的criteria,在hibernate内部设计和编码时,都是作为where条件中的一部分来实现的.主要的代码在类CriteriaQueryTranslator的方法getWhereCondition中,在这个方法中,迭代所有的criteria,并作为where条件使用。作为用在group集合中的having子句,并不属于where条件中任何一句。如果强行在criteria中使用having(比如使用Restrictions.sqlRestriction),最终的结果就是将having最终加到了where中条件的一部分。不过,这样生成的sql,即是错的,不会得到任何结果。

    直到最新的hibernate 3.6版本,此问题仍然未解决。对于需要处理聚集函数的条件问题,现阶段,除了hql(当然sql也算)。hibernate还没有其它的方法。先就这样吧。

解析struts2中的监测配置文件中的变化以方便开发时重新加载

    在进行开发时,经常需要修改配置文件,而修改配置文件之后,则必须要重新启动web容器,以重新启动相应的加载框架了。在项目部署时,一般不需要重新加载配置文件。而在开发时,则需要经常重新加载,因为配置文件经常需要被修改。如果重新容器的启动速度较慢,则大大地减慢了开发的速度。如果能够在修改了配置文件之后,即能够重新加载相应的对象,则相比重新启动容器要快一些了。

    在struts2中,就提供了一个在开发时,重新加载配置文件的设置。配置关键字为struts.configuration.xml.reload,当配置此值为true时,在每次请求相应的struts action时,则去判断struts2的文件是否有改变,当有改变发生时,就去重新加载相应的配置文件。这时就会将新修改的配置文件纳入到整个struts配置容器当中。

    在struts2中,负责重新加载配置文件的类由类ConfigurationManager的方法getConfiguration负责,此方法通过调用方法conditionalReload来实现重新加载配置文件,实现如下所示:

if (FileManager.isReloadingConfigs()) {
......
//判断是否需要重新加载
if(provider.needsReload()){
...
}
//准备重新加载所有的配置文件
if (reload) {
        ......
        packageProviders = configuration.reloadContainer(providers);
   }
}

    如上所示,所有的实现均由provider.needsReload()来确实,当发生有配置文件需要被重新加载时,就去重新加载所有配置文件。此方法一个实现为XmlConfigurationProvider,此实现如下所示:

public boolean needsReload() {

		for(String url : loadedFileUrls) {
			if(FileManager.fileNeedsReloading(url)) {
				return true;
			}
		}
		return false;
	}

    即最后,则最终取决于FileManager.fileNeedsReloading来确实,以下专门分析一下此文件如何来确定指定的url是否需要被改变。

继续阅读“解析struts2中的监测配置文件中的变化以方便开发时重新加载”

使用jsoup读取html文档结构并操纵数据结构(转)

    本文转自:http://www.ibm.com/developerworks/cn/java/j-lo-jsouphtml/index.html?ca=drs-
    jsoup 是一款 Java 的 HTML 解析器,可直接解析某个 URL 地址、HTML 文本内容。它提供了一套非常省力的 API,可通过 DOM,CSS 以及类似于 jQuery 的操作方法来取出和操作数据。本文主要介绍如何使用 jsoup 来进行常用的 HTML 解析。
    jsoup 的主要功能如下:
        1. 从一个 URL,文件或字符串中解析 HTML;
        2. 使用 DOM 或 CSS 选择器来查找、取出数据;
        3. 可操作 HTML 元素、属性、文本;
    jsoup 是基于 MIT 协议发布的,可放心使用于商业项目。

    文档输入
    jsoup 可以从包括字符串、URL 地址以及本地文件来加载 HTML 文档,并生成 Document 对象实例。下面是相关代码:

// 直接从字符串中输入 HTML 文档
 String html = "<html><head><title> 开源中国社区 </title></head>"
  + "<body><p> 这里是 jsoup 项目的相关文章 </p></body></html>"; 
 Document doc = Jsoup.parse(html); 

 // 从 URL 直接加载 HTML 文档
 Document doc = Jsoup.connect("http://www.oschina.net/").get(); 
 String title = doc.title(); 

 Document doc = Jsoup.connect("http://www.oschina.net/") 
  .data("query", "Java")   // 请求参数
  .userAgent("I ’ m jsoup") // 设置 User-Agent 
  .cookie("auth", "token") // 设置 cookie 
  .timeout(3000)           // 设置连接超时时间
  .post();                 // 使用 POST 方法访问 URL 

 // 从文件中加载 HTML 文档
 File input = new File("D:/test.html"); 
 Document doc = Jsoup.parse(input,"UTF-8","http://www.oschina.net/"); 

    请大家注意最后一种 HTML 文档输入方式中的 parse 的第三个参数,为什么需要在这里指定一个网址呢(虽然可以不指定,如第一种方法)?因为 HTML 文档中会有很多例如链接、图片以及所引用的外部脚本、css 文件等,而第三个名为 baseURL 的参数的意思就是当 HTML 文档使用相对路径方式引用外部文件时,jsoup 会自动为这些 URL 加上一个前缀,也就是这个 baseURL。
    例如 <a href=/project> 开源软件 </a> 会被转换成 <a href=http://www.oschina.net/project> 开源软件 </a>。

继续阅读“使用jsoup读取html文档结构并操纵数据结构(转)”

使用jsp extends而不是sitemesh分离jsp减少相同代码

    随着互联网应用的兴起,对基于布局技术的应用越来越多,许多情况下,都是采用copy+paste的开发模式来进行每一张jsp的开发。当然,再先进一点的,则是使用include的方式来包装每一张界面。
    对于每一张界面,都有相同的东西。比如,经常使用的header,footer,以及一个body界面最基本的布局元素。在开发前期,这些信息基本由web开发师来确定,然后每一张界面进行copy,并填充不同的东西,然后由程序开发人员来根据效果图或基本的html界面写动态数据,并最终形成产品项目。

    然而,这种解决方式还是不算简洁,对于已经存在的html。开发人员不再需要在界面上增加信息,而如果要新加一个功能,那么开发人员就需要首先从已经存在的界面上copy一份,然后修改其中需要变动的地方。
    到后来,如果出于某种变动(如设计上的调整),则需要在涉及到的相关界面都需要增加或修改一部分代码,这种情况下,以前copy+paste的代码就很麻烦了。开发人员必须找到每一张需要调整的界面,并在其中修改代码。
    我们说,重复的代码不写第二遍,那么在jsp上这么多的重复代码,应该怎么作呢。答案就是使用布局技术,首先有一个基本的布局界面,每张功能界面都引用这个布局界面,而只需要写当前功能界面所关注的功能,最后所生成的界面就是布局界面+功能界面的综合体了。
    使用过wordpress博客的人都了解,每个界面实际上都差不多,而负责前端所有展现的界面也就只有那么几个,这就是布局界面的应用。

    首先,作为开发人员,符合条件的布局技术必须满足两个条件,一个是掌握难度低,使用难度低,二是要简洁,不要大而全,解决最基本的功能即可。那么,就按照这两个需要来寻找吧。
    在google上搜索一番,涉及到最常用的布局技术有两个:sitemesh和struts tiles。其中,struts tiles从struts1时代起就存在了,就是为了解决界面布局的问题。然后由于它基于配置,且过于灵活,导致使用难度过大且不太不容易被掌握;所以逐渐转移到sitemesh上来。
    sitemesh当前最新的版本为2.4.2(官网上的版本为2.4.1)。网上有很多介绍它的应用,这里就不再介绍了,想使用的人可以google。它的主页为:http://www.opensymphony.com/sitemesh/。然而,最后的一次更新也在2009年3月,且最新的版本2.4.2也并没有在官网的下载中出现。寻找了半天,才发现sitemesh的代码库也不换地址了,最新的地址为https://github.com/sitemesh。而且,仔细看了下,好像基本处于停止的状态,且sitemesh也开始往sitemesh 3迁移了。代码基本上重新构建。对于使用和学习也不太方便。
    从笔者的角度上,主要关注于使用和技术应用,简单地查看了相应的源代码,实现功能确实过于复杂了一些,基本上是基于界面流过滤器的思想来进行文本的解析和替换。并且,相当的功能对于笔者所在的应用来说,基本上用不着。并且,还考虑到一个灵活应用的考虑,最主要的应用还是一个减少代码量,统一布局的目的。如果某一个功能jsp和模板界面相差太多,就直接使用原始的jsp,而不再使用sitemesh,在这一点上sitemesh就需要去修改配置文件,对于在开发上容易健忘的我们这一点实在要求太高。
    因此,最终笔者想要的就是一种可以类似界面替换的功能,以避免使用include指令时,大量的copy+paste操作。而不是想要增强jsp的应用。如果,某些界面又不使用这种功能时,又可以即时切换到原始的jsp上来。直接无迁移成本。而最后发现提供这种功能的东西就是:jsp extends。

继续阅读“使用jsp extends而不是sitemesh分离jsp减少相同代码”