blogjava-凯发k8网页登录

的第四篇文章，解读了http/2流的状态，以及状态之间的转化。(2016.10.09最后更新)

1. 概述
    http/2的流(stream)是有状态的。当客户端或服务器端在使用某个流去发送或接收特定帧(frame)或包含特定标签(flag)的帧时，会引起流的状态的转化。定义的流状态，如下所示：
    总的说，http/2为流的整个生命周期定义了7种状态：idle，reserved (local)，reserved (remote)，open，half closed (local)，half closed (remote)和closed。当一端发送或接收头部块(由一个headers/push_promise帧和紧随它的零到多个continuation帧组成的集合)或rst_stream帧，或包含有end_stream标签的帧(headers和data)之后，将改变流的状态。
    流的状态基于各端自己的视角。由于帧的传输会有网络延迟，在同一时刻，不同端认为的流的状态可能是不同的。比如，当发送端使用一个处于idle状态的流发送一个不包含end_stream标签的headers帧之后会立即认为该流处于open状态，但此时接收端尚未得到该headers帧，所以在那一时刻，接收端依然认为该流的状态是idle。

2. idle
    所有的流在创建之初都处于idle状态。处于idle状态的流，只允许被用于发送headers帧，但可以被用于接收headers和priority帧。在一端使用该状态的流发送或接收headers帧之后，该端会认为此流的状态转变为open。接收priority帧不会改变流的状态。
    一个idle状态的流可被另一个流通过发送/接收push_promise帧保留着，使其在将来被用于服务器端推送。被保留的流的状态则从idle变为reserved (local/remote)。

3. open
    处于open状态的流可被用于发送任何类型的帧。使用该状态的流去发送/接收包含有end_stream标签的帧(headers和data)之后，会使该流的状态变成half closed (local/remote)。使用open状态的流发送或接收rst_stream帧之后，则会使它的状态转变为closed。

4. half closed (local/remote)
    状态half closed (local)与half closed (remote)中的local与remote的区别，完全是基于各端自己的视角。对于同一个流的两端，如果一端认为这个流的状态是half closed (local)，那么另一端只能认为这个流的状态是half closed (remote)。
    处于half closed (local)状态的流只能被用于发送window_update，priority和rst_stream帧，但可以被用于接收任何类型的帧。相对应地，处于half closed (remote)状态的流只能被用于接收window_update，priority和rst_stream帧，但可以被用于发送任何类型的帧。

5. reserved (local/remote)
    与half closed (local/remote)状态相似，reserved (local/remote)状态中的local与remote也是基于流两端各自的视角。更具体的是，服务器端发送push_promise将一个idle状态的流保留着以用于未来的推送，并视这个被保留的流的状态为reserved (local)，而客户端则视这个流的状态为reserved (remote)。
    服务器端使用reserved (local)状态的流向客户端发送headers帧。该headers帧就是服务器端推送(server push)中被推送的响应的头部。当发送了headers帧之后，服务器端将视该流的状态为half closed (remote)。
相应地，客户端通过reserved (remote)状态的流接收到服务器端推送的响应的头部，然后会视该流的状态为half closed (local)。
    扩展一下，服务器端推送中被保留的流的状态在变为half closed(local/remote)之后才可能被用于接收/发送被推送的响应的体部，也就是data帧。

6. closed
    当一端使用一个流发送或接收到rst_stream帧，或通过状态为half closed (local/remote)的流接收/发送包含有end_stream标签的帧之后，都会视这个流的状态为closed。
    closed状态预示着流的终结，处于该状态的流将只能发送或接收priority帧。但有一个特例。即，如果通过使用half closed (local/remote)状态的流去接收或发送包含有end_stream标签的帧(headers或data)，以使该流的状态变为closed，那么在此之后的较短时间内，仍然可以接收window_update或rst_stream帧。

john jiang 2016-10-08 21:17

john jiang 2016-09-24 20:29

目前支持http/2的服务器端与客户端实现已有不少，的第二篇就分别以jetty和curl作为服务器端和客户端，描述了http/2测试环境的搭建过程。本文还将使用这个测试环境去展示jetty在实现http/2时的一个局限和一个bug。(2016.09.22最后更新)

1. http/2的实现
    目前已经有众多的服务器端和客户端实现了对http/2的支持。在服务器端，著名的apache httpd从2.4.17版，nginx从1.9.5版，开始支持http/2。在客户端，主流的浏览器，如chrome，firefox和ie，的最新版均支持http/2，但它们都只支持运行在tls上的http/2(即h2)。使用java语言实现的，则有jetty和netty，它们都实现了服务器端和客户端。此处有一份http/2实现的列表：
    另外，还有一些工具支持对http/2的分析与调试，如curl和wireshark。这里也有一份此类工具的列表：

2. 服务器端
    作为java程序员，选用一款使用java语言编写的开源http/2服务器端实现似乎是很自然的结果。实际上，在日后的研究中，我们也需要查看服务器端的源代码。这对于深入地理解http/2，并发现实现中可能的问题，具有现实意义。
    本文选择jetty的最新版本9.3.11作为服务器端。jetty是一个成熟的servlet容器，这为开发web应用程序提供了极大便利。而本文第1节中提到的netty是一个传输层框架，它专注于网络程序。可以使用netty去开发一个servlet容器，但这显然不如直接使用jetty方便。
    安装和配置jetty是一件很容易的事情，具体过程如下所示。
    假设此时已经下载并解压好了jetty 9.3.11的压缩文件，目录名为jetty-9.3.11。在其中创建一个test-base子目录，作为将要创建的jetty base的目录。
在创建base时，加入支持http，https，http2(h2)，http2c(h2c)和deploy的模块。
    注意，在上述过程中，会根据当前环境变量中使用的java版本(此处为1.8.0_60)去下载一个对应的tls-alpn实现jar文件(此处为alpn-boot-8.1.5.v20150921.jar)，该jar会用于对h2的支持。当启动jetty时，该jar会被java的bootstrap class loader加载到类路径中。
    创建一个最简单的web应用，使它在根目录下包含一个文本文件index，内容为"http/2 test"。再包含一个简单的servlet，代码如下：
web.xml主要是定义了一个servlet，具体内容如下：
该应用的部署路径为jetty-9.3.11/test-base/webapps/test.war。在该war文件所在的目录下，创建一个test.xml，其内容如下所示：
启动jetty服务器，使用默认的http和https端口，分别为8080和8443。
    根据上述日志可知，jetty启用了web应用test.war，还启动了两个serverconnector，一个支持h2c，另一个支持h2。值得注意的是，这两个serverconnector还分别支持h2c-17, h2c-16, h2c-15, h2c-14和h2-17, h2-16, h2-15, h2-14。这是因为，http/2在正式发布之前，先后发布了18个草案，其编号为00-17。所以，这里的h2c-xx和h2-xx指的就是第xx号草案。

3. 客户端
    其实最方便的客户端就是浏览器了。只要使用的firefox或chrome版本不是太老，肯定都已经支持了http/2，而且这一功能是默认打开的。也就是说，当使用firefox去访问前面所部署的web应用时，就是在使用http/2，但你不会感觉到这种变化。使用firefox提供的developer tools中的network工具查看服务器端的响应，会发现http版本为http/2.0。但此处希望这个客户端能够提供更为丰富的与服务器端进行交互的功能，那么浏览器就并不合适了。
    jetty也实现了支持http/2的客户端，但这个客户端是一个api，需要编写程序去访问http/2服务器端。而且，目前该api的设计抽象层次较低，需要应用程序员对http/2协议，比如各种帧，有较深入的了解。这对于初涉http/2的开发者来说，显然很不合适。本文选择使用c语言编写的一个工具，其实也是http/2的客户端实现之一，curl。
    curl在支持http/2时，实际上是使用了nghttp2的c库，所以需要先安装nghttp2。另外，为了让curl支持h2，就必须要有tls-alpn的支持。那么，一般地还需要安装openssl 1.0.2 。
    网络上关于在linux下安装支持http/2的curl的资源有很多，过程并不难，但有点儿繁，要安装的依赖比较多，本文就不赘述了。如果是使用windows，笔者比较推荐通过cygwin来安装和使用curl。在windows中安装cygwin非常简单，在cygwin中执行各种命令时，感觉上就如同在使用linux，尽管它并不是一个虚拟机。通过cygwin安装curl，它会自动地安装所需的各种依赖程序和库。
    在笔者的机器上，通过查看curl的版本会出现如下信息：
由上可知，笔者使用的curl版本是7.50.2，nghttp2版本是1.14.0，而openssl版本是1.0.2h。

4. 第一次尝试
    在第一次尝试中，只需要简单地访问第2节中部署的web应用中的静态文本文件index，以感受下h2c，完整命令如下：
在输出中包含有如下的内容：
">"是客户端发送的请求，"<"是服务器端发送的响应，而"*"是curl对当前过程的说明。结合本系列中所简述的http 2协议，可以有以下的基本理解。
[1]客户端发起了一个http/1.1的请求，其中携带有upgrade头部，要求服务器端升级到http/2(h2c)。
[2]服务器端同意升级，返回响应"101 switching protocols"，然后客户端收到了101响应，http/2连接进行确认。
[3]服务器端响应最终结果。状态行中出现的http版本为http/2，状态代码为200，且后面没有跟着"ok"。最后输出了index文件的内容"http/2 test"。

5. 一个局限
    这次，在发起的请求中包含体部，命令如下：
在输出中包含有如下的内容：
    和第4节中的输出进行比较，会发现缺少了"101 switching protocols"那一段，而且最终响应状态行中出现的http版本是http/1.1。这就说明服务器端不同意升级，后面继续使用http/1.1。刚刚部署的jetty未做任何改变怎么会突然不支持http/2了呢？或者这是curl的问题？其实，这是因为jetty服务器端在实现h2c时不支持请求中包含体部。另外，apache httpd也有同样的问题。如果是使用h2，则没有这个限制。这背后的原因超出了本文的范畴，不作表述。

6. 一个bug
    在这次尝试中，测试一下两端对100-continue的支持。如果请求中使用了头部"expect: 100-continue"，那么正常地该请求要有体部。但由于在第5节中介绍的问题，此时不能再使用h2c，而只能使用h2。另外，这次不访问静态文件，而是访问servlet(此处为/test)。完整命令如下：
在输出的最后出现了如下信息：
这其实是jetty的一个，正在开发中的9.3.12已经修复了它。

7. 小结
    http/2依然算是新潮的技术，对各家的实现，无论是服务器端，客户端，还是分析工具，都要持有一份怀疑态度。这些实现和工具都是程序，都有可能存在bug。而且协议对许多细节没有作出规定，各家都会发挥自己的想像力。比如，apache httpd和jetty在实现服务器端推送时，其方式就不尽相同。
    在开发自己的http/2实现或应用的时候，需要同时使用已有的不同服务器端和客户端去部署多套测试环境进行对比分析。

john jiang 2016-09-20 16:42

http/2的协议包含着两个rfc：hypertext transfer protocol version 2 ()，即http/2；hpack: header compression for http/2 ()，即hpack。rfc7540描述了http/2的语义，rfc7541则描述了用于http/2的头部压缩的格式。本文只涉及http/2协议，本系列的后续文章将会涉及hpack协议。(2016.10.13最后更新)

1. http/2要解决的问题
     http/1.0只允许在一个tcp连接中出现一个请求。后来的http/1.1虽然引入了请求流水线，以允许在一个连接中发送多个请求，但这只是部分地解决了请求并发的问题。服务器端在返回响应时，还是必须要按照它接收到的请求的顺序进行返回。如果排在前面的响应要消耗较长的时间，那依然会对后面的响应的造成阻塞，亦即线头阻塞(head-of-line blocking)。所以，客户端必须要使用多条连接去发起多个的请求以实现并发，并进而减小延迟。更大的并发会增大服务器的负载，也会占用更大的网络带宽。另外，头部通常会包含有大量的信息，如cookie，而这也会增加网络传输的开销。
     http/2允许在同一个tcp连接中交错地出现多个请求与响应，亦即多工(multiplex)。同时，它使用了一个高效的编码方法对头部进行压缩。http/2还允许对请求进行优先级排序，以便让更为重要的请求得以更快的完成，这会进一步提高性能。http/2还改变了服务器端只能被动地向客户端返回响应的定式，允许服务器端主动地向客户端推送数据，这就可以减少客户端发起请求的数量。
     总之，http/2主要是解决性能问题。

2. 发起http/2
     http/2会使用与http/1相同的uri scheme，即http和https。而且实现http/2的服务器端也不会使用不同的端口去分别支持http/1和http/2。这样有利于平滑地从http/1升级到http/2。毕竟目前已部署的绝大部分网络服务都只支持http/1，当未来它们升级到http/2时，如果换用了不同uri scheme或端口，那么肯定会对客户端产生极大的影响。但是http/2协议为运行在http和https上的http/2分别定义了两个不同的标识符：h2c和h2。h2c中的"c"指的是cleartext，即明文。本文后面会使用h2c指代运行在http2上(直接使用tcp)的http/2，而用h2指代运行在https上(使用tls)的http/2。
     那么，支持http/2的客户端如何知道它所连接的服务器端是否也支持http/2呢？
     对于h2c，支持http/2的客户端可以在发起的请求中使用http/1.1的upgrade头部去尝试要求服务器升级到http/2。该请求的格式如下：
get / http/1.1
host: server.example.com
connection: upgrade, http2-settings
upgrade: h2c
http2-settings:
http2-settings是一个经由base64编码过的字符串，其原始内容是客户端将要发送的settings帧的载荷，即一些配置参数。
     如果服务器端支持http/2，它就响应"101 switching protocols"，表示可以进行升级。该响应的格式如下：
http/1.1 101 switching protocols
connection: upgrade
upgrade: h2c
     如果服务器端不支持http/2，则会忽略upgrade请求头部，后续依然使用http/1.1。
     对于h2，会使用到协议transport layer security (tls) application-layer protocol negotiation extension ()，即tls-alpn。该协议允许客户端和服务器端就使用何种版本的http进行协商。如果tls-alpn在现实中运行良好的话，也许某天还会使用该方法去协商使用别的协议。
     当客户端与服务器端都同意使用http/2时，双方都需要各自发出一个连接序言(connection preface)以进行最后的确认。
     客户端在接收到服务器端的"101 switching protocols"响应(针对h2c)或tls连接的第一个应用数据字节(针对h2)之后会立即发出连接序言。该序言的开头是"pri * http/2.0\r\n\r\nsm\r\n\r\n"(其十六进制形式为"0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a")⁽¹⁾，后面必须再跟一个settings帧，哪怕这个帧是空的。
     服务器端的连接序言则由一个settings帧构成，该帧必须是服务器端在http/2连接中发送的第一个帧。这个settings帧可以为空，也可以包含一些希望客户端如何与自己进行通信的必要配置信息。

3. 帧(frame)
     http/2消息使用二进制格式(实际编码时使用十六进制书写)，相比于文本格式，这样可以提高消息处理的效率。http/2消息的最小单元为帧，它由头部与载荷(payload)组成。每个帧的长度必须是一个或多个8比特位字节(octet，下文将其简写为"字节")。
     帧头部依次包含有如下的5个字段：
     长度(length)：该字段占用24个比特位，代表帧载荷的长度。该长度是一个24位的无符号整数。
     类型(type)：该字段占用8个比特位，代表帧的类型。
     标志(flags)：该字段占用8个比特位，代表帧所定义的一个或多个标志。并不是所有的帧都定义了标志。
     保留位(r)：该字段占用1个比特位，其语义尚未被定义。在读取帧时，该位需要被忽略；但在发送帧时，该位需要保持为0(0x0)。
     流标识符(stream identifier)：该字段占用31个比特位，代表该帧所在流的标识符。
     在头部之后，紧接着的就是载荷。载荷的结构与内容完全由帧的类型决定，它的长度也是不定的。

     http/2定义了如下10种不同类型的帧。
     data：用于携带一组长度不定的字节。一个或多个data可作为请求或响应的载荷。
     headers：用于开启一个流，并可携带一个头部块片断。头部块指由一个headers/push_promise帧和紧随它的零到多个continuation帧组成的集合，因为只有它们才可能携带头部信息。这个集合可被分割成一个或一组字节，这样的字节被称为头部块片断。头部块中各个特定类型的帧必须紧紧相邻，不能出现其它类型的帧。
     priority：用于指定发送端建议的流优先级。
     rst_stream：用于立即终止流。当希望取消一个流或发生错误时，就可发送rst_stream帧。
     settings：用于携带可以影响两端之间通信方式的配置参数。settings帧定义了一个ack标志，用于指示该帧所设置的参数是否已被接收端获知。当收到一个settings且其中的ack标志为0时，接收端必须尽可能快的应用其中已被更新的参数。
     push_promise：用于向接收端通知发送端将要创建的流。当接收端接收到该帧时，新的流尚未被发送端创建，但发送端承诺会创建该流。该帧用于实现http/2的重要特性"服务器端推送(server push)"。
     ping：用于测量发送端与接收端之间的最小往返时间。这与使用众所周知的ping命令的目的相似，是为了测试某个空闲的连接是否还可用。
     goaway：用于发起对连接的关闭，或触发严重的错误条件。该帧允许一端，在完成对之前已创建的流的处理的同时，优雅地停止接收新的流。一端在创建新的流，另一端在发送goaway，这两者之间天然存在着竞争关系。为了就对这种情况，发送端在发送goaway时会让它携带上(该发送端所知晓的)接收端最后创建的流的标识符，当该goaway被发送之后，发送端将会忽视由接收端创建的任何一个标识符比该标识符大的流。
     window_update：用于流量控制。该帧的载荷由一个单比特保留位和一个31比特位的无符号整数组成。该整数向该帧的接收端指示了其向当前流量控制窗口所能增加传输量的值。
     continuation：用于继续发送头部块片断。只要同一个流中前面的帧是headers，push_promise或continuation，并且该帧没有设置end_headers标志，那么可无限量地发送continuation帧。
     部分帧，data，headers和push_promise，的载荷中可能包含填白(padding)。填白在业务上没有实际的用处，它的出现是基于安全目的。比如，可以用它来扰乱实际数据的长度，以减轻特定的http攻击。

     发送端发送的帧的最大长度要尊重接收端设定的settings_max_frame_size的值。但该值的范围要介于2^14至2^24-1个字节之间。

4. 流(stream)
     流是用于在客户端与服务器端之间进行帧传送的通道，同一个tcp连接中可以同时有多个流，如下图所示，
服务器端和客户端可以交错地向同一个连接中的不同流中传送帧。可以把一个流看作http/1中的一个连接。客户端与服务器端在同一个流中的交互依然遵循发送请求-等待响应模式。两端都可以创建新的流，共享对方创建的流，也可以关闭对方创建的流。帧在流中的顺序是有意义的，接收端会以接收到的顺序去处理帧。
     每个流都有一个标识符，是一个31比特位的无符合整数。在同一个连接中，流标识符是唯一的。由客户端创建的流的标识符为奇数，由服务器创建的流的标识符为偶数。但标识符为0的流可看作连接，用于连接控制信息，创建新的流时不可使用该标识符。同一个连接中的任何一个流的标识符都不可重用，即便这个流已被关闭了。对于长时间没有中断的连接，可能会出现标识符不够用的情况，那时就必须强制创建一个新的连接。
     http/2协议为流的生命周期定义了7种状态⁽²⁾：idle，reserved(local)，reserved(remote)，open，half closed(local)，half closed(remote)和closed。当一端接收或发送头部块或(帧data和headers的)标志rst_stream后可使流的状态发生转变。
     使用流来实现多工就会引起对tcp连接使用的竞争，这会造成流的阻塞。基于帧window_update的流量控制方案可以确保相同连接中的流相互之间不会产生破坏性干扰。流量控制可以作用于两个层面，即单个流或整个连接。只有帧data需要遵守流量控制，所有其它的帧所有消耗的空间均不会占用流量控制窗口。http/2协议只是定义了window_update帧的结构和语义，协议的实现可以选择任何适用自己的流量控制算法。
     流可以有优先级。客户端在创建一个新的流时，可在headers中指定优先级权重。在后续任何时间，通过priority可以改变流的优先级权重。在并发能力有限的情况下，高权重流的帧会被优先传送。权重的值必须介于1至256之间，默认权重为16。流与流之间还可以有依赖关系，这种关系会组成一棵依赖关系树。一个流能够指定自己成为另一个流的子流。这一过程，可以是非排他的，也可以是排他的。非排他性依赖，是指一个流在将自己变成另一个流的子流的过程中，允许另一个流还有别的子流，即允许有自己的兄弟流存在。排他性依赖，指在前述过程中，不允许另一个流还有别的子流。如果另一个流已经有子流了，那么该流会把所有潜在的兄弟流先变成自己的子流，然后再使自己成为另一个流的唯一子流。其实，排他性依赖的作用就是为了能够打破已有的关系树，在既成的父子节点中插入新的节点。否则，只能为已有节点添加子节点，那么关系树将不可能进行重构。所有的流在被创建时，默认成为标识符为0x0的流的子流。在"服务器端推送"中生成的"推送"流将自动地成为生成该推送流的流的子流，其默认权重也为16。

5. 消息交换
5.1 请求/响应交换
     http/2沿袭了http/1的语义，即所有的请求与响应语义均得到了保留，尽管传递这些语义的语法已经改变了。
     一个http/2消息由如下几个部分组成：
     [1]仅对于响应消息，可以包含一个携带有1xx响应头部的头部块。该头部块由一个headers帧和紧随它的零到多个continuation帧组成。
     [2]一个头部块。该头部块由一个headers帧和紧随它的零到多个continuation帧组成。
     [3]零到多个携带有体部(body)消息的data帧。http/1中使用的"分块(chunked)"体部将不适用于http/2。因为一个体部可由多个data帧组成，所以http/2的体部天然就是可分块的。
     [4]一个可能存在的包含着尾部消息的头部块。该头部块由一个headers帧和紧随它的零到多个continuation帧组成。

     http/2仍然沿用http/1中的头部字段，但字段名称中的字母必须全部为小写。另外，还将http/1消息开始行(请求中的与响应中的)中的消息，分解成了若干伪头部字段，此类字段均以冒号(:)开头。
     http/1请求行格式为"method request-target http-version"，对应的http/2伪头部字段有:method=method和:path=request-target，但http-version无对应字段，默认为http/2。
     http/1状态行格式为"http-version status-code reason-phrase"，对应的http/2伪头部字段有:status=status-code。但http-version无对应字段，默认为http/2；reason-phrase也无对应字段，因为可以通过状态代码查找到其对应的reason-phrase。http/2协议是在尽量减少冗余消息。
     http/2协议还为请求头部定义了另外两个伪字段：
     :scheme：uri中的scheme部分。它可以不仅仅是http或https，因为有时候可能会与非http服务进行交互。
     :authority：uri中的授权部分。即，scheme://user:password@host:port/path?query#fragment中的"user:password@host:port"。
     http/2协议节中给出一些简单示例，展示了如何将http/1消息对应到http/2消息。
5.2 服务器端推送
     http/2的服务器端推送是传统的请求/响应模式的一种特殊形式。服务器端在收到客户端的请求(主请求)之后，为了主动向客户端推送更多的内容，会自动地生成若干新的请求(推送请求)。服务器向客户端发送的响应中，不仅包含对主请求的响应(主响应)，还包含对推送请求的响应(推送响应)。
     客户端可以通过发送包含有settings_max_concurrent_streams参数的settings帧去禁用服务器端推送，也可以通过发送rst_stream帧去取消已经发起的服务器端推送，但不能发送包含有end_stream标志的帧。

(1)"pri * http/2.0\r\n\r\nsm\r\n\r\n"中的"pri"与"sm"合起来就是"rrism(棱镜)"。呵呵，httpbis工作组这是想表达什么意思呢 ;-)
(2)本系列的解读了流的状态。

john jiang 2016-09-19 11:36

3. 覆盖java核心api？
开发者们在使用主流ide时会发现，如果工程有多个jar文件或源文件目录中包含相同的类，这些ide会根据用户指定的优先级顺序来加载这些类。比如，在eclipse中，右键点击某个java工程-->属性-->java build path-->order and export，在这里调整各个类库或源文件目录的位置，即可指定加载类的优先级。
当开发者在使用某个开源类库(jar文件)时，想对其中某个类进行修改，那么就可以将该类的源代码复制出来，并在java工程中创建一个同名类，然后指定eclipse优先加息自己创建的类。即，在编译时与运行时用自己创建的类去覆盖类库中的同名类。那么，是否可以如法炮制去覆盖java核心api中的类呢？
考虑去覆盖类java.util.hashmap，只是简单在它的put()方法添加一条打印语。那么就需要将src.zip中的java/util/hashmap.java复制出来，并在当前java工程中创建一个同名类java.util.hashmap，并修改put()方法，如下所示：
此时，在eclipse环境中，synchronizedhashmap使用的java.util.hashmap被认为是上述新创建的hashmap类。那么运行应用程序syncmaptest后的期望输出应该如下所示：
但运行syncmaptest后的实际输出却为如下：
看起来，新创建的java.util.hashmap并没有被使用上。这是为什么呢？能够"想像"到的原因还是类加载器。关于java类加载器的讨论超出了本文的范围，而且关于该主题的文章已是汗牛充栋，但本文仍会简述其要点。
java类加载器由下至上分为三个层次：引导类加载器(bootstrap class loader)，扩展类加载器(extension class loader)和应用程序类加载器(application class loader)。其中引导类加载器用于加载rt.jar这样的核心类库。并且引导类加载器为扩展类加载器的父加载器，而扩展类加载器又为应用程序类加载器的父加载器。同时jvm在加载类时实行委托模式。即，当前类加载器在加载类时，会首先委托自己的父加载器去进行加载。如果父加载器已经加载了某个类，那么子加载器将不会再次加载。
由上可知，当应用程序试图加载java.util.map时，它会首先逐级向上委托父加载器去加载该类，直到引导类加载器加载到rt.jar中的java.util.hashmap。由于该类已经被加载了，我们自己创建的java.util.hashmap就不会被重复加载。
使用java命令运行syncmaptest程序时加上vm参数-verbose:class，会在窗口中打印出形式如下的语句：
从中可以看出，类java.util.hashmap确实是从rt.jar中加载到的。但理论上，可以通过自定义类加载器去打破委托模式，然而这就是另一个话题了。

john jiang 2015-11-01 20:06

john jiang 2015-10-30 23:17

利用java se 8流处理数据
-- 结合stream api的高级操作去表示富数据处理查询

john jiang 2014-08-15 19:57

本文是 201403/04刊中的一篇文章，也是文章系列"利用java se 8流处理数据"中的第一篇，它概述了java流的基本原理与基本应用，是一篇很好的java streams api的入门文章。(2014.07.27最后更新)

    没有集合对象，你会怎么样？几乎每个java应用都会创建并处理集合。它们是许多编程任务的基础：集合使你能够对数据进行分组和处理。例如，你也许会创建一个关于银行交易的集合，该集合代表了某个用户的银行流水清单。然后，你可能想要处理整个集合去算出该用户花了多少钱。尽管数据处理十分重要，但java在此方面表现的远不完美。
    首先，典型的集合处理模式与类sql操作相似，诸如"查找"(如找出最大金额的那笔交易)或者"分组"(如，将与购买杂货相关的交易进行分组)。大部分数据库允许你以声明的形式去指定这些操作。例如，后面的sql查询会让你找到那笔最大金额交易的id："select id, max(value) from transctions"。
    如你所见，我们并不需要去实现如何计算最大值(例如，使用循环和一个变量去追踪这个最大值)。我们仅需要表达什么是我们想要的。这种基本思想就意味着，你不太需要担心去显式地实现这些查询--它们已经为你处理好了。为什么我们不能在处理集合时也这样做呢？你发现自己有多少次都是在一遍又一遍地使用循环去重复实现这些操作呢？
    其次，我们如何才能更高效地去处理大型集合？理想情况下，在加速进行处理时，你会想到利用多核架构。然而，编写并行程序既困难又容易出错。
    java se 8赶来帮忙了！java api的设计者们在升级api时引入了一种新的称之为java流(流)的抽象，它允许你以声明形式去处理数据。另外，java流可以利用到多核架构而不必编写一行多线程代码。听起来不错，不是吗？这就是本文章系列所要探究的主题。
    java流能为我们做些什么呢？在探究这些细节之前，让我们先看一个例子，这样你才能对这种新的使用java se 8 java流的编程风格有感觉。假设我们要找到所有类型为grocery的交易并返回它们的id列表，并按交易金额的递减顺序对该列表进行排序。在java se 7中，我们应该会把清单1所示的程序那样去做。而在java se 8中，我们则会像清单2所示的那样去实现。
清单1

清单2

    图1形象地解释了那段java se 8程序。首先，我们调用list对象中的java流()方法从交易列表(数据)中获取一个java流对象。然后，多个操作(过滤，排序，映射，归集)链接在一起形成了一条线，这条线可以被看作构成了一条数据查询。


    那么如何并行地执行该程序呢？在java se 8中这很简单：只需要使用paralleljava流()方法去替换java流()方法，如清单3所示。java流 api会在内部对你的查询进行解构，并利用上你机器中的多核处理器。
清单3

    在该关于java se 8 java流的文章系列结束时，你将能够使用java流 api编写出像清单3那样的功能强大的查询程序。

java流入门
    让我们先从一点理论开始。java流的定义是什么？一个简短的定义就是"来自于一个数据源的能够支持聚合操作的一串元素"。让我们把它拆开来说：
    一串元素：java流为一串特定类型值的集合提供了一个接口。然后，java流实际上并不存储元素，它们会在需要时被用上。
    数据源：java流要使用一个提供数据的源，诸如集合对象，数组或i/o资源。
    聚合操作：java流支持类sql的操作，以及来自于函数编程语言的通用操作，诸如过滤，映射，归一，查找，匹配，排序，等等。
    另外，与集合操作非常不同的是，java流操作拥有两项基本特质：
    管道：许多java流操作会返回它们自己，这就使得这些操作能够链接在一起以组成一个大型管道。这样就可以进行一些诸如惰性和短路之类的优化，后面我们会进行探究。
    内部遍历：集合是显式地进行遍历(外部遍历)，但不同于集合，java流是在幕后进行遍历。让我们重新看看之前的示例代码来解释这些原理。图2形象地解释了清单2的更多细节。


    首先，通过调用java流()方法，我们从交易列表中得到了一个java流对象。那么数据源就是交易列表，它将向java流中提供一串元素。然后，我们对该java流应用了一系列的聚合操作：过滤(提供一个谓语去过滤元素)，排序(提供一个比较器去对元素进行排序)，以及映射(解析出信息)。所有的操作都会返回该java流，以便能够链接这些操作去组成一个管道，这可被看作是对数据源的一个查询。
    在调用collect()操作之前，没有实际工作会被执行。collect()方法将开始处理这个管道以返回一个结果(某个不是java流的对象，在此处，是一个list对象)。现在还不需要去关注collect()方法，我们会在以后的文章去一探究竟。此时，你会发现collect会将各种数据加工方法作为参数，将收集到的java流元素归结为一个结果。此处，tolist()就描述了一个将java流对象转化为list对象的加工方法。
    在探究与java流有关的各个方法之前，最好是停下来深入思考一下java流和集合之间观念上的不同之处。

java流 vs. 集合
    已有的java集合概念与新的java流概念都为一串元素提供了接口。那它们有何不同吗？简单地说，集合是关于数据的，而java流是关于计算的。
    想想这种情况，一部存储在dvd中的电影。这就是一个集合(可能是字节，可能是帧--在此处，我们不必关心这些)，因为它包含有全部的数据结构。现在再想想这种情况，这部电影被转化成了数据流，通过互联网去观看它。此时它就是一个(字节或帧的)流。流视频播放器只需要下载一些晚于用户当前所观看位置的帧就可以了。这样，你就可以在大部分值被计算出来之前先展示流开头处的值(想想流化一场现场直播的足球比赛)。
    粗看之，集合与流的区别就是与何时处理数据有关。集合是内存中的数据结构，它包含有当前数据结构中的全部值--将所有元素加入到集合之前，必须先对所有元素进行处理，相反地，java流只是逻辑上固定的数据结构，它里面的元素只会根据需要进行处理。
    使用collection接口，要求用户实现遍历(例如，使用增强的for循环，即foreach)；这被称之为外部循环。相反地，stream类库使用内部遍历--它已经为你实现好了遍历，它会关心存储流的结果值的位置；你仅需要提供一个函数告诉它要做些什么就行了。清单4(对集合的外部遍历)和清单5(对java流的内部遍历)中的代码形象地展示了这一不同之处。
清单4

清单5

    在清单4中，我们显式且顺序地遍历了交易列表，抽取了每个交易id，然后将它加到一个收集器中。相反地，当使用流时，没有显式的遍历。清单5中的代码构建了一个查询，其中的map操作被设定为一个参数，它会抽取交易id，然后collect操作会把结果stream对象转化成一个list对象。
你现在应该知道什么是java流，以及如何去使用它。现在让我们看看java流所支持的操作之间的区别，这样你就能构建自己的数据查询了。

java流操作：使用流去处理数据
    java.util.stream.stream接口定义了许多操作，它们可被归集为两类。在图1所示的例子中，你可以看到如下操作：
    过滤，排序和映射，它们可被连接在一起组成一个管道
    收集，它关闭了这个管道并返回结果
    能够被连接在一起的java流操作被称为中间操作。这些操作之所以能被连接在一起，是因为它们都会返回stream对象。这些操作从这个管道中返回结果，结果的类型可以是list，integer，甚至是void(任何stream以外的类型)
    你也许很好奇为什么这种区别很重要。是这样的，在这个java流管道的最终操作被调用之前，中间操作并不会执行任何处理；它们是"惰性"方法。这是因为中间方法经常会被"合并"，在最终操作中它们会被合成为单一的执行路径。
清单6

    例如，思考下清单6中的程序，它是从给定的数列中计算奇数的平方。你可能会很惊讶，它打印出如下结果：

    这是因为limit(2)使用了短路；我们只需要处理流的一部分，而不是全部，去得到一个结果。这就类似于测评一个由and操作符关联起来的大型布尔表达式链：一旦某个表达式返回了false，那么就可以认为整个表达式链就是false，而不必测评所有的表达式了。在这个例子中，limit()方法将返回的java流的长度限定为2。另外，filter与map被合并在了同一条执行路径中了。

    归纳一下到目前为止，在使用java流时我们所学到的内容，总言之，涉及三个方面：
    一个数据源(例如一个集合)，对它执行查询
    一个中间操作的链，它组成一个流的管道
    一个最终操作，它执行流的管道并产生结果
    现在让我们看看java流所支持的一些操作。参考java.util.stream.stream接口可以得到这些方法的完整清单，再看看本文末尾所给出的资源，它包含有更多的例子。

    过滤。有多种方法可以对流中的元素进行过滤：
    filter(predicate)：使用一个谓语(java.util.function.predicate)作为参数，它会返回一个包含所有匹配给定谓语条件元素的java流。
    distinct：返回一个包含有唯一元素的java流。
    limit(n)：返回的流的长度不能超过n。
    skip(n)：返回的流将不包括前n个元素。

    查找与匹配。一个通用的数据处理模式就要考虑一些元素是否匹配给定的属性。你可以使用anymatch，allmatch和nonematch方法帮你做到这一点。这些方法都会使用一个谓语参数并返回boolean值作为结果(所以，它们是最终操作)。例如，使用allmatch去查出交易流中所有金额大于100的交易，如清单7所示。
清单7

    另外，stream接口提供了方法findfirst和findany，以取出流中任一元素。它们可以与其它的流操作，如filter，结合起来使用。findfirst和findany都会返回一个optinal对象(见清单8)。
清单8

    optional类(java.util.optional)是一个容器类，它代表一个存在或不存在的值。清单8中的程序，findany方法可能没有找到任何类型为grocery的交易。optional类包含多个方法去测试一个元素是否存在。例如，如果交易存在，通过使用ifpresent方法，我们可以选择一个操作去应用这个optaional对象，如清单9所示(此处只是打印交易)。
清单9

    映射。java流支持map方法，它使用一个函数(java.util.function.function)作为参数，将流元素投影到其它形式。这个函数会被应用到每个元素，并将元素"映射"到新的元素。
    例如，你可能会想到使用它去抽取流中每个元素的信息。在清单10的例子中，我们返回了一个列表中每个字的长度。
清单10

    归一。到目前为止，我们已见过的最终操作会返回boolean(allmatch等等)，void(foreach)或optaional对象(findany等等)。我们也使用collect方法将stream对象中的所有元素放到一个list对象中。
    然而，你也可以将流中的元素放到一个查询中，该查询可表达更为复杂的数据处理，例如"拥有最大id"或者"算出所以交易金额的和"。这就可能对java流用上reduce方法，该方法会对每个元素重复地应用一个操作(例如，加上两个数字)，直到生成结果。在函数式编程中，这常被称为折叠操作。因为该操作可被看作重复地"折叠"一张很长的纸(stream对象)，直到这张纸的面积变得只有一点儿了。这就是折叠操作的结果。
    看看我们是如何使用循环去计算一个组数字的和会有助于理解这个问题：

    列表中的每一个数字元素都被迭代地组合在一起，并使用一个额外的操作符去产生结果。本质上，我们就是把一组数字"归一"成一个数字。在这段代码中有两个参数：数字和变量的初始值，即该例中的0，以及用于合并所有元素的操作符，即本例中的 。
清单11

    对java流使用reduce方法，我们可以计算出流中的所有元素值之和，如清单11所示。reduce方法使用两个参数：
    初始值，0
    binaryoperation，合并两个元素，并产生一个新值
    reduce方法本质上就是重复应用模式的抽象。其它的查询，如"计算产量"或"计算最大值"(如清单12所示)则是reduce方法的特别实例。
清单12

数字流
    你已经看到可以使用reduce方法去计算整数流的和。然后，这也是有成本的：我们重复执行了许多拆箱操作以将integer对象加到一起。如果我们能调用一个sum方法，使程序的意图更为明显，就像清单13那样，岂不是更好？
清单13

    java 8引入的三个特定的基本数据类型的流接口来应对这个问题--intstream，doublestream和longstream--它们专注于元素分别为int，double和long型的java流。将一个流转化为特定类型的流，你最常使用的方法就是maptoint，maptodouble和maptolong。这些方法与我们较早前看到的map方法是一样的，但它们会返回特定类型的stream对象，而不是stream对象。例如，我们可以改进下清单13中的代码，如清单14所示那样。你也可以使用装箱操作将一个基本数据类型的流转化成一个使用包装对象的流。
清单14

    最后，数字流的另一种有用的形式是数字区间。比如，你可能想生成介于1到100之间的所有数字。为了帮助生成这种区间，java se 8在intstream，doublestream和longstream中分别引入了两个静态方法：range和rangeclosed。
    这两个方法都会使用两个参数，第一个参数是起始值，第二个参数是终止值。但是range方法生成的区间不会包含终止值本身，但rangeclosed生成的区间则会包含。清单15是一个使用rangeclosed方法的例子，它返回一个包含有全部介于10到30之间奇数的流。
清单15

构建流
    有多种途径可以去构建一个流。你已经看过如何从集合对象中构建流。另外，我们还操控过数字流。你也可以从值，数组或文件中去创建流。另外，你甚至于可以从一个函数中生成无限流。
    可以直截了当地从值或数组中创建流：只需要使用一些静态方法即可，对于值，是stream.of()；而对于数组，则要调用arrays.stream()。如清单16所示。
清单16

    你也可以将一个文件转化为其内容行的流，使用静态方法files.lines()即可。清单17就使用该方法计算了文件中行的数量。
清单17

    无限流。最后，在总结本文之前，有一个令人非常兴奋的主意。到现在为止，你应该理解到流中的元素是按需生成的。有两个静态方法--stream.iterate()和stream.generate()--可以让你从一个函数中创建流。然而，因为被使用的元素是按需生成的，所以这两个方法可以"永远地"生成元素。这就是为什么我们称它为无限流：它就是没有固定大小的流，但它做的事情与一个从固定集合生成的流是一样的。
    清单18就是一个使用iterate方法的例子，它会包含10的所有倍数。iterate方法使用一个起始值(此处的0)和一个lambda表达式(类型为unaryoperator)去顺序地生成每一个新值。
清单18

    我们也可以使用limit方法，以从一个无限流中得到一个固定流。如清单19所示，可以将流的长度限制为5。
清单19

结论
    java se 8引入了streams api，它让你能够表达更为复杂的数据处理查询。在本文中，你已见到流可以支持许多操作，诸如过滤，映射，归一和迭代，把它们结合在一起可以写出简洁的、更富表现力的数据处理查询。这种新的编程方法远不同于java se 8之前的集合处理。但是，它有许多好处。首先，它利用到了诸如惰性或短路这样的技术，以优化数据处理查询的性能。其次，能够自动地利用上多核架构，以并行地处理流。在本文章系统的第二部分中，我们将探索更高级的操作，例如flatmap和collect。请继续关注。

john jiang 2014-07-27 20:54

john jiang 2014-05-05 00:12

john jiang 2014-04-19 23:48

john jiang 2014-02-28 15:25

本文是发布在上的一篇摘自于一书中的，介绍了使用构建java web应用的过程。刚刚接触gradle，看到了这篇小文，随手译了出来:-) (2014.01.23最后更新)

当今世界，一派繁忙。在职业生涯和私人生活中，我们中间的许多人要同时管理多个项目。你可能常常发现自己处于不知所措及失控的状态。保持规整并专注于价值的关键是一个维护良好的工作清单。当然，你可能总是把你的任务写在一张纸上，但是你也许不可能在你所处的任何地方都可方便地获得这些工作条目？对互联网的访问几乎是无处不在的，无论是通过你的移动电话，还是公共的网络接入点。在一书中，如图1所示的说明性示例是一个很有吸引力的可视化web应用。

图1 to do应用可以通过互联网进行访问，并使用它去管理数据存储中的工作条目

gradle插件表现的如同一个使能器，它会自动地执行这些任务。一个插件通过引入特定领域的规范以及对缺省值敏感的任务去对工程进行扩展。随gradle发布的插件之一就是java插件。该java插件绝不仅仅是提供了源码编译和打包这样的基础功能。它为工程建立了一整套标准的目录布局，它会确保以正确的顺序去执行任务，这样，这些任务在java工程环境中才是有意义的。现在是时候为我们的应用去创建一个构建脚本并去使用这个java插件了。

构建java应用
一开始，每个gradle工程都会创建一个名为build.gradle的构建脚本。为了创建该脚本，并告诉该工程使用java插件，应该像这样去做：
为了构建你的java代码，一行代码就够了。但gradle怎么知道去哪儿找你的源文件呢？该java插件引入的规范之一就是源代码的路径。默认地，该插件会到目录src/main/java中搜寻产品的源代码。

构建web应用
通过war插件，gradle也提供了构建web应用的扩展支持。war插件扩展了java插件，它加入了针对web应用程序开发的规范，并支持归集war文件。让我们也在这个工程中用用war插件：
web应用源文件的默认路径是src/main/webapp。假设你已经明确了该应用所必要的java类。那么要使产品的全部源代码和web资源文件处于正确路径下，该工程的目录布局应该像下面这样：

声明外部依赖
在实现这个web应用的过程，我们使用的一些类，例如javax.servlet.httpservlet，并非java标准版(java se)的一部分。在构建工程之前，我们需要确保已经声明了这些外部依赖。在java系统中，依赖类库是以jar文件的形式去发布和使用的。许多类库可以从仓库，如一个文件系统或中央服务器，中获得。为了使用依赖，gradle要求你至少定义一个仓库。出于一些考虑，我们将使用公共的可通过互联网进行访问的maven central仓库。
在gradle中，依赖是通过配置项来进行分组的。我们将来servlet依赖使用的配置项是providedcompile。该配置项用于那些在编译时而非运行时所需的依赖。像jstl这样的运行时依赖，在编译时不会被用到，但在运行时则会被用到。它们都会成为war文件的一部分。下面的配置语句块声明了我们应用所需的外部类库：

构建工程
我们已经准备好构建这个工程了。另到工程中的一个java插件任务名为build。该任务将编译源代码，运行测试程序并归集war文件--所有的这些任务都将以正确的顺序被执行。执行命令gradle build之后，你可能会得到形如下面的输出：

上述输出的每一行都代表执行了一个由java或war插件提供的任务。你可能会注意到，有一些任务被标记为up-to-date。它的意思是指该任务被跳过去了。gradle的增量构建支持策略会自动识别不需要执行的工作。特别是在大型商业项目中，该特性会极大地节省时间。
在该工程的根节目录中，你将会发现一个名为build的子目录，它包含有执行构建之后的全部输出，包括类文件，测试报告，归集的war文件，以及像manifest这样的在打包时需要的临时文件。如下就是执行构建工作之后的工程目录结构：
你已经知道如何从一个基于标准目录结构的web工程去构建war文件。现在是时候将它布署到一个servlet容器中去了。在下一节中，我们将在本地开发机器中启动jetty去运行这个web应用。

运行应用
在本地机器中运行一个web应用应该很容易，能够实践快速应用开发(rad)，并能够提供快速的启动时间。最棒地是，它不要求你部署一个web容器运行时环境。jetty一个流行的轻量级开源web容器，它支持前面提到的所有特性。在这个web应用中加入一个http模块，它就变成了一个嵌入式实现。gradle的jetty插件扩展了war插件，它提供的任务可以将一个web应用部署到嵌入式容器中，并能够启动该应用。在你的构建脚本中，可以像如下那样使用这个插件：
这个将被我们用于启动web应用的任务名为jettyrun。它甚至可以在无需创建war文件的情况下启动一个jetty容器。执行上述命令后会得到如下形式的输出：
在上述输出的最后一行中，该插件告诉了你jetty即将侦听的请求地址。打开一个你喜欢的浏览器，并输入上述地址。最后，我们会看到这个to do web应用的行为。图2展示在一个浏览器中查看到该应用界面的截屏。

图2 to do应用的web界面及其行为

在你通过组合键ctrl c去停止这个应用之前，gradle会让它一直运行。jetty如何知道使用哪个端口和上下文环境去运行这个web应用？再说一遍，这就是规范。jetty运行web应用所使用的默认端口就是8080。

总结
只需要较少的努力，你就可以使用gradle去构建并运行一个java web应用。只要你严格遵循标准目录结构，那么你的构建脚本仅需要两行代码。

john jiang 2014-01-23 21:22

john jiang 2013-12-29 20:19

john jiang 2013-12-07 17:45

john jiang 2013-10-23 23:27

相应地修改应用程序的代码，如代码清单9所示，

john jiang 2013-10-07 16:55

john jiang 2013-09-21 19:11

john jiang 2013-08-22 14:43

john jiang 2013-08-02 11:50

john jiang 2013-07-14 11:15