instance holder原理和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