当某块逻辑出现问题，导致程序阻塞时，可能会导致以下两种情况之一： 1. 如果这块逻辑由中间件的I/O线程负责处理，那么会导致I/O线程处理 2. 如果这块逻辑不是由I/O线程负责处理，则bla bla 一定要避免第一种情况。虽然对这块逻辑来说，两种选项都是程序被阻塞，业务未被处理；但在第二种选项中，指向其他健康逻辑的请求还是可以被中间件所接受请工作。 在第一种选项中，极端情况下所有I/O线程都被会被阻塞，导致指向其他健康逻辑的请求都进不来，整个系统彻底不可用。 所以，I/O线程一般不要用来处理业务逻辑。 业务逻辑应该交由专门的线程池来处理。
谁打开了流，谁就应该负责关闭这个流。 理由一 在现实系统中，打开流、关闭流的动作可能并不仅是一次open(), close()调用，可能还包括记日志、通知相关模块等附加动作，而这些动作在open/close时往往还是对称的，也就是说，在open()时做一些附加动作，在close()时可能会作一些类似的或反向的附加动作。 既然这些附加动作是对称的，那它们最好放在一个类里；反推过来，open和close调用最好也放在同一个类里。 理由二 待想。。。
这里有个 精准的定义： http://en.wikipedia.org/wiki/Service_provider_interface spi发现机制： 1. jdk有一套以java.util.ServiceLoader为核心的机制。 ServiceLoader会从类路径查找做了相关META-INF声明的jar包，所以上层不必耦合SPI具体实现的类。 2. 其实用spring IoC搞更直观 spi跟api在语言层面的联系：有两种模式 1. spi即api，具体的类实现指定的接口。比如Tomcat的Request类实现HttpServletRequest 2. spi本身采用interface/implementation机制，接口中提供的方法直接贴近底层或者只用作工厂，不为用户所知；然后，spi接口作为api的成员变量，api在有需要时调用spi完成工作
有利于 长连接下的流式转输 摘自 http://en.wikipedia.org/wiki/Chunked_transfer_encoding 引用 Chunked encoding has the benefit that it is not necessary to generate the full content before writing the header, as it allows streaming of content as chunks and explicitly signaling the end of the content
一个很厉害的同事推荐的： 面向模式的软件体系结构 卷2：用于并发和网络化对象的模式 面向模式的软件架构.第4卷,分布式计算的模式语言
http://www.jcp.org/en/jsr/detail?id=356 Final Release: http://jcp.org/aboutJava/communityprocess/final/jsr356/index.html, 批准于22 May, 2013 并且它是JEE 7规范的一部分
http://autobahn.ws/testsuite
http://caniuse.com/
<mvc:annotation-driven> <mvc:async-support default-timeout="3000"/> </mvc:annotation-driven> 如果不配这个东西，callable里的代码会被直接忽略
[url]http://wamp.ws/ [/url] 构建在websocket之上的RPC协议和pub/sub协议