Monthly Archives: August 2013

中间件开发:不要阻塞I/O线程

当某块逻辑出现问题,导致程序阻塞时,可能会导致以下两种情况之一:

1. 如果这块逻辑由中间件的I/O线程负责处理,那么会导致I/O线程处理

2. 如果这块逻辑不是由I/O线程负责处理,则bla bla

一定要避免第一种情况。虽然对这块逻辑来说,两种选项都是程序被阻塞,业务未被处理;但在第二种选项中,指向其他健康逻辑的请求还是可以被中间件所接受请工作。 在第一种选项中,极端情况下所有I/O线程都被会被阻塞,导致指向其他健康逻辑的请求都进不来,整个系统彻底不可用。

所以,I/O线程一般不要用来处理业务逻辑。 业务逻辑应该交由专门的线程池来处理。

谁打开了流,谁就应该负责关闭这个流

谁打开了流,谁就应该负责关闭这个流。

理由一

在现实系统中,打开流、关闭流的动作可能并不仅是一次open(), close()调用,可能还包括记日志、通知相关模块等附加动作,而这些动作在open/close时往往还是对称的,也就是说,在open()时做一些附加动作,在close()时可能会作一些类似的或反向的附加动作。

既然这些附加动作是对称的,那它们最好放在一个类里;反推过来,open和close调用最好也放在同一个类里。

理由二

待想。。。

关于SPI

这里有个
精准的定义
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完成工作