Java 6 中的 API 改进
Management 在 Java SE 5 被提出之后，受到了欢迎。在 Java 6 当中，这个包提供更多的 API 来更好地提供信息。
OperatingSystemMXBean. getSystemLoadAverage()
Java 程序通常关注是虚拟机内部的负载、内存等状况，而不考虑整个系统的状况。但是很多情况下，Java 程序在运行过程中，整个计算机系统的系统负荷情况也会对虚拟机造成一定的影响。随着 Java 的发展，Java 程序已经覆盖了各个行业，这一点也必须得到关注。在以前，利用 Native 代码来检测系统负载往往是唯一的选择，但是在 Java 6 当中，JDK 自己提供了一个轻量级的系统负载检测 API，即 OperatingSystemMXBean.getSystemLoadAverage()。
当然这个 API 事实上仅仅返回一个对前一分钟系统负载的简单的估测。它设计的主要目标是简单快速地估测当前系统负荷，因此它首先保证了这个 API 的效率是非常高的;也因为如此，这个 API 事实上并不适用于所有的系统。
锁检测
我们知道，同步是 Java 语言很重要的一个特性。在 Java SE 中，最主要的同步机制是依靠 synchronize 关键字对某一个对象加锁实现的;在 Java SE 5 之后的版本中，concurrent 包的加入，大大强化了 Java 语言的同步能力，concurrent 提供了很多不同类型的锁机制可供扩展。因此，要更好地观测当前的虚拟机状况和不同线程的运行态，去观察虚拟机中的各种锁，以及线程与锁的关系是非常必要的。很可惜的是，在过去的 JDK 中，我们并没有非常方便的 API 以供使用。一个比较直接的检测方式是查看线程的 stack trace，更为强大全面(但是也更复杂并且效率低下)的方案是得到一个 VM 所有对象的快照并查找之，这些策略的代价都比较大，而且往往需要编写复杂的 Native 代码。
JDK 6 里提供了一些相当简单的 API 来提供这个服务。首先了解两个新类，LockInfo 和 MonitorInfo 这两个类承载了锁的信息。LockInfo 可以是任何的 Java 锁，包括简单 Java 锁和 java.util.concurrent 包中所使用的锁(包括 AbstractOwnableSynchronizer 和 Condition 的实现类/子类)，而 MonitorInfo 是简单的 Java 对象所代表的锁。要检测一个线程所拥有的锁和等待的锁，首先，要得到一个线程的 ThreadInfo，然后可以简单地调用：
getLockedMonitors()
返回一个所有当前线程已经掌握的锁对象的列表。
getLockedSynchronizers()
对于使用 concurrent 包的线程，返回一个该线程所掌握的“ownable synchronizer”(即 AbstractOwnableSynchronizer 及其子类)所组成的列表。
getLockInfo()
当前线程正在等待的那个锁对象的信息就可以知道线程所有的锁信息。通过这些锁信息，我们很方便的可以知道当前虚拟机的所有线程的锁信息。由此，我们还可以推导出更多的信息。
死锁检测
死锁检测一直以来是软件工程师所重视的，显然一个死锁的系统永远是工程师最大的梦魇。Java 程序的死锁检测也一直以来是 Java 程序员所头痛的。为了解决线程间死锁问题，一般都有预防(代码实现阶段)和死锁后恢复(运行时)两种方式。以前 Java 程序员都重视前者，因为在运行态再来检测和恢复系统是相当麻烦的，缺少许多必要的信息;但是，对于一些比较复杂的系统，采取后者或者运行时调试死锁信息也是非常重要的。由上面所说，现在我们已经可以知道每一个线程所拥有和等待的锁，因此要计算出当前系统中是否有死锁的线程也是可行的了。当然，Java 6 里面也提供了一个 API 来完成这个功能，即：
ThreadMXBean.findDeadlockedThreads()
这个函数的功能就是检测出当前系统中已经死锁的线程。当然，这个功能复杂，因此比较费时。基本上仅仅将之用于调试，以便对复杂系统线程调用的改进。
未来的发展
JMX 在 Java SE 5/6 中的功能已经相当强大，但是距离 Java 程序开发人员的要求还是有一段距离，因此 Sun 公司已经向 JCP 提出了 JSR 255 (JMX API 2.0 版本)来扩充和进一步发展 JMX，并希望这个 JSR 将在 Java SE 7 中实现。在这个文档中，新的 JMX 2.0 将着重于：
对 management 模型的优化，并提供更好的支持;加入了比如 annotation 等等的新特性;
对 JMX 定义的优化，在进一步强化 MBean 扩充性好的优点的同时，尽量改变(用户普遍认为的)MBean 很难实现的缺点;
对非 Java 平台客户端的支持。这将是一个令人振奋的新特性;
具体的扩展可能包括：
层次性的命名域(Hierarchical namespace);
新的事件服务功能;
对 locales 的新支持;
为 MBean 启用 annotation 服务;
也可以使用用户类型的 mapping 了;
可以看到，JMX 的进一步发展主要关注的是可扩展性、动态性和易用性等 Java 用户非常关注的方面。
总结
在 Java SE 5 出现的 JMX 在 Java SE 6 中有了更多的功能和扩展能力，这很好地适应了 Java 语言的发展和用户的要求，让 Java 的监测、管理的的功能更加强大。
