一个单片磁盘的旋转速率为7200rpm,一面上的磁道数是30000,每道扇区数是600,寻道时间是每横越百磁道用1ms.假定开始时磁头位于磁道0,收到一个存取随机磁道上随机扇区的请求.
1,平均寻道时间为多少?
2,平均旋转延迟是多少？
3，一扇区的传送时间是多少？
4，满足此请求的总的平均时间是多少？

1、平均寻道时间应为全部寻道时间的一半，150ms
2、平均旋转延迟应为转一周时间的一半，约4.17ms
3、T=b/rN，其中b/N即1/600，T为0.0014ms
4、总的平均时间是前三者的算术和，154.1714ms

Nginx ("engine x") 是一个高性能的 HTTP 和 反向代理 服务器，也是一个 IMAP/POP3/SMTP 代理服务器 。 Nginx 是由 Igor Sysoev 为俄罗斯访问量第二的Rambler.ru 站点开发的，它已经在该站点运行超过四年多了。Igor 将源代码以类BSD许可证的形式发布。自Nginx 发布四年来，Nginx 已经因为它的稳定性、丰富的功能集、 示例配置文件和低系统资源的消耗而闻名了。目前国内各大门户网站已经部署了Nginx，如新浪、网易、腾讯等；国内几个重要的视频分享网站也部署了Nginx，如六房间、酷6等。 新近发现Nginx 技术在国内日趋火热，越来越多的网站开始部署Nginx。

因为 Nginx 的文档大部分是英文的，本维基的目的是帮助使用中文世界的用户安装、配置和交换有关 Nginx 的使用经验。大部分文档源自(al-nginx AT none.at,Aleksandar Lazic) 的工作，有关本维基本身的问题请直接询问Cliff Wells[1] ，其他翻译请点击 。

Nginx 发布

• 当前开发版: Nginx 1.3.1 | Nginx/windows 1.3.1 (更新记录) (2012年6月6日)
• 当前稳定版: Nginx 1.2.1 | Nginx/windows 1.2.1 (更新记录) (2012年6月6日)
• 历史稳定版: Nginx 1.0.15 | Nginx/windows 1.0.15 (更新记录) (2012年4月12日)
• 历史稳定版: Nginx 0.8.54 | Nginx/windows 0.8.55 (更新记录) (2011年7月19日)
• 历史稳定版: Nginx 0.7.69 | Nginx/windows 0.7.69 (更新记录) (2011年7月19日)

Nginx 新闻

• nginx成立公司继续发展,将保持开源/免费/BSD授权
• nginx-1.0.0稳定版发布 1.0.x现在为稳定版分支
• 2010年12月份调查 - 部署Nginx 的主机比例以达到6.62% (1691万)
• nginx-0.8.51稳定版发布 0.8.x现在为稳定版分支
• Evan Miller 的 Emiller的Nginx模块开发指南 草稿发布(2009年8月13日)，中文草稿(2009年9月21日)。
• TorrentReactor 使用 Nginx。
• 万一你没有立刻注意到，提醒下，维基使用了新主题。
• 因为最近的一些垃圾信息，现在必须注册一个帐户才能编辑该维基。不便之处，多多包涵。不过，这对于将这些垃圾信息抑制在萌芽状态的最好方法。
• 2009年7月份调查 - 全球范围内部署Nginx 的主机或虚拟主机比例以达到5.4%
• 2009年5月份调查 - 全球范围内部署Nginx 的主机或虚拟主机比例以达到3.25%
• 2009年3月份调查 - 全球范围内部署Nginx 的主机或虚拟主机比例以达到3.06%
• 2008年12月份调查 - 部署Nginx 的主机或虚拟主机总数已达350万，其增长率超过Lighttpd
• Netcraft 2008年8月份调查 - Nginx数量正在增加
• IRC Log

主要文档

• 概述
• 为什么选择 Nginx ？
• 安装 Nginx
• 运行和控制 Nginx - 命令行参数和信号
• 配置符号参考
• 优化 Nginx
• 常见问题（FAQ）
• 调试 nginx
• 特性请求

核心模块

• 主模块
• 事件模块
• HTTP 模块

基本模块

• HTTP Access 模块
• HTTP Auth Basic 模块
• HTTP AutoIndex 模块
• HTTP DAV 模块
• HTTP FastCGI 模块
• HTTP Gzip Compression 模块
• HTTP Headers 模块
• HTTP Index 模块
• HTTP Log 模块
• HTTP Proxy 模块
• HTTP Rewrite 模块
• HTTP Upstream 模块

其他模块

• HTTP Empty GIF 模块
• HTTP GEO 模块
• HTTP Real IP 模块
• HTTP SSI 模块
• HTTP Stub Status 模块
• HTTP Memcached 模块
• HTTP limit_zone 模块
• HTTP Secure Link 模块

第三方模块

• HTTP Upstream Request Hash 模块
• Notice 模块
• nginx_substitutions_filter 模块
• Http Access Key 模块
• ngx_cache_purge 模块
• NginxHttpOwnerMatch 模块（解决链接型文件跨站访问）

配置示例和方法

• 完整示例
• 完整示例（来自 Nginx 站点）
• 虚拟主机
• 负载均衡示例
• PHP/FastCGI 示例
• Ruby on Rails / Mongrel
• X-Sendfile (=> X-Accel-Redirect) in Nginx
• Disable the errorlog entries caused by the HW-Loadbalancer
• RHEL 5.4 + Nginx + Mediawiki With HTTPS
• LNMP 多用户虚拟主机方案
• LNMP 多用户动态进程管理虚拟主机方案
• 启用AWstats对Nginx作静态访问统计
• Nginx 二级子域名完美方案
• Nginx 日志分析AWStats+JAWStats安装配置
• Nginx常用Rewrite规则

社团

1. IRC: #nginx on irc.freenode.net (log archives )
2. Subscribe to the English Mailing List

外部资源

1. Nginx 官方首页(English)
2. Nginx中文网
3. Nginx中文文档
4. Nginx模块参考手册中文版
5. Nginx 各版本源代码和Win32 Binaries
6. Nginx 0.8.x + PHP 5.2.13（FastCGI）搭建胜过Apache十倍的Web服务器（第6版）
7. Evan Miller's Guide to Nginx Module Development
8. Nginx模块开发备忘
9. Nginx/windows 0.7.59 与PHP FastCGI 协同工作配置
10. Nginx source code cross-reference
11. Nginx (draft English docs by Aleksandar Lazic) is now integrated into this wiki ;-)
12. Cherokee vs Nginx benchmark
13. Nginx and TurboGears
14. Lots of Nginx examples
15. Nginx With PHP As FastCGI Howto (with fcgi-start script)
16. Nginx, PHP and a PHP FastCGI daemon init script (with init script for PHP FastCGI)
17. Nginx and Mongrel
18. Short Nginx examples
19. Init.d boot-up script for Linux
20. Nginx & Mongrel Cluster (with a possible start-stop script)
21. DokuWiki & nginx
22. Rails caching with Nginx's X-Accel-Redirect
23. Several Python::NginxChs blog entries
24. nginx.vim (config syntax highlighting for Vim)
25. Nginx, Fastcgi, PHP, rewrite config for Drupal
26. Rails hosting simplified (Using Nginx)
27. Django on Nginx
28. Pylons on Nginx
29. Godaddy Turbo SSL on Nginx
30. 关于Nginx的一些优化（突破10W并发）
31. Linux下Nginx+PHP+MySQL配置

支持 Nginx！

Nginx是一个开源的免费项目，需要大量的投资来支持我们的开发，比如购置服务器设备以支持Nginx官方网站、维基，或者是购买设备来测试开发。你可以通过捐赠的方式来帮助和支持本项目。我们衷心地希望使用Nginx而得益的企业或运营商、个人能拿出部分所得利来捐助Nginx，一方面为了Nginx更好，一方面也为了您能得到更完美的服务器程序。

PayPal: paypal@nginx.net

做个中文版下载源：

http://dl.iteye.com/topics/download/38db9a29-3e17-3dce-bc93-df9286081126

做个原版地址链接：

http://labs.google.com/papers/gfs.html

http://labs.google.com/papers/bigtable.html

http://labs.google.com/papers/mapreduce.html

/Files/kelly859/Google_三大论文中文版.pdf

永久链接 : http://www.ha97.com/4617.html

Tomcat从5.5版本开始，支持以下四种Connector的配置分别为：

<Connector port="8081" protocol="org.apache.coyote.http11.Http11NioProtocol"                           connectionTimeout="20000" redirectPort="8443"/>
<Connector port="8081" protocol="HTTP/1.1" connectionTimeout="20000"
               redirectPort="8443"/> 
<Connector executor="tomcatThreadPool"
               port="8081" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" />
<Connector executor="tomcatThreadPool"
               port="8081" protocol="org.apache.coyote.http11.Http11NioProtocol"
               connectionTimeout="20000"
               redirectPort="8443" />

我们姑且把上面四种Connector按照顺序命名为 NIO, HTTP, POOL, NIOP

为了不让其他因素影响测试结果，我们只对一个很简单的jsp页面进行测试，这个页面仅仅是输出一个Hello World。假设地址是 http://tomcat1/test.jsp

我们依次对四种Connector进行测试，测试的客户端在另外一台机器上用ab命令来完成，测试命令为： ab -c 900 -n 2000 http://tomcat1/test.jsp ，最终的测试结果如下表所示(单位:平均每秒处理的请求数)：

由这五组数据不难看出，HTTP的性能是很稳定，但是也是最差的，而这种方式就是Tomcat的默认配置。NIO方式波动很大，但没有低于280 的，NIOP是在NIO的基础上加入线程池，可能是程序处理更复杂了，因此性能不见得比NIO强；而POOL方式则波动很大，测试期间和HTTP方式一 样，不时有停滞。

由于linux的内核默认限制了最大打开文件数目是1024，因此此次并发数控制在900。

尽管这一个结果在实际的网站中因为各方面因素导致，可能差别没这么大，例如受限于数据库的性能等等的问题。但对我们在部署网站应用时还是具有参考价值的。

来自:http://www.javayou.com/diary/143691518

l Tomcat默认的配置： 

l 参数说明

l Pattern属性说明

%a - 远端IP地址

%A - 本地IP地址

%b - 发送的字节数，不包括HTTP头，如果为0，使用"－"

%B - 发送的字节数，不包括HTTP头

%h - 远端主机名(如果resolveHost=false，远端的IP地址）

%H - 请求协议

%l - 从identd返回的远端逻辑用户名（总是返回 '-'）

%m - 请求的方法（GET，POST，等）

%p - 收到请求的本地端口号

%q - 查询字符串(如果存在，以 '?'开始)

%r - 请求的第一行，包含了请求的方法和URI

%s - 响应的状态码

%S - 用户的session ID

%t - 日志和时间，使用通常的Log格式

%u - 认证以后的远端用户（如果存在的话，否则为'-'）

%U - 请求的URI路径

%v - 本地服务器的名称

%D - 处理请求的时间，以毫秒为单位

%T - 处理请求的时间，以秒为单位

另外还可以将cookie, 客户端请求中带的HTTP头(incoming header), 会话(session)或是ServletRequest中的数据都写到Tomcat的访问日志中，你可以用下面的语法来引用。 
%{xxx}i – 记录客户端请求中带的HTTP头xxx(incoming headers) 
%{xxx}c – 记录特定的cookie xxx 
%{xxx}r – 记录ServletRequest中的xxx属性(attribute) 
%{xxx}s – 记录HttpSession中的xxx属性(attribute)  

l Pattern配置示例

%t %h %l %s %D %r %b %{User-Agent}i

原文： http://blog.csdn.net/scorpio3k/article/details/7610973 

对于ibaits参数引用可以使用#和$两种写法，其中#写法会采用预编译方式，将转义交给了数据库，不会出现注入问题；如果采用$写法，则相当于拼接字符串，会出现注入问题。

例如，如果属性值为“' or '1'='1 ”，采用#写法没有问题，采用$写法就会有问题。

对于like语句，难免要使用$写法，

 1. 对于Oracle可以通过'%'||'#param#'||'%'避免；

 2. 对于MySQL可以通过CONCAT('%',#param#,'%')避免；

 3. MSSQL中通过'%'+#param#+'% 。 

如下3种SQL语句：

[html] view plaincopy

1 mysql: select * from t_user where name like concat('%',#name #,'%')    

2    

3 oracle: select * from t_user where name like '%'||#name #||'%'   

4    

5 SQL Server:select * from t_user where name like '%'+#name #+'%     

private static final SerializerFactory _serializerFactory = new SerializerFactory();
ByteArrayOutputStream bout = new ByteArrayOutputStream();
Hessian2Output h2out = new Hessian2Output(bout);
h2out.setSerializerFactory(_serializerFactory);
h2out.writeObject(msg);
h2out.flush();
byte[] content = bout.toByteArray();

新版本代码：

UnsafeByteArrayOutputStream bos = new UnsafeByteArrayOutputStream(1024);
Hessian2Output h2o = new Hessian2Output(bos);
h2o.writeObject(connReq);
h2o.flush();
byte[] content = bos.toByteArray();

新代码没有调用h2o.setSerializerFactory(serializerFactory);
就因为这一句，性能下降10倍。
我们来看一下Hessian3.2.1的源代码：

public void writeObject(Object object)
throws IOException
{
if (object == null) {
writeNull();
return;
}

Serializer serializer;

serializer = findSerializerFactory().getSerializer(object.getClass());

serializer.writeObject(object, this);
}

public final SerializerFactory findSerializerFactory()
{
SerializerFactory factory = _serializerFactory;

if (factory == null)
_serializerFactory = factory = new SerializerFactory();

return factory;
}

看代码，在writeObject()时，如果发现没有设置SerializerFactory，会自动设一个SerializerFactory，
看起来好像没有问题，我们自己设的SerializerFactory也是直接new出来的，没做什么手脚，
那为什么性能会下降这么快呢？开始还真被这行代码唬住了，看起来没啥区别，
仔细一想，才发现，Hessian2Output对象是prototype的，
每次请求，都会创建一个实例，用完即销毁，这样的话，基于下面的方式：

if (factory == null)
_serializerFactory = factory = new SerializerFactory();

每一个Hessian2Output内部都会重新new SerializerFactory();
应改为：

private static final SerializerFactory DEFAULT_SERIALIZER_FACTORY =new SerializerFactory();
if (factory == null)
_serializerFactory = factory = DEFAULT_SERIALIZER_FACTORY;

从这里可以看出是创建SerializerFactory的开销非常大，导致性能下降严重，
这个应该算是Hessian的BUG，这种线程安全的工厂类，就不应该在设默认值时，每次都new一个。
大家用Hessian的时候请小心这个问题。
后续还发现，不设置SerializerFactory，会出现大量线程被阻塞：
(下图为VisualVM截图，红色标识的片断为Blocked状态)

注意:每个层次的知识都是渐增的，位于层次n，也蕴涵了你需了解所有低于层次n的知识。

计算机科学 Computer Science

软件工程 Software Engineering

程序设计 Programming

经验 Experience

学识 Knowledge

原文出处：

http://www.indiangeek.net/wp-content/uploads/Programmer%20competency%20matrix.htm

译文出处：

http://static.icybear.net/%5BCN%5DProgrammer%20competency%20matrix.htm

转载自：http://www.iteye.com/topic/572581

加密算法有很多种：这里只大约列举几例：

1:消息摘要：（数字指纹）：既对一个任意长度的一个数据块进行计算，产生一个唯一指纹。MD5/SHA1
发送给其他人你的信息和摘要,其他人用相同的加密方法得到摘要，最后进行比较摘要是否相同。

2:单匙密码体制:DES:比较简便高效,密钥简短，加解密速度快，破译极其困难,但其安全性依赖于密匙的安全性。
DES（Data Encryption Standard）是发明最早的最广泛使用的分组对称加密算法。DES算法的入口参数有三个：Key、Data、Mode。其中Key为8个字节共64位，是DES算法的工作密钥；Data也为8个字节64位，是要被加密或被解密的数据；Mode为DES的工作方式，有两种：加密或解密

3:数字签名:就是信息发送者用其私钥对从所传报文中提取出的特征数据（或称数字指纹）进行RSA算法操作，以保证发信人无法抵赖曾发过该信息（即不可抵赖性），同时也确保信息报文在经签名后末被篡改（即完整性）。当信息接收者收到报文后，就可以用发送者的公钥对数字签名进行验证。
代表：DSA

4:非对称密匙密码体制（公匙体系）：加密密匙不同于解密密匙，加密密匙公之于众，谁都可以使用，解密密匙只有解密人自己知道。代表：RSA

下面是对上面几个例子进行的简单实现：

布尔操作符

大多数的搜索引擎都会提供布尔操作符让用户可以组合查询，典型的布尔操作符有 AND, OR, NOT。Lucene 支持 5 种布尔操作符，分别是 AND, OR, NOT, 加(+), 减(-)。接下来我会讲述每个操作符的用法。

• OR: 如果你要搜索含有字符 A 或者 B 的文档，那么就需要使用 OR 操作符。需要记住的是，如果你只是简单的用空格将两个关键词分割开，其实在搜索的时候搜索引擎会自动在两个关键词之间加上 OR 操作符。例如，“Java OR Lucene” 和 “Java Lucene” 都是搜索含有 Java 或者含有 Lucene 的文档。
• AND: 如果你需要搜索包含一个以上关键词的文档，那么就需要使用 AND 操作符。例如，“Java AND Lucene” 返回所有既包含 Java 又包含 Lucene 的文档。
• NOT: Not 操作符使得包含紧跟在 NOT 后面的关键词的文档不会被返回。例如，如果你想搜索所有含有 Java 但不含有 Lucene 的文档，你可以使用查询语句 “Java NOT Lucene”。但是你不能只对一个搜索词使用这个操作符，比如，查询语句 “NOT Java” 不会返回任何结果。
• 加号（+）: 这个操作符的作用和 AND 差不多，但它只对紧跟着它的一个搜索词起作用。例如，如果你想搜索一定包含 Java，但不一定包含 Lucene 的文档，就可以使用查询语句“+Java Lucene”。
• 减号（-）: 这个操作符的功能和 NOT 一样，查询语句 “Java -Lucene” 返回所有包含 Java 但不包含 Lucene 的文档。

域搜索(Field Search)

Lucene 支持域搜索，你可以指定一次查询是在哪些域(Field)上进行。例如，如果索引的文档包含两个域，Title 和 Content，你就可以使用查询 “Title: Lucene AND Content: Java” 来返回所有在 Title 域上包含 Lucene 并且在 Content 域上包含 Java 的文档。

通配符搜索(Wildcard Search)

Lucene 支持两种通配符：问号（？）和星号（*）。你可以使用问号（？）来进行单字符的通配符查询，或者利用星号（*）进行多字符的通配符查询。例如，如果你想搜索 tiny 或者 tony，你就可以使用查询语句 “t?ny”；如果你想查询 Teach, Teacher 和 Teaching，你就可以使用查询语句 “Teach*”。

模糊查询

Lucene 提供的模糊查询基于编辑距离算法(Edit distance algorithm)。你可以在搜索词的尾部加上字符 ~ 来进行模糊查询。例如，查询语句 “think~” 返回所有包含和 think 类似的关键词的文档。

范围搜索(Range Search)

范围搜索匹配某个域上的值在一定范围的文档。例如，查询 “age:[18 TO 35]” 返回所有 age 域上的值在 18 到 35 之间的文档。

　　在Servlet应用中，有一个getRealPath(String str)的方法，这个方法尽管也可以动态地获得文件的路径，不秘直接手写绝对路径，但这也是一个不被建议使用的方法，那么，我们有什么方法可以更好地获得文件呢?

      那就是Class.getResource()与Class.getResourceAsStream()方法，但很多人还是不太懂它的用法，因为很多人（比如不久前的我）都不知道应该传怎么样的参数给它，当然，有些人己经用得如火纯青，这些人是不需要照顾的，在此仅给不会或者还不是很熟的人解释一点点。

比如我们有以下目录

|--project

    |--src

        |--javaapplication

            |--Test.java

            |--file1.txt

        |--file2.txt

    |--build 

        |--javaapplication

            |--Test.class

            |--file3.txt

        |--file4.txt

在上面的目录中，有一个src目录，这是JAVA源文件的目录，有一个build目录，这是JAVA编译后文件(.class文件等）的存放目录

那么，我们在Test类中应该如何分别获得

file1.txt  file2.txt  file3.txt  file4.txt这四个文件呢？

首先讲file3.txt与file4.txt

file3.txt:

方法一：File file3 = new File(Test.class.getResource("file3.txt").getFile());

方法二：File file3 = new File(Test.class.getResource("/javaapplication/file3.txt").getFile());

方法三：File file3 = new File(Test.class.getClassLoader().getResource("javaapplication/file3.txt").getFile());

file4.txt:

方法一：File file4 = new File(Test.class.getResource("/file4.txt").getFile());

方法二：File file4 = new File(Test.class.getClassLoader().getResource("file4.txt").getFile());

很好，我们可以有多种方法选择，但是file1与file2文件呢？如何获得？

答案是，你只能写上它们的绝对路径，不能像file3与file4一样用class.getResource()这种方法获得，它们的获取方法如下

假如整个project目录放在c:/下，那么file1与file2的获取方法分别为

file1.txt

方法一：File file1 = new File("c:/project/src/javaapplication/file1.txt");

方法二：。。。没有

file2.txt

方法一：File file2 = new File("c:/project/src/file2.txt");

方法二：。。。也没有

总结一下，就是你想获得文件，你得从最终生成的.class文件为着手点，不要以.java文件的路径为出发点，因为真正使用的就是.class，不会拿个.java文件就使用，因为java是编译型语言嘛

至于getResouce()方法的参数，你以class为出发点，再结合相对路径的概念，就可以准确地定位资源文件了，至于它的根目录嘛，你用不同的IDE build出来是不同的位置下的，不过都是以顶层package作为根目录，比如在Web应用中，有一个WEB-INF的目录，WEB-INF目录里面除了web.xml文件外，还有一个classes目录，没错了，它就是你这个WEB应用的package的顶层目录，也是所有.class的根目录“/”，假如clasaes目录下面有一个file.txt文件，它的相对路径就是"/file.txt"，如果相对路径不是以"/"开头，那么它就是相对于.class的路径。。

还有一个getResourceAsStream()方法，参数是与getResouce()方法是一样的，它相当于你用getResource()取得File文件后，再new InputStream(file)一样的结果

CAP定理指出，一个数据库不可能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition-Tolerance）。

一致性（Consistency）是指执行了一次成功的写操作之后，未来的读操作一定可以读到这个写入的值。可用性（Availability）是指系统总是可读可写的。Yammer的Coda Hale和Cloudera的Henry Robinson都阐述过，分区容错性是不能牺牲的，因此只能在一致性和可用性上做取舍，如何处理这种取舍正是目前NoSQL数据库的核心焦点。

选择一致性而不是可用性的系统将面临一些尴尬的问题，当系统不可用时怎么办？你可以对写操作进行缓冲处理，但如果存储缓冲数据的机器出现故障，客户端将丢失写入的值。同样地，缓冲写也可以被认为是一种非一致性的操作，因为客户端认为成功的写入实际上并没有写入到实际的数据库中。当然，系统可以在机器不可用时向客户端返回错误，但可以想象，一个经常告诉客户端“请重试”的产品是多么令人讨厌。

另一个方案是选择可用性放弃一致性。这种情况下最好的一致性保障是“最终一致性”（Eventually Consistency）。当使用最终一致性的系统时，客户端有时会读到与刚刚写入数据不同的数据。有时候，同一时间同一个key的多个请求有可能返回不同的结果。数据更新并不能及时在所有的复制节点上生效，所以不同的复制节点上可能读取到的是不同的值。当你检测到数据不一致性时，你需要进行修复（Repair）操作，这就需要使用矢量时钟（vector clock）记录数据的版本历史并合并不同的数据更新（这称为读取修复，read repair）。

我相信在应用层维护最终一致性对开发人员负担太重，开发人员极易弄错读取修复的代码，而一旦开发人员犯错，有问题的读取修复将对数据库系统造成不可逆的损坏。

所以牺牲可用性时问题会很多，牺牲一致性时构建和维护系统的复杂度又很高，但这里又只有两个选择，不管怎样做都会不完美。CAP定理是改不了的，那么还有什么其他可能的选择吗？

实际上，还有一个办法：你并不能避开CAP定理，但可以把复杂的问题独立出来，免得你丧失对整个系统的掌控能力。CAP定理带来的复杂性，其实是我们如何构建数据系统这一根本问题的体现。其中有两点特别重要：数据库中可变状态和更新状态的增量算法。复杂性正是这两点和CAP定理之间的相互作用导致的。

本文将通过一个数据库系统的设计，来说明如何解决CAP定理通常会造成的复杂性问题。但我要做的不仅仅如此，CAP定理是一个针对机器发生错误时系统容错性的一个定理，而这里有比机器容错性更加重要的容错性——人为操作容错性。在软件开发中一个确定的事实是，开发人员都并非完人，产品中难免有一些Bug，我们的系统必须对有Bug的程序写入的错误数据有足够的适应能力，我要展示的系统将是这样一个可以容忍人为错误的系统。

本文将挑战你对数据系统如何构建这一问题的假设，通过颠覆传统数据系统构建方法，我会让大家看到一个前所未见的优雅、扩展性强、健壮的数据系统。

什么是数据系统？

在开始介绍系统设计之前，让我们先来看看我们要解决的问题：数据系统的目的在于什么？ 什么是数据？ 在我们考虑CAP定理之前，我们必须给出一个可以适用于所有数据应用程序的定义来回答上述问题。

数据应用程序种类很多，包括存入和提取数据对象、连接、聚合、流处理、机器学习等。似乎并不存在一个对数据系统的明确定义，数据处理的多样性使得我们很难用一个定义来描述。

事实却并非如此，下面这个简单的定义：

Query = Function(All Data)

概括了数据库和数据系统的所有领域。每一个领域——有50年历史的RDBMS、索引、OLAP、OLTP、MapReduce、EFL、分布式文件系统、流处理器、NoSQL等——都可以被概括进这个方程。

所谓数据系统就是要回答数据集问题的系统，这些问题我们称之为“查询”。上面的方程表明，查询就是数据上的一个函数。

上述方程对于实际使用来说太过于笼统，几乎对复杂的数据系统设计不起什么作用。但如果所有的数据系统都遵循这个方程又会怎样呢？这个方程是探索我们数据系统的第一步，而它最终将引导我们找到“打败”CAP定理的方法。

这个方程里面有两个关键概念：数据、查询。这两个完全不同的概念经常被混为一谈，所以下面来看看这两个概念究竟是什么意思。

数据

我们先从“数据”开始。所谓数据就是一个不可分割的单位，它肯定存在，就跟数学里面的公理一样。

关于“数据”有两个关键的性质。首先，数据是跟时间相关的，一个真实的数据一定是在某个时间点存在于那儿。比如，假如Sally在她的社交网络个人资料中写她住在芝加哥，你拿到的这个数据肯定是她某个时间在芝加哥填写的。假如某天Sally把她资料里面居住地点更新为亚特兰大，那么她肯定在这个时候是住在亚特兰大的，但她住在亚特兰大的事实无法改变她曾经住在芝加哥这个事实——这两个数据都是真实的。

其次，数据无法改变。由于数据跟某个时间点相关，所以数据的真实性是无法改变的。没有人可以回到那个时间去改变数据的真实性，这说明了对数据操作只有两种：读取已存在的数据和添加更多的新数据。那么CRUD就变成了CR【译者注：CRUD是指Create Read Update Delete，即数据的创建、读取、更新和删除】。

我去掉了“更新”操作，因为更新对于不可改变的数据没有任何作用。例如，更新Sally的位置信息本质上就是在她住的地方数据中新加一条最近的位置信息而已。

我同样去掉了“删除”操作，因为绝大部分删除操作可以更好地表述为新加一条数据。比如Bob在Twitter上不再关注Mary了，这并不能改变他曾经关注过Mary这个事实。所以与其删除Bob关注Mary这个数据，还不如新加一条Bob在某个时间点不再关注Mary这个数据。

这里只有很少数的情况需要永久“删除”数据，例如规则要求你每隔一段时间清掉数据，这个情况在我将要展示的系统中有很好的解决方案，所以为了简洁，我们暂不考虑这些情况。

查询

查询是一个针对数据集的推导，就像是一个数学里面的定理。例如，你可以通过计算“Sally现在的位置在哪里”这个查询来得到Sally最新的位置数据。查询是整个数据集合上的函数，可以做一切事情：聚合、连接不同类型的数据等。因此，你可以查询系统中女性用户的数量，可以查询最近几小时热门的Twitter内容。

前面我已经定义查询是整个数据集上的函数，当然，不是所有的查询都需要整个数据集，它们只需要数据集的一个子集。但我的定义是涵盖了所有的查询类型，如果想要“打败”CAP定理，我们需要能够处理所有的查询。

打败CAP定理

计算查询最简单的办法就是按照查询语义在整个数据集上运行一个函数。如果这可以满足你对延迟的要求，那么就没有其他需要构建的了。

可想而知，我们不能指望在整个数据集上的查询能够很快完成，特别是那些服务大型网站、需要每秒处理几百万次请求的系统。但假如这种查询可以很快完成，让我们来看看像这样的系统和CAP定理的PK结果：你将会看到，这个系统不仅打败了CAP定理，而且还消灭了它。

CAP定理仍然适用，所以你需要在可用性和一致性上做出选择，这里的漂亮之处在于，一旦你权衡之后做出了选择，你就做完了所有的事情。通常的那些因为CAP定理带来的问题，都可以通过不可改变的数据和从原始数据中计算查询来规避。

如果你选择一致性而不是可用性，那么跟以前并没有多大的区别，因为你放弃了可用性，所以一些时候你将无法读取或者写入数据。当然这只是针对对强一致性有要求的系统。

如果你选择可用性而不是一致性，在这种情况下，系统可以达到最终一致性而且规避了所有最终一致性带来的复杂问题。由于系统总是可用的，所以你总可以写入新数据或者进行查询。在出错情况下，查询可能返回的不是最近写入的数据，但根据最终一致性，这个数据最终会一致，而查询函数最终会把这个数据计算进去。

这里的关键在于数据是不可变的。不可变数据意味着这里没有更新操作，所以不可能出现数据复制不同这种不一致的情况，也意味着不需要版本化的数据、矢量时钟或者读取修复。在一个查询场景中，一个数据只有存在或者不存在两种情况。这里只有数据和在数据之上的函数。这里没有需要你为确保最终一致性额外做的事情，最终一致性也不会因此使你的系统变得复杂。

之前的复杂度主要来自增量更新操作和CAP定理之间的矛盾，在最终一致性系统中可变的值需要通过读取修复来保证最终一致性。通过使用不可变数据，去掉增量更新，使用不可变数据，每次从原始数据计算查询，你可以规避那些复杂的问题。CAP定理就被打败了。

当然，现在讲的只不过是想法而已，而且每次从原始数据计算查询基本上不可能。但我们从中可以学到一些在实际解决方案中的关键点。

• 数据系统因为不可变数据和不断增长的数据集变得简单了。
• 基本的写入操作就是写入一条新的不可变数据。
• 数据系统通过重新从原始数据计算查询规避了CAP定理带来的复杂度。
• 数据系统利用增量算法使得查询的返回延迟降低到一个可以接受的程度。

让我们开始探索这个数据系统应该如何设计。请注意从这里开始我们所描述都是针对系统优化、数据库、索引、EFL、批量计算、流处理——这些技术都是对查询函数的优化，让查询返回时间降低到一个可以接受的程度。这很简单，但也是数据系统所面对的现实。数据库通常是数据管理的核心，但它们是更大蓝图中的一部分。

批量计算

“如何让任意一个函数可以在任意一个数据集上快速执行完成”这个问题太过于复杂，所以我们先放宽了一下这个问题依赖条件。首先假设，可以允许数据滞后几小时。放宽这个条件之后，我们可以得到一个简单、优雅、通用的数据系统构建解决方案。之后，我们会通过扩展这个解决方案使得它可以不用放宽条件来解决问题。

由于查询是所有数据的一个函数，让查询变快的最简单的方法就是预先计算好这些查询。只要这里有新的数据，你就重新计算这些查询。这是可能的，因为我们放宽了条件使得我们的数据可以滞后几个小时。图1展示了这个工作流程。

图1 预计算工作流程

为了实现这个，你的系统需要：

• 能很容易存储大的、不断增长的数据集；
• 能在数据集上可扩展地计算查询函数。

这样的系统是存在的，即Hadoop。它是一个成熟的、经历了无数团队实战检验过的系统，同时拥有一个巨大的工具生态系统。它虽不完美，但是这里用来做批量处理的最好的一个工具。

许多人也许会告诉你，Hadoop只适用于那些“非结构化”的数据，这是完全错误的看法。Hadoop处理“结构化”的数据也很不错，通过使用像Thrift或者Protocol Buffers这样的工具，你可以使用丰富的数据结构存储你的数据。

Hadoop由分布式文件系统HDFS和批处理框架MapReduce两部分构成。HDFS可以通过文件存储大量数据，MapReduce可以在这样数据上进行可扩展计算。这个系统完全符合我们的要求。

我们将数据以文件形式存储到HDFS中去。文件可以包括一个数据记录序列。新增数据时，我们只需要在包括所有数据的文件夹中新增一个包含这条新记录的文件即可。像这样在HDFS存储数据满足了“能够很容易存储大的、不断增长的数据集”这个要求。

预计算数据集上的查询也很直观，MapReduce是一个足够复杂的框架，使得几乎所有的函数都可以按照多个MapReduce任务这种方式实现。像Cascalog、Cascading和Pig这样的工具使实现这些函数变得十分简单。

最后，为了可以快速访问这些预计算查询结果，你需要对查询结果进行索引，这里有许多数据库可以完成这个工作。ElephantDB和Voldemort read-only可以通过从Hadoop中导出key/value数据来加快查询速度。这些数据库支持批量写和随机读，同时不支持随机写。随机写使得数据库变得复杂，所以通过不支持随机写，这些数据库设计得特别简洁，也就几千行代码而已。简洁使得这些数据库鲁棒性变得非常好。

下面来看批量处理系统整体上是如何配合工作的。假设写一个网站分析程序来跟踪页面访问量，你需要能够查询到任意时间段的页面访问量，数据是以小时方式提供的。如图2所示。

图2 批处理工程流程示例(timestamp代表时间戳，count代表个数)

实现这个很简单，每一个数据记录包括一个单一页面的访问量。这些数据通过文件形式存储到HDFS中，一个函数通过实现MapReduce计算任务，来计算一个URL下页面每小时的访问量。这个函数产生的是key/value对，其中[URL, hour]是key，value是页面的访问量。这些key/value对被导出到ElephantDB中去，使得应用程序可以快速得到任意[URL, hour]对对应的值。如果应用程序想要知道某个时间范围内某个页面的访问量，它可以查询ElephantDB中那段时间内的数据，然后把这些数据相加就可以得到这个访问量数据了。

在数据滞后几小时这个缺陷下，批量处理可以计算任意数据集上的任意函数。系统中的“任意性”是指这个系统可以处理任何问题。更重要的是，它很简单，容易理解和完全可扩展，你需要考虑的只是数据和查询函数，Hadoop会帮你处理并行的事情。

批处理系统、CAP定理和容忍人为错误

截至目前，我们的系统都很不错，这个批处理系统是不是可以达到容忍人为错误的目标呢？

让我们从CAP定理开始。这个批处理系统总是最终一致的：写入的数据总可以在几小时后被查询到。这个系统是一个很容易掌控的最终一致性系统，使得你可以只用关注你的数据和针对数据的查询函数。这里没有涉及读取修复、并发和其他一些需要考虑的复杂问题。

接下来看看这个系统对人为错误的容忍性。在这个系统中人们可能会犯两个错误：部署了一个有Bug的查询函数或者写入了错误的数据。

如果部署了一个有Bug的查询函数，需要做的所有事情就是修正那个Bug，重新部署这个查询函数，然后在主数据集上重新计算它。这之所以能起作用是因为查询只是一个函数而已。

另外，错误的数据有明确的办法可以恢复：删除错误数据，然后重新计算查询。由于数据是不可变的，而且数据集只是往后添加新数据，写入错误的数据不会覆盖或者删除正确的数据，这与传统数据库更新一个数据就丢掉旧的数据形成了鲜明的对比。

注意到MVCC和HBase类似的行版本管理并不能达到上面人为错误容忍级别。MVCC和HBase行版本管理不能永久保存数据，一旦数据库合并了这些版本，旧的数据就会丢失。只有不可变数据系统能够保证你在写入错误数据时可以找到一个恢复数据的方法。

实时层

上面的批量处理系统几乎完全解决了在任意数据集上运行任意函数的实时性需求。任何超过几个小时的数据已经被计算进入了批处理视图中，所以剩下来要做的就是处理最近几个小时的数据。我们知道在最近几小时数据上进行查询比在整个数据集上查询要容易，这是关键点。

为了处理最近几个小时的数据，需要一个实时系统和批处理系统同时运行。这个实时系统在最近几个小时数据上预计算查询函数。要计算一个查询函数，需要查询批处理视图和实时视图，并把它们合并起来以得到最终的数据。

图3 计算一个查询

在实时层，可以使用Riak或者Cassandra这种读写数据库，而且实时层依赖那些数据库中对状态更新的增量算法。

让Hadoop模拟实时计算的工具是Storm。我写Storm的目的是让Hadoop可以健壮、可扩展地处理大量的实时数据。Storm在数据流上运行无限的计算，并且对这些数据处理提供了强有力的保障。

让我们回到刚才那个根据某个URL查询某个页面在某个时间段内页面访问量的例子，通过这个例子我将展示实时层是如何工作的。

批处理系统还是跟之前一样：一个基于Hadoop和ElephantDB的批处理工作流，在几个小时之前的数据上预计算查询函数。剩下就是让实时系统去处理最近几小时数据了。

我们将最近几小时的数据状态存入Cassandra中，用Storm去处理页面访问量数据流并并行更新到数据库中，针对每一个页面访问量，在[URL, hour]所代表的key下，有一个计数器，这个计数器在Cassandra中实现。这就是所有的事情，Storm让事情变得非常简单。

图4 批处理/实时架构示例

批处理层+实时层、CAP定理和人为错误容忍性

貌似又回到一开始提出的问题上去了，访问实时数据需要使用NoSQL数据库和增量算法。这就说明回到了版本化数据、矢量时钟和读取修复这些复杂问题中来。但这是有本质区别的。由于实时层只处理最近几小时的数据，所有实时层的计算都会被最终批处理层重新计算。所以如果犯了什么错误或者实时层出了问题，最终都会被批处理层更正过来，所有复杂的问题都是暂时的。

这并不意味着不需要关心实时层的读取修复和最终一致性，你仍然需要实时层尽可能的一致。但当犯了一个错误时，不会永久性地破坏数据。这便移除了许多你所需要面对的复杂问题。

在批处理层仅需要考虑数据和数据上的查询函数，批处理层因此很好掌控。在实时层，需要使用增量算法和复杂的NoSQL数据库。把所有的复杂问题独立到实时层中，对系统的鲁棒性、可靠性做出了重大贡献。

同样的，实时层并没有影响系统的人为错误容忍性，这个数据不可变和只追加的批处理系统，仍然是整个系统的核心，所以所有的都可以像上面说的一样被纠正过来。

我有一个类似的系统：Hadoop和ElephantDB组成批处理系统，Storm和Cassandra组成实时系统。由于缺乏监控，某天当我起床的时候发现Cassandra运行满负荷了，使得所有的数据请求都超时。这使得Storm计算失败，一些数据又重新回到了等待队列中，这个数据就一次次重复请求。

如果我没有批处理层，那么我就需要扩展和恢复Cassandra，这个很不容易。更糟的是，因为请求不断的重复，无法得到正确的数据。

幸运的是，所有的复杂问题都被隔离到实时层中去了，我清空了所有的后台请求队列，把它们打到了批处理层上，同时重启了Cassandra集群，过了几个小时之后所有数据都恢复正常了。没有错误数据，请求中也没有不准确的地方。

垃圾回收

上面描述的所有东西都是建立在一个不可变的、不断增长的数据集上的。如果数据集已经很大，使得不可能用水平扩展储存所有时间的所有数据，该如何处理呢？这是不是就推翻了我说的一切呢？是不是需要回到可变数据的系统上呢？

不。我们可以很容易地用“垃圾回收”对基本模型进行扩展来解决上面的问题。垃圾回收是一个在主数据集上的简单函数，返回的是一个过滤版本的主数据集。垃圾回收掉了旧数据，可以选择任意的垃圾回收策略。可以在易变的系统中只保留数据最新的一个值或者保留每个数据的历史。比如，如果要处理位置数据，可以保留每人每年的一个地点。可变性是一个不是很灵活的垃圾回收形式（它跟CAP定理交互得也很糟糕）。

垃圾回收可以被实现成批处理的一个任务，隔段时间运行一下。由于它是作为离线批处理任务执行的，所以不影响我们与CAP定理的交互。

总结

让可扩展的数据系统复杂的原因不是CAP系统，而是数据增量算法和数据的可变状态。最近由于分布式数据库的兴起导致了复杂度越来越不可控。前面讲过，我将挑战对传统数据系统构建方法的假设。我把CRUD变成了CR，把持久化层分成了批处理和实时两个层，并且得到对人为错误容忍的能力。我花费了多年来之不易的经验打破我对传统数据库的假设，并得到了这些结论。

批处理/实时架构有许多有趣的能力我并没有提到，下面我总结了一些。

算法的灵活性。随着数据量的增长，一些算法会越来越难计算。比如计算标识符的数量，当标识符集合越来越大时，将会越来越难计算。批处理/实时分离系统给了你在批处理系统上使用精确算法和在实时系统上使用近似算法的灵活性。批处理系统计算结果会最终覆盖实时系统的计算结果，所以最终近似值会被修正，而你的系统拥有了“最终精确性”。

数据结构迁移变得很容易。数据结构迁移的难题将一去不复返。由于批量计算是系统的核心，很容易在整个系统上运行一个函数，所以很容易更改你数据的结构或者视图。

简单的Ad-Hoc网络。由于批处理系统的任意性，使得你可以在数据上进行任意查询。由于所有的数据在一个点上都可以获取，所以Ad-Hoc网络变得简单而且方便。

自我检查。由于数据是不可变的，数据集就可以自我检查。数据集记录了它的数据历史，对于人为错误容忍性和数据分析很有用。

我并没有说我已经“解决”了数据量过大的问题，但我已经为解决大数据问题制订了一个框架。批处理/实时架构可以应用到任何一个数据系统中去，“授人以鱼，不如授人以渔”，我已经告诉你了如何去构建这样的系统。

为了提高系统整体能力来解决大数据的问题，我们还有许多工作需要做。

• 扩展数据模型，支持批量写和随机读。不是每一个应用程序都支持key/value的数据库，这也是我们团队对扩展ElephantDB，使得可以支持搜索、文档数据库、区间查询感兴趣的原因。
• 更好的批处理原语。Hadoop并不是批处理的最终形态，好多批处理计算Hadoop效率不高。Spark是一个有意思的扩展MapReduce的项目。
• 提升后的读写NoSQL数据库。这里不同类型数据的数据库还有很大的提升空间，随着这些数据库的成熟，它们将收获很多。
• 高层级的抽象。未来工作中最有意思的就是对批处理模块和实时处理模块的高层次抽象，在批处理和实时架构下你没有理由不拥有一个简单的、描述性的、鲁棒性好的语言。

许多人需要一个可扩展的关系型数据库，本文就是想让你知道完全不需要那个。大数据量和NoSQL运动使数据管理比RDBMS更加复杂。那仅仅是因为我对大数据的处理采用了跟RDBMS同样的方法：把数据和视图混为一谈，并且依赖增量算法。大数据量需要采用完全不同的方式构建数据系统。通过存储持续增长的不可变数据，并且系统核心采用预计算，大数据系统就可以变得比关系型数据库更易掌控，并且可扩展性很强。

Lucene是一个高性能的java全文检索工具包，它使用的是倒排文件索引结构。该结构及相应的生成算法如下：
　　
　　0）设有两篇文章1和2
　　文章1的内容为：Tom lives in Guangzhou,I live in Guangzhou too.
　　文章2的内容为：He once lived in Shanghai.
　　
　　1)由于lucene是基于关键词索引和查询的，首先我们要取得这两篇文章的关键词，通常我们需要如下处理措施
　　a.我们现在有的是文章内容，即一个字符串，我们先要找出字符串中的所有单词，即分词。英文单词由于用空格分隔，比较好处理。中文单词间是连在一起的需要特殊的分词处理。
　　b.文章中的”in”, “once” “too”等词没有什么实际意义，中文中的“的”“是”等字通常也无具体含义，这些不代表概念的词可以过滤掉
　　c.用户通常希望查“He”时能把含“he”，“HE”的文章也找出来，所以所有单词需要统一大小写。
　　d.用户通常希望查“live”时能把含“lives”，“lived”的文章也找出来，所以需要把“lives”，“lived”还原成“live”
　　e.文章中的标点符号通常不表示某种概念，也可以过滤掉
　　在lucene中以上措施由Analyzer类完成
　　
　　经过上面处理后
　　 文章1的所有关键词为：[tom] [live] [guangzhou] [i] [live] [guangzhou]
　　 文章2的所有关键词为：[he] [live] [shanghai]
　　
　　2) 有了关键词后，我们就可以建立倒排索引了。上面的对应关系是：“文章号”对“文章中所有关键词”。倒排索引把这个关系倒过来，变成：“关键词”对“拥有该关键词的所有文章号”。文章1，2经过倒排后变成
　　关键词 文章号
　　guangzhou 1
　　he 2
　　i 1
　　live 1,2
　　shanghai 2
　　tom 1
　　
　　通常仅知道关键词在哪些文章中出现还不够，我们还需要知道关键词在文章中出现次数和出现的位置，通常有两种位置：a)字符位置，即记录该词是文章中第几个字符（优点是关键词亮显时定位快）；b)关键词位置，即记录该词是文章中第几个关键词（优点是节约索引空间、词组（phase）查询快），lucene 中记录的就是这种位置。
　　
　　加上“出现频率”和“出现位置”信息后，我们的索引结构变为：
　　关键词 文章号[出现频率] 出现位置
　　guangzhou 1[2] 3，6
　　he 2[1] 1
　　i 1[1] 4
　　live 1[2],2[1] 2，5，2
　　shanghai 2[1] 3
　　tom 1[1] 1
　　
　　以live 这行为例我们说明一下该结构：live在文章1中出现了2次，文章2中出现了一次，它的出现位置为“2,5,2”这表示什么呢？我们需要结合文章号和出现频率来分析，文章1中出现了2次，那么“2,5”就表示live在文章1中出现的两个位置，文章2中出现了一次，剩下的“2”就表示live是文章2中第 2个关键字。
　　
　　以上就是lucene索引结构中最核心的部分。我们注意到关键字是按字符顺序排列的（lucene没有使用B树结构），因此lucene可以用二元搜索算法快速定位关键词。
　　
　　实现时 lucene将上面三列分别作为词典文件（Term Dictionary）、频率文件(frequencies)、位置文件 (positions)保存。其中词典文件不仅保存有每个关键词，还保留了指向频率文件和位置文件的指针，通过指针可以找到该关键字的频率信息和位置信息。
　　
　　 Lucene中使用了field的概念，用于表达信息所在位置（如标题中，文章中，url中），在建索引中，该field信息也记录在词典文件中，每个关键词都有一个field信息(因为每个关键字一定属于一个或多个field)。
　　
　　为了减小索引文件的大小，Lucene对索引还使用了压缩技术。首先，对词典文件中的关键词进行了压缩，关键词压缩为<前缀长度，后缀>，例如：当前词为“阿拉伯语”，上一个词为“阿拉伯”，那么“阿拉伯语”压缩为<3，语>。其次大量用到的是对数字的压缩，数字只保存与上一个值的差值（这样可以减小数字的长度，进而减少保存该数字需要的字节数）。例如当前文章号是16389（不压缩要用3个字节保存），上一文章号是16382，压缩后保存7（只用一个字节）。
　　
　　 下面我们可以通过对该索引的查询来解释一下为什么要建立索引。
　　假设要查询单词 “live”，lucene先对词典二元查找、找到该词，通过指向频率文件的指针读出所有文章号，然后返回结果。词典通常非常小，因而，整个过程的时间是毫秒级的。
　　而用普通的顺序匹配算法，不建索引，而是对所有文章的内容进行字符串匹配，这个过程将会相当缓慢，当文章数目很大时，时间往往是无法忍受的。

1.Spring架构图

2.Hibernate架构图

3.Struts2架构图

4.Struts1架构图

5.JSF请求处理生命周期图

6.Seam架构图

7.Grails架构图

8.DWR架构图

9.J2EE架构图

10.SSH整合架构图

11.Oracle架构图

12.SmartClient Ajax框架架构图

13.JavaSE总览

 14.新的JEE包结构规范

15.老的J2EE包结构规范

1, 范型
使用范型, 可以做到方法参数,返回值,集合等都是类型安全的.
特别是,一个类使用了接口作为专递参数,可使用范型,将其参数进行泛化.
优点是: 简化变量名,支持多种实现.

2, 可变参数
方法中,同类型的多个参数,可以使用如下语法精简.
public void print(String a,String b,String c)
变成
public void print(String… strs)

3, for each的迭代,简化iterator接口
针对iterator接口的作用,简化了迭代的代码量.

List strs = new ArrayList();

for (String str : strs) {
//iterator here
}

4, 静态引入
将老的”类.方法”静态引用方式,替换成import进来.
import static com.java.Test;
此处Test是静态方法

5, 自动装箱/拆箱
针对Integer,Long,Double等包装类型,以后可以直接使用int,long,double
jdk编译时,会进行转换.