2008-04-30

instance holder原理和plug-in平台的思考

关键字: plugin plug-in
看这个代码:
String str2;
do{
String str1 = new String("abc");
str2 = new String("cde");
}while(false);
String str3 = str2;
出了以上代码块,str1指向的instance就没有地方hold住了,没办法操作那instance了,这个instance就消失了等待垃圾回收。
而出了以上代码块后,str2指向的instance被两个地方hold住了,一个是str2,一个是str3。
这是java简单的语法和规则。
java简单到可以只缩为“代码”,“内存”和“线程”几个概念,线程是cpu时间片的承载,代码可以通过JNI调用C library和系统调用。“instance1.method1()”中点号可以看作将执行流程和控制切换给这个instance,同时以上这句话不会模糊线程和cpu时间片的概念。
在JVM进程里,所有instance对象,都可以看作处在同一个平坦的内存中,包括你web app里的instance或被spring hold住的instance,还是tomcat本身的instance,weblogic也一样。
在JMX里注册了一个MBean,JMX能改变web app的参数,web app能接受JMX的改变要求,是因为同一个instance被两个地方hold住了。
所以JNDI, JMX, Spring等其中一个基本原理都可看作 : instance holder mechanism for connect(contact) or a container to holder instances
Java/J2EE的世界就是container的世界。

touch function: shift thread cpu time & control flow to another instance
由以上看清jvm内都是一个强关联的整体,关键是你有没有路径去寻址,有时候你只有个接口对象,但没实现类,而你需要的instance其实是被实现类 hold住的,所以你访问不到没暴露给你的东西,你没办法寻址,所以所谓“平台”通过接口将你封闭住了。如果你想设计弱关联的plug-in机制,或许可以从这个角度去想想。弱关联,只是在plug-in内部弱关联而已,你让某plugin内部代码只能通过一条路径寻址到其他plug-in的 instance,那就达到一种比较好的封装性,这条寻址路径也是受你控制的。
更具体一点是,某plugin通过一字符串lookup()到另一服务(这其中的过程是,cpu片切换到一个container去执行,container会返回另一服务的instance给你),就可以与另一服务通讯,如果某时间lookup不到就只有暂时忍忍了,要不就NullPointerException了。如果你想控制plugin间的通讯,可以在返回 instance时加个代理插一脚。如果终端instance没准备好时,平台可能会给一个dummy instance代理,让plugin干不成事,也不会出错。plugin平台肯定是要设计interface的。
与lookup()主动式概念类似,Spring或其它instance container或plugin平台会根据某些规则自动组织(注入)instance给你,对象网就是这样组织的,plugin平台就是这样组织的。
更弱关联的plugin机制是,调用与平台沟通的方法后不返回另一plugin的instance,只是由平台调用另一plugin的instance后返回执行后数据的instance,比如是XmlBus或SDO这样中间格式的instance。
以下给出一个最终化的plugin体系示意图:

OSGi也脱离不了这样的结构,可以从这个原理思考OSGi中的问题。OSGi还利用上ClassLoader机制。

request是个holder, session是个holder, servletcontext也是个holder,tomcat也是个holder,所有对象都是个holder,有reference就是holder/container
不知道tomcat context.xml中crossContext="false"是不是也可以用这个原理进行思考。
不知道JBoss 5.0从JMX微内核结构转到POJO微内核结构,是不是可以这个原理思考一下,并研究源代码充分吸收JBoss的技术。

instance是不能跨越jvm和进程的,jvm间只有通过操作系统机制和tcp port间关联

plugin平台还有个欲望是“控制”,或许有人想用AOP来控制,Spring AOP是用动态代理,在其中插入了一个代理Instance,所以是有两个Instance,所以在终端Instance内部调用本Instance其他 method时,不被拦截住。而AspectJ AOP改变了字节码,只有一个Instance
评论
发表评论

您还没有登录,请登录后发表评论

lokki
搜索本博客
我的相册
9a9ef868-20e1-3344-b179-cb1a5fa2ef6b-thumb
plugin-model
共 2 张
最近加入圈子
存档
最新评论