背景
前几节分析了Tomcat中跟JMX有关的内容,昨天继续分析了JMX的架构图,以及JVM启动JMX的流程,整理出JDK中相关的类图,以巩固对JMX的理解。
架构图
sun公司定义的JMX架构图,百来的图片如下:
纵观上图,以虚线分割,分为三层:
第一层,远程管理层应用,即访问JMX的应用,如jconsole.exe,snmp等。
第二层,JMX代理层,核心层,它是连接第一层和第三层的枢纽。
第三层,资源植入层,即定义资源,并向代理层注册MBean。
类图分析
在开启Tomcat的JMX之后,跟踪到JDK启动JMX是通过Agent.startAgent()方法完成的,以此进行源码分析,得到相关的类图如下:
类图底部中的RIMConnector即架构图第一层中的Connector的具体实现。
启动流程
整理startRemoteConnectorServer()方法的调用流程,绘制出启动时序图如下:
关联分析
结合类图和时序图来看,我们可以得到一些信息如下:
第一,JMX启动的第二步getPlatformMBeanServer(),它创建一个MBeanServer对象,而该对象作为参数传递给了JMXConnectorServer,赋值给后者的成员变量了。这就提供了JMXConnectorServer操作MBean时依赖的MBeanServer对象了。
第二,此时我们再结合tomcat那一节的注册流程来看,Registry类获取MBeanServer的源码如下:
public synchronized MBeanServer getMBeanServer() {
long t1=System.currentTimeMillis();
if (server == null) {
if( MBeanServerFactory.findMBeanServer(null).size() > 0 ) {
server = MBeanServerFactory.findMBeanServer(null).get(0);
if( log.isDebugEnabled() ) {
log.debug("Using existing MBeanServer " + (System.currentTimeMillis() - t1 ));
}
} else {
server = ManagementFactory.getPlatformMBeanServer();
if( log.isDebugEnabled() ) {
log.debug("Creating MBeanServer"+ (System.currentTimeMillis() - t1 ));
}
}
}
return (server);
}
我们注意到,这里先调用的是MBeanServerFactory.findMBeanServer即先从MBeanServer工厂维护的实例列表中查找是否已经创建了MBeanServer,如果有直接获取该对象。
第三,第一步中JMX启动时率先调用了一次getPlatformMBeanServer(),所以工厂类的实例列表中已经缓存了一个MBeanServer对象了,那么第二步Tomcat在注册MBean时使用的,跟第一步创建的是同一个MBeanServer对象。
第四,再来看JMX的三层结构图,此时Connector和Agent,MBean注册,使用的是同一个MBeanServer对象,这样Agent代理层就成功实现了衔接功能。
启示录
还是相同的感悟,JDK源码博大精深,这里不过是浅尝辄止,管中窥豹,取其精华一二。那个类图给了我几点启示:
首先,抽象层中的依赖类型必定是抽象类型,例如:接口JMXConnectorServerProvider类依赖的是JMXConnectorServer抽象类型,而他们的实现类依赖的是具体的子类,即ServerProvider依赖的是RMIConnectorServer。
这一点跟Java面向抽象编程的规范是一致的,也比较容易理解。在其他内容分析中也发现了这一点。
其次,利用工厂创建JMXConnectorServer实例,ConnectorBootstrap通过MBeanServerFactory和JMXConnectorServerFactory两个工厂来获取所依赖的实例对象。工厂模式在JDK和tomcat源码中很常见,但是什么样的实体应该提供工厂呢?这个我再思考思考。