前言
在 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 兩層體系呢?這裡有兩個現實的原因:
一般來說,治理系統會將同一物理分布或者功能類似的 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(); } }
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; } }
package standardbeans; import javax.management.MBeanServer; import javax.management.MBeanServerFactory; import javax.management.ObjectName; public class Main { private static ObjectName objectName ; private static MBeanServer mBeanServer; public static void main(String[] args) throws Exception{ init(); manage(); } private static void init() throws Exception{ ServerImpl serverImpl = new ServerImpl(); ServerMonitor serverMonitor = new ServerMonitor(serverImpl); mBeanServer = MBeanServerFactory.createMBeanServer(); objectName = new ObjectName("objectName:id=ServerMonitor1"); mBeanServer.registerMBean(serverMonitor,objectName); } private static void manage() throws Exception{ Long upTime = (Long) mBeanServer.getAttribute(objectName, "upTime"); System.out.println(upTime); } }
package dynamicbeans; import javax.management.*; import java.lang.reflect.*; public class ServerMonitor implements DynamicMBean { private final ServerImpl target; private MBeanInfo mBeanInfo; public ServerMonitor(ServerImpl target){ this.target = target; } //實現獲取被治理的 ServerImpl 的 upTime public long upTime(){ return System.currentTimeMillis() - target.startTime; } //javax.management.MBeanServer 會通過查詢 getAttribute("Uptime") 獲得 "Uptime" 屬性值 public Object getAttribute(String attribute) throws AttributeNotFoundException, MBeanException, ReflectionException { if(attribute.equals("UpTime")){ return upTime(); } return null; } //給出 ServerMonitor 的元信息。 public MBeanInfo getMBeanInfo() { if (mBeanInfo == null) { try { Class cls = this.getClass(); //用反射獲得 "upTime" 屬性的讀方法 Method readMethod = cls.getMethod("upTime", new Class[0]); //用反射獲得構造方法 ConstrUCtor constructor = cls.getConstructor(new Class[] {ServerImpl.class}); //關於 "upTime" 屬性的元信息:名稱為 UpTime,只讀屬性(沒有寫方法)。 MBeanAttributeInfo upTimeMBeanAttributeInfo = new MBeanAttributeInfo( "UpTime", "The time span since server start", readMethod, null); //關於構造函數的元信息 MBeanConstructorInfo mBeanConstructorInfo = new MBeanConstructorInfo( "Constructor for ServerMonitor", constructor); //ServerMonitor 的元信息,為了簡單起見,在這個例子裡, //沒有提供 invocation 以及 listener 方面的元信息 mBeanInfo = new MBeanInfo(cls.getName(), "Monitor that controls the server", new MBeanAttributeInfo[] { upTimeMBeanAttributeInfo }, new MBeanConstructorInfo[] { mBeanConstructorInfo }, null, null); } catch (Exception e) { throw new Error(e); } } return mBeanInfo; } public AttributeList getAttributes(String[] arg0) { return null; } public Object invoke(String arg0, Object[] arg1, String[] arg2) throws MBeanException, ReflectionException { return null; } public void setAttribute(Attribute arg0) throws AttributeNotFoundException, InvalidAttributeValueException, MBeanException, ReflectionException { return; } public AttributeList setAttributes(AttributeList arg0) { return null; } }
其它動態 MBean
另外還有兩類 MBean:Open MBean 和 Model MBean。實際上它們也都是動態 MBean。
Open MBean 與其它動態 MBean 的唯一區別在於,前者對其公開接口的參數和返回值有所限制 —— 只能是基本類型或者 >javax.management.openmbean 包內的 ArrayType、CompositeType、TarbularType 等類型。這主要是考慮到治理系統的分布,很可能遠端治理系統甚至 MBServer 層都不具有 MBean 接口中非凡的類。
Model Bean
然而,普通的動態 Bean 通常缺乏一些治理系統所需要的支持:比如持久化 MBean 的狀態、日志記錄、緩存等等。假如讓用戶去一一實現這些功能確實是件枯燥無聊的工作。為了減輕用戶的負擔,JMX 提供商都會提供不同的 ModelBean 實現。其中有一個接口是 Java 規范中規定所有廠商必須實現的::>javax.management.modelmbean.RequiredModelBean。通過配置 Descriptor 信息,我們可以定制這個 Model Bean, 指定哪些 MBean 狀態需要記入日志、如何記錄以及是否緩存某些屬性、緩存多久等等。這裡,我們以 RequiredModelBean 為例討論 ModelBean。比如,我們先來看一個例子,首先是 server 端:
package modelmbean; public class Server { private long startTime; public Server() { } public int start(){ startTime = System.currentTimeMillis(); return 0; } public long getUpTime(){ return System.currentTimeMillis() - startTime; } }
package modelmbean; import javax.management.*; import javax.management.modelmbean.*; public class Main { public static void main(String[] args) throws Exception{ MBeanServer mBeanServer = MBeanServerFactory.createMBeanServer(); RequiredModelMBean serverMBean = (RequiredModelMBean) mBeanServer.instantiate( "javax.management.modelmbean.RequiredModelMBean"); ObjectName serverMBeanName = new ObjectName("server: id=Server"); serverMBean.setModelMBeanInfo(getModelMBeanInfoForServer(serverMBeanName)); Server server = new Server(); serverMBean.setManagedResource(server, "ObjectReference"); ObjectInstance registeredServerMBean = mBeanServer.registerMBean((Object) serverMBean, serverMBeanName); serverMBean.invoke("start",null, null); Thread.sleep(1000); System.out.println(serverMBean.getAttribute("upTime")); Thread.sleep(5000); System.out.println(serverMBean.getAttribute("upTime")); } private static ModelMBeanInfo getModelMBeanInfoForServer(ObjectName objectName) throws Exception{ ModelMBeanAttributeInfo[] serverAttributes = new ModelMBeanAttributeInfo[1]; Descriptor upTime = new DescriptorSupport( new String[] { "name=upTime", "descriptorType=attribute", "displayName=Server upTime", "getMethod=getUpTime", }); serverAttributes[0] = new ModelMBeanAttributeInfo( "upTime", "long", "Server upTime", true, false, false, upTime); ModelMBeanOperationInfo[] serverOperations = new ModelMBeanOperationInfo[2]; Descriptor getUpTimeDesc = new DescriptorSupport( new String[] { "name=getUpTime", "descriptorType=operation", "class=modelmbean.Server", "role=operation" }); MBeanParameterInfo[] getUpTimeParms = new MBeanParameterInfo[0]; serverOperations[0] = new ModelMBeanOperationInfo("getUpTime", "get the up time of the server", getUpTimeParms, "java.lang.Long", MBeanOperationInfo.ACTION, getUpTimeDesc); Descriptor startDesc = new DescriptorSupport( new String[] { "name=start", "descriptorType=operation", "class=modelmbean.Server", "role=operation" }); MBeanParameterInfo[] startParms = new MBeanParameterInfo[0]; serverOperations[1] = new ModelMBeanOperationInfo("start", "start(): start server", startParms, "java.lang.Integer", MBeanOperationInfo.ACTION, startDesc); ModelMBeanInfo serverMMBeanInfo = new ModelMBeanInfoSupport( "modelmbean.Server", "ModelMBean for managing an Server", serverAttributes, null, serverOperations, null); //Default strategy for the MBean. Descriptor serverDescription = new DescriptorSupport( new String[] { ("name=" + objectName), "descriptorType=mbean", ("displayName=Server"), "type=modelmbean.Server", "log=T", "logFile=serverMX.log", "currencyTimeLimit=10" }); serverMMBeanInfo.setMBeanDescriptor(serverDescription); return serverMMBeanInfo; }
唯一不同的是,ModelMBean 需要額外兩步:
1.serverMBean.setModelMBeanInfo(getModelMBeanInfoForServer(serverMBeanName)); 2.serverMBean.setManagedResource(server, "ObjectReference");
第二步指出了 ServerMBean 治理的對象,也就是說,從元數據中得到的 Method 將施加在哪個 Object 上。需要指出的是 >setManagedResource(Object o, String type); 中第二個參數是 Object 類型,可以是 "ObjectReference"、"Handle"、"IOR"、"EJBHandle" 或 "RMIReference"。目前 SE 中的實現只支持 "ObjectReference"。筆者認為後面幾種類型是為了將來 JMX 治理對象擴展而設定的,可能將來 Model Bean 不僅可以治理 Plain Java Object(POJO),還可能治理 Native Resource, 並給諸如 EJB 和 RMI 對象的治理提供更多的特性。
Model Bean 與普通動態 Bean 區別在於它的元數據類型 ModelMBeanInfo 擴展了前者的 MBeanInfo,使得 ModelMBeanOperationInfo、ModelMBeanConstructor_Info、ModelMBeanAttributeInfo 和 ModelMBeanNotificationInfo 都有一個額外的元數據:>javax.management.Descriptor,它是用來設定 Model Bean 策略的。數據的存儲是典型的 "key-value" 鍵值對。不同的 Model Bean 實現,以及不同的 MBeanFeatureInfo 支持不同的策略特性。下面我們就以 Attribute 為例,看一下 RequiredModelBean 支持的策略。
首先,它最重要的 Descriptor 主要是 name、displayName 和 descriptorType,其中 name 是屬性名稱。"name" 要與對應 ModelMBeanAttributeInfo 的 name 相同。descriptorType 必須是 "attribute"。
另外,value、default、legalValues "value" 是用來設定初始值的,"default" 指當不能從 resource 中獲得該屬性時的默認返回值,"legalValues" 是一組合法的屬性數據。它並不用來保證 setAttribute 的數據一致性,而是在 UI 系統,如 JConsole 中提示用戶可能的數據輸入。
在屬性訪問的 getMethod, setMethod 方法上,事實上所有對屬性的訪問都會被 delegate 給同一 MBeanInfo 中特定的 Operation。 getMethod/setMethod 給出了對應的 ModelMBeanOperationInfo 名稱。
還有一些額外的屬性,比如:persistPolicy, persistPeriod 是代表了持久化策略;currencyTimeLimit, lastUpdatedTimeStamp 緩存策略;iterable 屬性是否必須使用 iterate 來訪問。默認為否;protocolMap 定義了與第三方系統有關的數據轉換的 data model;visibility 定義了與第三方 UI 系統有關的 MBean 如何顯示的策略;presentationString 也是定義了與第三方 UI 系統有關的 MBean 如何顯示策略,比如 "presentation=server.gif"。
事實上,策略特性有兩個層次的作用域:整個 Model Bean 和特定的 MBeanFeature。
Model Bean 的策略描述會被施加到該 Model Bean 的所有 MBeanFeature 上去,除非該 MBeanFeature 重寫了這個策略特性。
在上面的例子裡,這一個語句:
serverMMBeanInfo.setMBeanDescriptor(serverDescription);給整個 serverMBeanInfo 設了一個策略描述 serverDescription,其中用 "currencyTimeLimit=10" 指出屬性的緩存時間是 10 秒。所以,在 Main 方法中,兩次 serverMBean.getAttribute("upTime");之間的間隔小於 10 秒就會得到同樣的緩存值。
Descriptor upTime = new DescriptorSupport( new String[] { "name=upTime", "descriptorType=attribute", "displayName=Server upTime", "getMethod=getUpTime", "currencyTimeLimit=-1" //不需要緩存 }); Descriptor getUpTimeDesc = new DescriptorSupport( new String[] { "name=getUpTime", "descriptorType=operation", "class=modelmbean.Server", "role=operation" ,"currencyTimeLimit=-1" //不需要緩存 });
java.lang.management 和虛擬機的關系
我們知道,management 和底層虛擬機的關系是非常緊密的。其實,有一些的是直接依靠虛擬機提供的公開 API 實現的,比如 JVMTI;而另外一些則不然,很大一塊都是由虛擬機底層提供某些不公開的 API / Native Code 提供的。這樣的設計方式,保證了 management 包可以提供足夠的信息,並且使這些信息的提供又有足夠的效率;也使 management 包和底層的聯系非常緊密。
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,然後可以簡單地調用:
死鎖檢測
死鎖檢測一直以來是軟件工程師所重視的,顯然一個死鎖的系統永遠是工程師最大的夢魇。Java 程序的死鎖檢測也一直以來是 Java 程序員所頭痛的。為了解決線程間死鎖問題,一般都有預防(代碼實現階段)和死鎖後恢復(運行時)兩種方式。以前 Java 程序員都重視前者,因為在運行態再來檢測和恢復系統是相當麻煩的,缺少許多必要的信息;但是,對於一些比較復雜的系統,采取後者或者運行時調試死鎖信息也是非常重要的。由上面所說,現在我們已經可以知道每一個線程所擁有和等待的鎖,因此要計算出當前系統中是否有死鎖的線程也是可行的了。當然,Java 6 裡面也提供了一個 API 來完成這個功能,即:
未來的發展
JMX 在 Java SE 5/6 中的功能已經相當強大,但是距離 Java 程序開發人員的要求還是有一段距離,因此 Sun 公司已經向 JCP 提出了 JSR 255 (JMX API 2.0 版本)來擴充和進一步發展 JMX,並希望這個 JSR 將在 Java SE 7 中實現。在這個文檔中,新的 JMX 2.0 將著重於:
具體的擴展可能包括:
可以看到,JMX 的進一步發展主要關注的是可擴展性、動態性和易用性等 Java 用戶非常關注的方面。
總結
在 Java SE 5 出現的 JMX 在 Java SE 6 中有了更多的功能和擴展能力,這很好地適應了 Java 語言的發展和用戶的要求,讓 Java 的監測、治理的的功能更加強大。