在Plumbr，我們花了最后一個月的時間來為將來的重大改進奠定基礎。 此類構件之一是為JVM添加唯一標識符，以便將來自同一JVM的所有會話鏈接在一起。

雖然一開始看起來似乎很瑣碎的任務，但是當查看JVM捆綁的jps命令的輸出時，圍繞該問題的復雜性開始令人頭疼，該命令列出了我的機器中所有當前正在運行的Java進程：

My Precious:tmp my$ jps 1277 start.jar 1318 Jps 1166

上面列出了jps命令的輸出，列出了我的機器上當前正在運行的所有Java進程。 如果您不熟悉該工具，則它會在左側列出所有進程的進程ID，并在右欄中列出進程名稱。 顯然，唯一一個以有意義的名稱列出自己的人就是jps本身。 另外兩個不太禮貌。 隱藏在start.jar首字母縮寫后面的是Jetty實例，而完全匿名的實際上是Eclipse。 我的意思是，真的– Java世界上最大的IDE甚至不愿意在標準Java工具中用名稱列出自己嗎？

因此，一窺內置工具的最新技術，就可以回到我們手頭的要求上。 我們當前的解決方案是通過進程ID +計算機名稱組合來標識JVM。 這有一個明顯的缺點–每當進程死掉時，它的輪回就不會從內核獲得相同的ID。 因此，每當JVM Plumbr監視的監視重新啟動或終止時，我們都會失去跟蹤，無法將后續調用綁定在一起。 對于監視工具來說，這顯然不是合理的行為，因此我們繼續尋找更好的解決方案。

接下來的明顯步驟是三個月前，當時我們允許用戶通過-Dplumbr.application.name = my-precious-jvm啟動參數指定計算機的名稱。 看起來似乎很明智，但在這三個月中，只有2％的用戶實際上不愿意指定此參數。 因此，現在該回到繪圖板上，看看在嘗試將唯一且易于理解的標識符自動綁定到JVM實例時，我們有哪些選擇。

我們的第一種方法是使用main（）方法獲取類的名稱，并將其用作標識符。 當我們在包含四個不同Jetty實例的開發箱中啟動構建時，立即出現的弊端很快就會顯現出來–您立即擁有四個不同的JVM，它們都在相同的但不太唯一的標識符下進行綁定。

下一個嘗試是解析應用程序的內容并從部署描述符中識別應用程序–畢竟， Plumbr監視的大多數應用程序都打包為WAR / EAR捆綁軟件，因此這將是有意義的，并使用捆綁軟件中存在的信息。 實際上，絕大多數工程師的確在web.xml或application.xml的<display-name>參數中給出了有意義的名稱。

這解決了部分問題–當所有四個Jetty實例都運行具有不同<display-name>的應用程序時，它們將顯示為唯一。 確實如此，直到我們的登臺環境表明情況并非總是如此。 我們在同一臺計算機上有幾個不同的Plumbr Server實例，它們使用不同的應用程序服務器，但是使用相同的<display-name>參數部署相同的WAR文件。 您可能會猜到，這再次扼殺了此類ID的唯一性。

另一個引起問題的事實是，有一些應用程序服務器正在運行多個Web應用程序-將多個WAR文件部署到容器中后會發生什么？

因此，我們不得不進一步挖掘。 為了區分在同一臺機器上運行同一應用程序的多個JVM，我們添加了啟動文件夾以保證標識符的唯一性。 但是多重戰爭的問題仍然存在。 為此，我們回到了最初的假設，即使用主類名稱作為標識符。

還有一些技術上的細微差別，例如區分用于ID的實際哈希和同一哈希的用戶友好版本，現在，我們提供了一種解決方案，它將在您監視的JVM列表中顯示類似的內容：

機 虛擬機 由于

青蒿素分期	自助服務（WAR）	2014年7月7日11:45
青蒿素分期	網上商店（WAR）	2014年8月7日18:30
芳綸	com.ringbearer.BatchProcessor	01.01.2001 00:00

因此，實際上，我們能夠提出一個不錯的解決方案，并在其他所有方法均失敗的情況下使用-Dplumbr.application.name參數進行手動命名。 仍然存在一個問題–為什么JVM工具和API完全缺少系統管理員通常需要的東西？

翻譯自: https://www.javacodegeeks.com/2014/07/identifying-jvm-trickier-than-expected.html

總結

以上是生活随笔為你收集整理的识别JVM –比预期的要复杂的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。