介紹

我決定結合我的兩個軟件愛好，并在PCGen上進行一些分析， PCGen是一種流行的基于Java的開放源代碼角色生成器，用于角色扮演游戲。 我用Censum ，我們（ jClarity的）新的垃圾收集日志分析工具來進行分析。

本文假定您對JVM上的垃圾回收（GC）有所了解。 如果您不熟悉GC，那么建議您加入我們的jClarity朋友計劃 。 我們正在建立有關GC的知識庫，以便與整個Java社區自由共享，我們非常希望您能對此進行驗證！

項目

我正在使用的兩個項目是PCGen（我正在對其進行分析的項目）和Censum（GC分析工具）。

PCGen

PCGen是針對d20角色扮演系統（例如《星球大戰》和《龍與地下城》）的流行角色生成器和維護程序。 這是一個長期運行的項目（> 10年），由一個大型（約750,000 LOC）Java Swing桌面工具組成，該工具具有大量專有格式的數據文件。 免責聲明：我是PCGen的主席。

PCGen是一個數據密集型工具。 為了驅動其規則引擎并滿足響應式UI的要求（具有大量詳細信息），許多此類數據已預先加載并保存在內存中。 用戶過去曾報告以下問題。

在處理多個字符和/或高級字符時，經常會出現暫停。

創建高級別角色或創建的角色超過2個時，PCGen就會死亡。 更多精通技術的用戶報告說，他們在pcgen日志文件中看到OutOfMemoryError。

為了減輕PCGen（6.0）最新版本中的這種不良性能，已經做了一些工作，因此我決定使用Censum來確定這些更改是否改善了性能。

森森

Censum是jClarity的新垃圾收集分析工具。 重點是使用功能強大的分析來處理原始日志數據，并為繁忙的開發人員（例如PCGen！的貢獻者）快速提供簡單的英語答案。 免責聲明：我是jClarity的CTO。

Censum是一項對開放源代碼項目免費的新產品，當然，如果您要購買副本，今天就可以獲得免費的評估許可證 （單擊Try Censum ）！

TLDR –結論

我們有好消息，一些信息和壞消息。

好消息

積極的消息是，PCGen開頭的默認堆設置（-Xms256m -Xmx512m）現在足夠大小，足以保持PCGen的運行。 即使創建了第5個復雜字符，也沒有OutOfMemoryError。

Censum顯示，一旦運行了完整的GC（通常在創建了每個新字符之后），便會恢復很大一部分堆，并且每個字符占用大約25-50 MB的堆空間。 我們可以粗略地推斷出，起始點（已加載數據）約為125MB，PCGen可以隨時輕松地保持大約10-15個字符打開而不會崩潰。 對于一個總經理來說，這可能還不足以讓他的哥布林部落開始運轉，但是對于大多數常規聚會而言，這當然足夠了！

壞消息

負面消息稍多的是Censum報告，PCGen的暫停時間相對較高，很可能是由于過早晉升而引起的。 提早升級過多會導致我們想要的存儲速度更快地進入舊一代。 這可能會產生連鎖反應，導致收集更多舊的基因組以及完整的GC，自然導致更長的停頓時間。 有關高暫停時間，過早升級以及PCGen可以做什么的更多詳細信息，請參見完整的分析部分。

從這里到哪里？

PCGen可以遵循Censum的“權宜之計”建議，以改變年輕一代空間的大小。 通過使用-XX：NewSize標志并將其設置為?256M，可以緩解高暫停時間的問題。

但是，PCGen的長期解決方案是繼續減少其數據結構（特別是玩家角色的表示）的影響。 實際上，這是PCGen今天正在進行的項目！

技術設置

PCGen通常從具有默認堆設置-Xms256m和-Xmx512m的Shell腳本運行。 對該腳本進行了更改，以提供產生可分析的GC日志所需的最少標志集。 添加到java命令的標志是：

-verbose：gc -Xloggc：pcgen_gc.log -XX：+ PrintGCDetails -XX：+ PrintTenuringDistribution

• -verbose：gc和-Xloggc：pcgen_gc.log生成基本日志，該日志輸出到名為pcgen_gc.log的文件。
• -XX：+ PrintGCDetails提供Censum執行分析所需的GC分配信息的絕對最小集。
• 最后，-XX：+ PrintTenuringDistribution提供有關對象何時從年輕的世代空間（伊甸園，幸存者1和幸存者2）移動到舊世代空間（使用期限）的有用信息。

所有這些選項對正在運行的JVM幾乎沒有影響。 您應該始終在生產中啟用這些功能！

PCGen在運行Mac OS 10.7.5的MBP上與Oracle Java 7u10一起運行，具有8GB RAM，256MB SSD驅動器和超線程雙核2.8Ghz i7處理器。

PCGen活動

PCGen首先加載基本游戲模式和系統文件+基本UI來加載數據源。 下一步是讓用戶選擇要加載的數據源（角色扮演游戲規則集）。 裝有“怪獸”套裝的流行SRD 3.5 （地牢和巨龍3.5e）已加載。

一個角色（ Karianna ）被逐級創建到第20個巫師中，該巫師具有滿載的咒語，設備和熟悉的貓（在PCGen中實際上是第2個角色）。 此后添加了幾個更復雜的角色，包括大龍藍龍（大量數據！）。

分析

我將介紹最初的數據加載用例，然后介紹常規用法（創建字符）。

資料載入

我很好奇初始數據加載對內存的影響。 盡管使用具有PCGen的SSD驅動器可以縮短加載時間，但毫無疑問，這是項目目標！ 這是Censum在GC之后在堆分配方面顯示的內容。

如您所見，數據的初始加載在數據加載結束時導致了許多年輕的世代集合和一個舊的（永久的）GC事件。 堆使用率最高可攀升至約325MB，但在收集垃圾后，堆使用率又降至約100MB。 加載大約15本厚規則書的數據還不錯！

但是，PCGen的數據加載有點像Web /應用程序服務器（例如Tomcat）的啟動期。 就您的GC分析而言，通常最好將其排除在一次性啟動之外，而不是分析正在運行的應用程序。

創建角色

創建Karianna并將她提升到20級需要填寫13個主選項卡的詳細信息?20個子選項卡和大量數據！ 還創建了另外4個字符，它們具有相似的復雜性，其中一些友好（貓很熟悉），而有些則不友好（大龍藍龍）。

該過程的一些屏幕截圖如下：

技能專長

設備

嵌入式字符表

Censum的分析

打開日志文件后，Censum立刻將我帶到了“分析摘要”屏幕，該屏幕使我一目了然地了解了PCGen的垃圾回收的進行情況。

好消息

我立即知道：

我有正確的標志來收集足夠的GC數據以進行分析以使其正常工作

我的GC吞吐量很好（PCGen花費時間在運行，而不是在進行垃圾收集）

沒有討厭
System.gc（）調用（通常不是很好的做法）。

信息新聞

內存利用率 （內存泄漏是其中的一個子集）和內存池大小是信息性的，因為日志尚未收集24小時的數據（建議的最小值是查看應用程序一個完整工作日的周期）。

壞消息

PCGen似乎具有高的暫停時間以及過早的升級問題。 讓我們進一步深入探討！

高暫停時間

高暫停時間是由于GC收集器必須暫停應用程序線程才能以安全的方式清理對象引用所致。 收集器必須掃描和清理的對象引用越多，暫停時間就越長！ 最長的停頓通常是由完整的GC集合引起的，其中清理了整個Java堆（例如，年輕一代和老一代的空間都變得很滿）。

作為一個用戶，我注意到停頓了兩次，還不足以真正打擾我，但我知道我的硬件非常好，而且這些停頓時間對于其他用戶而言可能會更糟。

正如Censum指出的那樣，暫停所花費的時間的0.15％并不是主要的問題，而是所關心的0.666秒的暫停時間。 但是，我記得最長的暫停時間可能來自PCGen中的初始數據加載。 為了與此相關，Censum提供了一張暫停時間圖。

數據加載是最嚴重的違法行為，但是肯定的是，由于GC已滿，因此對于每個創建的角色，每個角色創建點周圍都有?秒的良好暫停。 在使用PCGen的情況下，再說一秒鐘對我來說并不令人討厭，但是正如Censum所示，完整的GC需要時間，因此PCGen應該減少完整的GC的數量。

在這種情況下，我們知道由于Censum給我們的另一個警告–提早升級，我們可能會得到比我們想要的更多的完整GC。

提早促銷

提早提倡本質上是指應該在年輕一代空間中收集的對象在年齡增長之前就被提升到老一代空間中。 這個“年齡”被稱為任職期限，它基于1980年代進行的軟件研究和JVM的運行時啟發式算法的結合。 由于以下原因，可能會提早升職：

創造新物體的速度淹沒了年輕一代的空間

正在創建的對象太大，無法容納年輕的一代空間。 例如大的連續內存塊。

這具有對舊的發電空間施加壓力的效果。 它的填充速度更快，因此會收集更多的舊基因組并最終出現完整的GC，從而導致更頻繁的暫停時間。

當我去看看應該提升對象多長時間以及它們被提升多早時，我立即得到了答案。 “任期摘要”屏幕向我們顯示了“任期閾值”設置為15（對象可以在年輕一代中存活約15個集合，然后自然提升為老一代）。 另請注意，過早地提升了100％的對象！

然后，我去看看何時提升對象。 Censum告訴我，大多數人幾乎是在年輕一代就開始晉升的（Tenuring Threshold為1）。 該值向我表明，到達的對象對于當前的年輕一代而言太大。 但是，我仔細檢查并確保對象分配不是很高，Censum告訴我，對象分配的峰值約為2.5GB / s，這僅是大約？ 我的MBP的功能，所以我們可以了。

PCGen采取的步驟

PCGen團隊的下一步將是查看jmap中的直方圖之類的內容，以查看正在創建哪些大對象。 快速檢查jmap輸出意味著我知道我們有String（字符串），char和byte的大型（多MB）連續數組。

此時PCGen的一個選項是調整年輕一代空間的大小，以便使用
-XX：NewRatio或-XX：NewSize標志。 設置這兩個值之一的大小將取決于從jmap用法中發現的結果。 在這種情況下，需要將-XX：NewSize設置為?256M，以減少暫停次數。

但是，通常這不是一個很好的長期解決方案。 PCGen項目最好減少這些大的連續內存分配的使用。 由湯姆·帕克（Tom Parker）和詹姆斯·登普西（James Dempsey）領導，這正是PCGen團隊正在做的事情，將龐大的內存結構從整體式的PlayerCharacter類中提取到了更靈活的較小方面。

摘要

令人驚奇的是，PCGen志愿者為6.0版本付出的辛勤工作為最終用戶帶來了實實在在的紅利！

幾年前，我追蹤了PCGen用戶在加載第25級Kobold Shaman時報告的30秒以上的暫停。 我花了幾天的時間才發現這是一個GC /內存問題，因為我只有原始的GC日志文件（它們是多線程的，不確定的野獸）。 展望未來，我肯定會使用像Censum這樣的工具來更快地解決這些問題，這意味著我可以繼續為PCGen添加新功能！

如果您想解決棘手的GC問題，請不要忘記查看PCGen來滿足d20角色扮演游戲的需求和Censum ！

參考：來自我們的JCG合作伙伴 Martijn Verburg 的PCGen垃圾收集分析，網址為Are We There Yet博客。

翻譯自: https://www.javacodegeeks.com/2013/01/garbage-collection-analysis-of-pcgen.html

總結

以上是生活随笔為你收集整理的PCGen的垃圾收集分析的全部內容，希望文章能夠幫你解決所遇到的問題。

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