windows下如何正確使用Jconsole遠程連接linux主機上的JVM

背景說明：

客戶端： Windows XP SP3，JDK 1.5.0_14；服務端：CentOS 5.4 Final（Rad Hat版本：5.1.19.6，linux核心：2.6.18-164.el5），JDK 1.6.0_21 for linux。

開始時，在Windows環境下，使用“jconsole”，連接CentOS下的一個Java服務，在命令行連續不斷的拋出以下異常信息：

  

經過一系列不堪回首的漫長過程，發現這個問題可能是jconsole的bug，而此bug已經在sun的bug Report中列出來了，而且，目前此bug的狀態：     State     11-Closed, Not a Defect, bug。關於此bug的具體信息請參考：?bug_id=6209663

此時，使用linux的“hostname -i”命令查看，發現當前服務器的hostname為：127.0.0.1，使用“hostname newhosename”修改成實際的IP地址，仍然不能解決上述問題。

針對此bug，也有不少高手們提出了相應的解決方案，具體方案列表如下：（以下6條摘自：）

使用JCONSOLE監控遠程LINUX運行的JAVA進程，總是在報連接失敗的錯誤。
1)被監控的服務器端增加啟動參數

-Dcom.sun.management.jmxremote.port=8999
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false

2)本機上使用jconsole連接遠程的8999端口
報連接失敗，檢查網絡情況，8999端口有在監聽等待，本地機器能夠連接上對端機器的8999端口。切換了一台linux機器，情況依舊。

3)去網上找了一把，發現一個網友一年多前也在為此苦惱，所不同的是網友用的是JDK1.5，我用的是JDK 1.6。該網文鏈接如下：
（發現已經不可用）

4)嘗試抓包分析，發現是RMI的二進制協議，無法解讀，報文中有127.0.0.1等字眼，從關鍵字判斷是RMI下載的STUB文件。

5)繼續查找，發現了一篇有價值的文章談到這個問題，是服務器端解釋機器名的問題，如果服務器端hostname -i被定向到127.0.0.1則會出現連接失敗的問題。修改/etc/hosts文件，使hostname -i 指向正確的IP，JConsole終於可以正常連接。
這篇文章鏈接如下：
?bug_id=6209663

6)可能的問題原因分析：JCONSOLE連接上監控的進程，從監控進程下載了RMI遠程調用的STUB文件？該STUB訪問服務器的進程，
服務器端的地址可能是通過hostname -i類似機制獲得。

綜合上述方案，修改liunx下的hosts文件，相對簡單，於是，修改/etc/hosts文件，將其第一行的“127.0.0.1  localhost.localdomain localhost”，修改為：“192.168.1.234  localhost.localdomain localhost”，其中，“192.168.1.234”為實際的服務器的IP地址。

重啟linux，此時，在終端中輸入“hosename -i”，結果為實際設置的IP地址，這裡是192.168.1.234。再次使用jconsole連接此linux服務器，OK，一切正常，久違的JConsole圖形界面顯示出來。

另外，上述第一條中的“8999”為實際的需要監控的java服務的端口號。

但是，在實際情況下，第一條貌似不怎麼管用，添加完第一條的參數後，應用服務器起不來了。

又找到另外一篇文章（出處：?uid-113838-action-viewspace-itemid-132703）：