Java SE 6 新特性: JMX 与系统管理

　　前言

　　在 Java 程序的运行过程中，对 JVM 和系统的监测一直是 Java 开发人员在开发过程所需要的。一直以来，Java 开发人员必须通过一些底层的 JVM API，比如 JVMPI 和 JVMTI 等，才能监测 Java 程序运行过程中的 JVM 和系统的一系列情况，这种方式一直以来被人所诟病，因为这需要大量的 C 程序和 JNI 调用，开发效率十分低下。于是出现了各种不同的专门做资源管理的程序包。为了解决这个问题，Sun 公司也在其 Java SE 5 版本中，正式提出了 Java 管理扩展（Java Management Extensions，JMX）用来管理检测 Java 程序（同时 JMX 也在 J2EE 1.4 中被发布）。

　　JMX 的提出，让 JDK 中开发自检测程序成为可能，也提供了大量轻量级的检测 JVM 和运行中对象/线程的方式，从而提高了 Java 语言自己的管理监测能力。

　　JMX 和系统管理

　　管理系统（Management System）

　　要了解 JMX，我们就必须对当前的 IT 管理系统有一个初步的了解。随着企业 IT 规模的不断增长，IT 资源（IT resource）数量不断增加，IT 资源的分布也越来越分散。可以想象，甚至对于一家只有几百台 PC 公司的 IT 管理人员来说，分发一个安全补丁并且保证其在每台 PC 上的安装，如果只依赖人工来完成那简直就是一场噩梦。这样，IT 管理系统就应运而生。

　　然而，CPU、网卡、存储阵列是 IT 资源；OS、MS Office、Oracle database、IBM Websphere 也是 IT 资源。IT 管理系统若要对这些 IT 资源进行管理，就必须对这些管理对象有所了解：形形色色的 IT 资源就像是说着不同语言的人：Oralce 数据库表达内存紧张的方式和 Window XP 是绝然不同的， 而 IT 管理系统就像建造通天塔的经理，必须精通所有的语言， 这几乎是一个不可能完成的任务。难道 IT 管理系统是另外一个通天塔吗？当然不是！其实我们只要给每个 IT 资源配个翻译就可以了。

　　管理系统的构架

图 1. 管理系统构架


　　上图分析了管理系统的基本构架模式。其中 Agent / SubAgent 起到的就是翻译的作用：把 IT 资源报告的消息以管理系统能理解的方式传送出去。

　　也许读者有会问，为什么需要 Agent 和 SubAgent 两层体系呢？这里有两个现实的原因：

1. 管理系统一般是一个中央控制的控制软件，而 SubAgent 直接监控一些资源，往往和这些资源分布在同一物理位置。当这些 SubAgent 把状态信息传输到管理系统或者传达管理系统的控制指令的时候，需要提供一些网络传输的功能。
2. 管理系统的消息是有一定规范的，消息的翻译本身是件复杂而枯燥的事情。

　　一般来说，管理系统会将同一物理分布或者功能类似的 SubAgent 分组成一组，由一个共用的 Agent 加以管理。在这个 Agent 里封装了 1 和 2 的功能。

　　JMX 和管理系统

　　JMX 既是 Java 管理系统的一个标准，一个规范，也是一个接口，一个框架。图 2 展示了 JMX 的基本架构。

图 2. JMX 构架


　　和其它的资源系统一样，JMX 是管理系统和资源之间的一个接口，它定义了管理系统和资源之间交互的标准。>javax.management.MBeanServer 实现了 Agent 的功能，以标准的方式给出了管理系统访问 JMX 框架的接口。而 >javax.management.MBeans 实现了 SubAgent 的功能，以标准的方式给出了 JMX 框架访问资源的接口。而从类库的层次上看，JMX 包括了核心类库 >java.lang.management 和 >javax.management 包。>java.lang.management 包提供了基本的 VM 监控功能，而 >javax.management 包则向用户提供了扩展功能。

　　JMX 的基本框架

　　JMX 使用了 Java Bean 模式来传递信息。一般说来，JMX 使用有名的 MBean，其内部包含了数据信息，这些信息可能是：应用程序配置信息、模块信息、系统信息、统计信息等。另外，MBean 也可以设立可读写的属性、直接操作某些函数甚至启动 MBean 可发送的 notification 等。MBean 包括 Standard，MXBean，Dynamic，Model，Open 等几种分类，其中最简单是标准 MBean 和 MXBean，而我们使用得最多的也是这两种。MXBean 主要是 >java.lang.management 使用较多，将在下一节中介绍。我们先了解其他一些重要的 MBean 的种类。

　　标准 MBean

　　标准 MBean 是最简单的一类 MBean，与动态 Bean 不同，它并不实现 >javax.management 包中的特殊的接口。说它是标准 MBean， 是因为其向外部公开其接口的方法和普通的 Java Bean 相同，是通过 lexical，或者说 coding convention 进行的。下面我们就用一个例子来展现，如何实现一个标准 MBean 来监控某个服务器 ServerImpl 状态的。ServerImpl 代表了用来演示的某个 Server 的实现：

package standardbeans; 

public class ServerImpl { 

    public final long startTime; 

    public ServerImpl() { 

        startTime = System.currentTimeMillis(); 

    } 

} 

　　然后，我们打算使用一个标准 MBean，ServerMonitor 来监控 ServerImpl：

package standardbeans; 

public class ServerMonitor implements ServerMonitorMBean { 

    private final ServerImpl target; 

    public ServerMonitor(ServerImpl target){ 

        this.target = target; 

    } 

    public long getUpTime(){ 

        return System.currentTimeMillis() - target.startTime; 

    } 

} 

　　这里的 ServerMonitorBean 又是怎么回事呢？MXBean 规定了标准 MBean 也要实现一个接口，所有向外界公开的方法都要在这个接口中声明。否则，管理系统就不能从中获得相应的信息。此外，该接口的名字也有一定的规范：即在标准 MBean 类名之后加上“MBean”后缀。若 MBean 的类名叫做 MBeansName 的话，对应的接口就要叫做 MBeansNameMBean。

　　对于管理系统来说，这些在 MBean 中公开的方法，最终会被 JMX 转化成属性（Attribute）、监听（Listener）和调用（Invoke）的概念。如果读者对 Java Bean 有一些了解的话，不难看出，>public long getUpTime() 对应了 Bean 中的一个称为“upTime”的只读属性。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有