guava是Java的一个扩展类库
guava是Java的一个扩展类库,在google的许多项目中使用过了,现在最为一个 开源的Java类库广泛使用(http://code.google.com/p/guava-libraries/)。
guava类库扩展的主要是这些相关类:collections(集合类),concurrency(并发),primitives,reflection(反射),comparison,I/O,hashing,networking(网络),strings(字符串),math(计算),in-memory caching(内存缓存),in-memory publish/subscirbe(内存发布订阅)等。
guava的目标是让我们写更少的代码,并且可以让我们写的代码更简单、清晰、可读性强。
下面我们对guava的使用方法和场景做一些介绍。
guava库需要在大于JDK1.6的版本下使用。
通常我们检查参数,是用如下方法
public void setRating(Double rating){ if(rating == null){ throw new NullPointerException(); } Double r = rating; }
如果你使用guava的类库,可以使代码更加简洁
public void setRating(Double rating){ Double r = checkNotNull(rating); }
不过,记得添加静态引用(import static com.google.common.base.Preconditions.checkNotNull;),在Eclipse中的设置,可以参考(eclipse中添加静态引用)
除了checkNotNull之外,Preconditions还提供了一些其他的方法,如chekArgument,checkState,checkElementIndex,checkPositionIndex等,更多可参考Preconditions API。
这个方法主要是用于更加简单的实现Object.toString()方法
public String toString() { return Objects.toStringHelper(this).add("name", name) .add("id", userId).add("pet",petName) //.omitNullValues().toString(); }
omitNullValues()当某个属性有空值的时候,不输出该熟悉。输出内容如下:
TestGuava{name=qiyadeng, id=12}
我们经常需要判断某一段语句执行需要多少时间,过去常用的做法是记录运行前的时间,然后用运行完成的时间减去运行前的时间,并且转换成我们可读的秒或是毫秒时间(这个转换过程可并不简单),在guava中的做法是:
Stopwatch stopwatch = new Stopwatch().start(); //do something test for (int i = 0; i < 10000; i++) { } long nanos = stopwatch.elapsed(TimeUnit.NANOSECONDS); System.out.println(nanos);
字符匹配的方法特别多,举一个例子过滤用户的输出
String userInput = "nihao1234-1"; CharMatcher ID_MATCHER = CharMatcher.DIGIT.or(CharMatcher.is(‘-‘)); System.out.println(ID_MATCHER.retainFrom(userInput));
可以把输入的的字符类型去掉,只输出1234-1。更多的使用方法可以参考CharMatcher。
可以快速地把一组字符数组连接成为用特殊符合连接的一个字符串,如果这组字符中有null值的话,我们可以使用skipNulls或是useForNull来控制我们要输出的内容。
//Joiner JOINER= Joiner.on(",").skipNulls(); Joiner JOINER= Joiner.on(",").useForNull("null"); String str = JOINER.join("hello","world",null,"qiyadeng"); //hello,world,null,qiyadeng
有这样一组字符串”hello,,qiyadeng,com,”我们用split(“,”)分割字符串,得到的结果是["hello","","qiyaeng","com"],但是我们如果希望的是把空值去掉,还需要另外处理,使用guava的Splitter可以简单做到。
Iterable<String> splitStr = Splitter.on(‘,‘).trimResults().omitEmptyStrings().split("hello,qiyadeng,com"); for (String string : splitStr) { System.out.println(string); }
今天来介绍一下“Protocol Buffers ”(以下简称protobuf)这个玩意儿。本来俺在构思“生产者/消费者模式 ”系列的下一个帖子:关于生产者和消费者之间的数据传输格式。由于里面扯到了protobuf,想想干脆单独开一个帖子算了。
★protobuf是啥玩意儿?
为了照顾从没听说过的同学,照例先来扫盲一把。
首先,protobuf是一个开源 项 目(官方站点在“这里 ”),而且是后台很硬的开源项目。网上现有的大部分(至少80%)开源项目,要么是某人单干、要么是几个闲杂人等合伙搞。而protobuf则不然,它是
鼎鼎大名的Google公司开发出来,并且在Google内部久经考验的一个东东。由此可见,它的作者绝非一般闲杂人等可比。
那这个听起来牛X的东东到底有啥用处捏?简单地说,这个东东干的事儿其实和XML 差不多,也就是把某种数据结构的信息,以某种格式保存起来。主要用于数据存储、传输协议格式等场合。有同学可能心理犯嘀咕了:放着好好的XML不用,干嘛重新发明轮子啊?!先别急,后面俺自然会有说道。
话说到了去年(大约是08年7月),Google突然大发慈悲,把这个好东西贡献给了开源社区。这下,像俺这种喜欢捡现成的家伙可就有福啦!貌似喜欢 捡现成的家伙还蛮多滴,再加上 Google的号召力,开源后不到一年,protobuf的人气就已经很旺了。所以俺为了与时俱进,就单独开个帖子来忽悠一把。
★protobuf有啥特色?
扫盲完了之后,就该聊一下技术 方面的话题了。由于这玩意儿发布的时间较短(未满周岁),所以俺接触的时间也不长。今天在此是先学现卖,列位看官多多包涵 :-)
◇性能好/效率高
现在,俺就来说说Google公司为啥放着好端端的XML不用,非要另起炉灶,重新造轮子。一个根本的原因是XML性能不够好。
先说时间开销:XML格式化(序列化)的开销倒还好;但是XML解析(反序列化)的开销就不敢恭维啦。俺之前经常碰到一些时间性能很敏感的场合,由于不堪忍受XML解析的速度,弃之如敝履。
再来看空间开销:熟悉XML语法的同学应该知道,XML格式为了有较好的可读性,引入了一些冗余的文本信息。所以空间开销也不是太好(不过这点缺点,俺不常碰到)。
由于Google公司赖以吹嘘的就是它的海量数据和海量处理能力。对于几十万、上百万机器的集群,动不动就是PB级的数据量,哪怕性能稍微提高 0.1% 也是相当可观滴。所以Google自然无法容忍XML在性能上的明显缺点。再加上Google从来就不缺造轮子的牛人,所以protobuf也就应运而生 了。
Google对于性能的偏执,那可是出了名的。所以,俺对于Google搞出来protobuf是非常滴放心,性能上不敢说是最好,但肯定不会太差。
◇代码 生成机制
除了性能好,代码生成机制是主要吸引俺的地方。为了说明这个代码生成机制,俺举个例子。
比如有个电子商务的系统(假设用C++实现),其中的模块A需要发送大量的订单信息给模块B,通讯的方式使用socket。
假设订单包括如下属性:
--------------------------------
时间:time(用整数表示)
客户id:userid(用整数表示)
交易金额:price(用浮点数表示)
交易的描述:desc(用字符串表示)
--------------------------------
如果使用protobuf实现,首先要写一个proto文件(不妨叫Order.proto),在该文件中添加一个名为"Order"的message结构,用来描述通讯协议中的结构化数据。该文件的内容大致如下:
--------------------------------
message Order
{
required int32 time = 1;
required int32 userid = 2;
required float price = 3;
optional string desc = 4;
}
--------------------------------
然后,使用protobuf内置的编译器编译 该proto。由于本例子的模块是C++,你可以通过protobuf编译器的命令行参数(看“这里 ”),让它生成C++语言的“订单包装类”。(一般来说,一个message结构会生成一个包装类)
然后你使用类似下面的代码来序列化/解析该订单包装类:
--------------------------------
// 发送方
Order order;
order.set_time(XXXX);
order.set_userid(123);
order.set_price(100.0f);
order.set_desc("a test order");
string sOrder;
order.SerailzeToString(&sOrder);
// 然后调用某种socket的通讯库把序列化之后的字符串发送出去
// ......
--------------------------------
// 接收方
string sOrder;
// 先通过网络通讯库接收到数据,存放到某字符串sOrder
// ......
Order order;
if(order.ParseFromString(sOrder)) // 解析该字符串
{
cout << "userid:" << order.userid() << endl
<< "desc:" << order.desc() << endl;
}
else
{
cerr << "parse error!" << endl;
}
--------------------------------
有了这种代码生成机制,开发人员再也不用吭哧吭哧地编写那些协议解析的代码了(干这种活是典型的吃力不讨好)。
万一将来需求发生变更,要求给订单再增加一个“状态”的属性,那只需要在Order.proto文件中增加一行代码。对于发送方(模块A),只要增加一行设置状态的代码;对于接收方(模块B)只要增加一行读取状态的代码。哇塞,简直太轻松了!
另外,如果通讯双方使用不同的编程语言来实现,使用这种机制可以有效确保两边的模块对于协议的处理是一致的。
顺便跑题一下。
从某种意义上讲,可以把proto文件看成是描述通讯协议的规格说明书(或者叫接口规范)。这种伎俩其实老早就有了,搞过微软的COM编程或者接触过CORBA的同学,应该都能从中看到IDL(详细解释看“这里 ”)的影子。它们的思想是相通滴。
◇支持“向后兼容”和“向前兼容”
还是拿刚才的例子来说事儿。为了叙述方便,俺把增加了“状态”属性的订单协议成为“新版本”;之前的叫“老版本”。
所谓的“向后兼容”(backward compatible),就是说,当模块B升级了之后,它能够正确识别模块A发出的老版本的协议。由于老版本没有“状态”这个属性,在扩充协议时,可以考 虑把“状态”属性设置成非必填 的,或者给“状态”属性设置一个缺省值(如何设置缺省值,参见“这里 ”)。
所谓的“向前兼容”(forward compatible),就是说,当模块A升级了之后,模块B能够正常识别模块A发出的新版本的协议。这时候,新增加的“状态”属性会被忽略。
“向后兼容”和“向前兼容”有啥用捏?俺举个例子:当你维护一个很庞大的分布式系统时,由于你无法同时 升级所有 模块,为了保证在升级过程中,整个系统能够尽可能不受影响,就需要尽量保证通讯协议的“向后兼容”或“向前兼容”。
◇支持多种编程语言
俺开博以来点评 的几个开源项目(比如“Sqlite ”、“cURL ”),都是支持很多种 编程语言滴,这次的protobuf也不例外。在Google官方发布的源代码中包含了C++、Java 、Python三种语言(正好也是俺最常用的三种,真爽)。如果你平时用的就是这三种语言之一,那就好办了。
假如你想把protobuf用于其它语言,咋办捏?由于Google一呼百应的号召力,开源社区对protobuf响应踊跃,近期冒出很多其它编程语言的版本(比如ActionScript、C#、Lisp、Erlang、Perl、PHP 、Ruby等),有些语言还同时搞出了多个开源的项目。具体细节可以参见“这里
”。
不过俺有义务提醒一下在座的各位同学。如果你考虑把protobuf用于上述这些语言,一定认真评估对应的开源库。因为这些开源库不是Google官方提供的、而且出来的时间还不长。所以,它们的质量、性能等方面可能还有欠缺。
★protobuf有啥缺陷?
前几天刚刚在“光环效应 ”的帖子里强调了“要同时评估优点和缺点”。所以俺最后再来批判一下这玩意儿的缺点。
◇应用 不够广
由于protobuf刚公布没多久,相比XML而言,protobuf还属于初出茅庐。因此,在知名度、应用广度等方面都远不如XML。由于这个原因,假如你设计的系统需要提供若干对外的接口给第三方系统调用,俺奉劝你暂时不要考虑protobuf格式。
◇二进制格式导致可读性差
为了提高性能,protobuf采用了二进制格式进行编码。这直接导致了可读性差的问题(严格地说,是没有可读性)。虽然protobuf提供了TextFormat这个工具类(文档在“这里 ”),但终究无法彻底解决此问题。
可读性差的危害,俺再来举个例子。比如通讯双方如果出现问题,极易导致扯皮(都不承认自己有问题,都说是对方的错)。俺对付扯皮的一个简单方法 就是直接抓包并dump成log,能比较容易地看出错误在哪一方。但是protobuf的二进制格式,导致你抓包并直接dump出来的log难以看懂。
◇缺乏自描述
一般来说,XML是自描述的,而protobuf格式则不是。给你一段二进制格式的协议内容,如果不配合相应的proto文件,那简直就像天书一般。
由于“缺乏自描述”,再加上“二进制格式导致可读性差”。所以在配置文件方面,protobuf是肯定无法取代XML的地位滴。
★为什么俺会用上protobuf?
俺自从前段时间接触了protobuf之后,就着手把俺负责的产品中的部分 数据传输协议替换成protobuf。可能有同学会问,和protobuf类似的东东也有不少,为啥独独相中protobuf捏?由于今天写的篇幅已经蛮 长了,俺卖个关子,把这个话题留到“生产者/消费者模式[5]:如何选择传输协议及格式?”。俺会在后续的这个帖子里对比各种五花八门的协议格式,并谈谈 俺的浅见。
Spring已经出来好多年了,当年是作为轻量级J2EE容器和EJB抗衡的,不过随着技术和时间的发展,Spring越来越全面,越来越强大,也就越来越Heavy了。而且,在使用Spring的过程中,因为所有Bean直接的关联都是在XML配置文件中完成的,于是当系统变大之后,XML配置中的内容会非常的多,感觉会很乱。
Google-Guice是最近几年刚刚出来的一种DI框架,它的好处就是简单,轻量级,快。Guice中的Bean之间的关联都是在Module中定义的,如果需要定义不同的关联,则需要定义不同的Module,这点相对来说会麻烦一些,但是这种使用Annotation和Module的方式,对于程序员来说,可能会感觉更为直接。另外,Guice启动的时候比Spring要快很多,据说要快100倍,这主要是因为Spring要去读配置文件,要Parse XML文件。但是个人感觉这种快,其实作用有限,因为这种速度的差异,只是在load
Bean的时候,当Bean都已经被load到内存之后,其实就没什么差别了,所以Guice快只是快在启动阶段。
关于在做项目时,到底选择Spring还是选择Guice呢? 个人感觉,如果你原来一直在使用Spring或者Guice,那么其实完全没有必要换,因为这样会带来额外的复杂度。原来熟悉那个用那个就OK了。 如果Spring和Guice都没用过,或者说都用过,那么我觉得就看项目需要了,如果项目需要的仅仅是个DI容器,那么我觉得Guice就足够了,好处就是简单,上手快,启动快;如果项目需要更多功能,要和其他的框架进行兼容,那么个人感觉选择Spring仍然是不错的选择,比较Spring出道时间长,和很多成熟框架之间都有很好的兼容,虽然Guice新的版本已经可以支持AOP功能,并且也可以支持和一些其他框架进行兼容,但是Guice想要在短时间内取代Spring,个人感觉还是非常难的。
最后,转一个看到的Spring和Guice的对比,转自:http://blog.csdn.net/lixuehui/article/details/1559926
Spring | Guice | |
使用XML | 使用将类与类之间的关系隔离到xml中,由容器负责注入被调用的对象,因此叫做依赖注入 | 不使用xml,将类与类之间的关系隔离到Module中,声名何处需要注入,由容器根据Module里的描述,注入被调用的对象。 |
使用Annotation | 使用 支持自定义Annotation标注,对于相同的接口定义的对象引用,为它们标注上不同的自定义Annotation注释,就可以达到同一个类里边的同一个接口的引用,注射给不同的实现,在Module里用标注做区分,灵活性大大增加。 使用Annotation也未必是好事,范型等新特性也未必是好事,目前大多的服务器均不支持jdk1.5,wls要9以前才支持,而目前的客户由于价格原因也很少选用wls9的,至少我们做过的项目中都没有。功能再强,客户不需要,何用? |
|
运行效率 | 装载spring配置文件时,需解析xml,效率低,getBean效率也不高,不过使用环境不会涉及到getBean,只有生产环境的时候会用到getBean,在装载spring应用程序的时候,已经完成全部的注射,所以这个低效率的问题不是问题。 | 使用Annotation,cglib, 效率高与spring最明显的一个区别,spring是在装载spring配置文件的时候把该注入的地方都注入完,而Guice呢,则是在使用的时候去注射,运行效率和灵活性高。 |
类耦合度 | 耦合度低,强调类非侵入,以外部化的方式处理依赖关系,类里边是很干净的,在配置文件里做文章,对类的依赖性极低。 | 高,代码级的标注,DI标记@inject侵入代码中,耦合到了类层面上来,何止侵入,简直侵略,代码耦合了过多guice的东西,大大背离了依赖注入的初衷,对于代码的可维护性,可读性均不利 |
类编写时 | 需要编写xml,配置Bean,配置注入 | 只需声明为@inject,等着被注入, 最后在统一的Module里声明注入方式 |
仅支持IOC | 否,spring目前已经涉猎很多部分 | 是,目前仅仅是个DI容器 |
是否易于代码重构 | 统一的xml配置入口,更改容易 | 配置工作是在Module里进行,和spring异曲同功 |
支持多种注入方式 | 构造器,setter方法 | Field,构造器,setter方法 |
灵活性 |
1,如果同一个接口定义的引用需要注入不同的实现,就要编写不同的Module,烦琐 2,动态注入 如果你想注射的一个实现,你还未知呢,怎么办呢,spring是没办法,事先在配置文件里写死的,而Guice就可以做到,就是说我想注射的这个对象我还不知道注射给谁呢,是在运行时才能得到的的这个接口的实现,所以这就大大提高了依赖注射的灵活性,动态注射。 |
|
与现有框架集成度 | 1, 高,众多现有优秀的框架(如struts1.x等)均提供了spring的集成入口,而且spring已经不仅仅是依赖注入,包括众多方面。 2, Spring也提供了对Hibernate等的集成,可大大简化开发难度。 3, 提供对于orm,rmi,webservice等等接口众多,体系庞大。 |
1,可以与现有框架集成,不过仅仅依靠一个效率稍高的DI,就想取代spring的地位,有点难度。 |
配置复杂度 | 在xml中定位类与类之间的关系,难度低 | 代码级定位类与类之间的关系,难度稍高 |
原文:http://blog.csdn.net/qq1175421841/article/details/51161239