您可能從我們以前的面向性能的文章中看到，健康的JVM是實(shí)現(xiàn)最佳應(yīng)用程序性能和穩(wěn)定性的最重要目標(biāo)之一。 這樣的健康評估通常僅關(guān)注主要收集的頻率（避免）或檢測內(nèi)存泄漏的存在。 年輕一代空間或短壽命物體的大小和足跡如何？

本文基于一個(gè)真實(shí)的故事和我們與一位IT客戶的最新故障排除經(jīng)驗(yàn)。 它將通過一個(gè)示例應(yīng)用程序證明，過多的內(nèi)存占用空間和次要收集的頻率可能會引發(fā)性能問題，就像其老兄，舊一代或使用期限的空間一樣嚴(yán)重。

JVM健康狀況診斷

如果您不熟悉JVM調(diào)優(yōu)領(lǐng)域，那么您很快就會意識到，沒有適用于所有應(yīng)用程序的通用解決方案。 無論您可以從各種來源從Web上找到高質(zhì)量的材料，您仍需要進(jìn)行盡職調(diào)查并正確了解您正在處理的應(yīng)用程序類型，包括其對JVM GC暫停的敏感性（某些應(yīng)用程序需要非常較低的JVM暫停時(shí)間<1％）。

Java性能分析（包括內(nèi)存泄漏檢測）以及性能和負(fù)載測試是為收集所有正確數(shù)據(jù)以及有關(guān)應(yīng)用程序內(nèi)存占用量和JVM運(yùn)行時(shí)運(yùn)行狀況的事實(shí)而需要執(zhí)行的額外工作的良好示例。

話雖這么說，“健康的” JVM是什么意思？ 請盡您所能回答以下問題。

**如果回答“否”，請假設(shè)置信度為90％+，否則回答“我不知道”。

• 您的Java堆或OldGen空間是否隨著時(shí)間的流逝而泄漏（在進(jìn)行重大收集之后）？
• 您的應(yīng)用程序當(dāng)前受大型和/或頻繁的JVM GC暫停影響嗎？
• JVM的總體暫停時(shí)間是否高于5％或高于已建立的理想基準(zhǔn)？
• 當(dāng)前，您的應(yīng)用程序響應(yīng)時(shí)間是否經(jīng)常受到JVM GC活動的定期影響，并且超出了應(yīng)用程序的承受能力？
• 在最近3個(gè)月中，您是否觀察到j(luò)ava.lang.OutOfMemoryError錯(cuò)誤的發(fā)生？
• 您是否在最近3個(gè)月內(nèi)觀察到JVM崩潰的發(fā)生（帶有核心轉(zhuǎn)儲和崩潰報(bào)告的JVM突然故障）？
• 您是否認(rèn)為您的JVM當(dāng)前不穩(wěn)定并且/或者需要過多的人工干預(yù)（定期重啟等）？

如果您回答“是”或“我不知道”，這意味著您或您的生產(chǎn)性能調(diào)整團(tuán)隊(duì)可以在這里做一些工作，包括查看當(dāng)前的JVM GC策略。

如果您對所有具有高置信度級別的用戶回答“否”，則意味著您可能已經(jīng)獲得了可靠的應(yīng)用程序和JVM穩(wěn)定性，祝賀您。 我仍然建議您重新評估主要版本和增量負(fù)載預(yù)測之間的情況。

青年一代：真的停止世界嗎？

正如我們從快速的JVM健康狀況評估練習(xí)中看到的那樣，要點(diǎn)之一是指JVM的總體暫停時(shí)間。 這實(shí)際上意味著JVM在“停止世界”事件期間花費(fèi)了多少時(shí)間。 在此期間，應(yīng)用程序線程將被掛起并且不執(zhí)行任何工作，從而增加了應(yīng)用程序的響應(yīng)時(shí)間。 該指標(biāo)至關(guān)重要，因?yàn)檩^大的JVM暫停將觸發(fā)不穩(wěn)定且不可預(yù)測的響應(yīng)時(shí)間。

我在過去幾年中看到的一個(gè)普遍誤解是，YoungGen或次要集合是完全透明的，并且不會影響應(yīng)用程序的響應(yīng)時(shí)間。 如果您的Java堆大小很小（YG空間<1 GB），并且處理的對象生存期或分配率適中，則此語句幾乎是正確的。 在這種情況下，如果次要收集執(zhí)行得非常快（<20 ms）并且執(zhí)行得不太頻繁（每30秒以上），則YoungGen空間貢獻(xiàn)的總體JVM暫停時(shí)間將保持很小（<< 1％）。 但是，如果YG內(nèi)存分配率提高（每個(gè)請求的占用空間增加，流量激增等），情況可能會很快改變。

我建議以下文章，以獲取有關(guān)可用于HotSpot JVM的YoungGen空間和并發(fā)收集器的更多詳細(xì)信息。

＃Oracle HotSpot主要是并發(fā)收集器：CMS vs. G1

• http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/G1GettingStarted/index.html

＃Oracle HotSpot次要收藏詳盡介紹

• http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html
• http://blog.griddynamics.com/2011/06/understanding-gc-pauses-in-jvm-hotspots_02.html

無論您使用的HotSpot GC策略如何，包括大多數(shù)并發(fā)的收集器（例如CMS或G1），YoungGen空間收集仍然是“世界停止”事件。 據(jù)我們所知， Azul Zing C4是唯一宣傳為真正的連續(xù)并發(fā)壓縮收集器的JVM收集器。 目前，我們還沒有機(jī)會嘗試使用該收集器。 我歡迎任何具有C4調(diào)優(yōu)經(jīng)驗(yàn)的人分享他們的觀察結(jié)果，尤其是真實(shí)的事實(shí)數(shù)據(jù)，而不是像G1這樣的大多數(shù)并發(fā)收集器。

現(xiàn)在，我們已經(jīng)涵蓋了一些理論，下面讓我們深入研究示例應(yīng)用程序，并針對各種YoungGen占用空間和分配比率來回顧性能測試結(jié)果。

樣本應(yīng)用規(guī)范

為了比較各種YG分配率之間的響應(yīng)性和JVM暫停時(shí)間％，我們根據(jù)以下規(guī)范創(chuàng)建了一個(gè)示例應(yīng)用程序：

• 根據(jù)以下屬性，已創(chuàng)建JAX-RS（REST）Web服務(wù)，并通過jvm URI公開了該服務(wù)。

@GET@Path("/jvm")@Produces(MediaType.APPLICATION_JSON)public Integer jvm() {}

每次對jvm的調(diào)用都執(zhí)行以下邏輯：

1.分配短期對象的預(yù)定大小（適用于快速YG GC）。

此外，在類加載時(shí)會分配1 GB的長壽命對象（不適合GC）的初始內(nèi)存占用空間，以便為CMS收集器創(chuàng)建一些噪音。

YG短期對象的內(nèi)存分配和OldGen靜態(tài)保留僅通過按照下面的代碼片段創(chuàng)建原始字節(jié)值的靜態(tài)數(shù)組即可實(shí)現(xiàn)。 根據(jù)使用MAT進(jìn)行的JVM堆轉(zhuǎn)儲分析，可以觀察到真正的內(nèi)存占用量。

private final static int LONG_LIVED_OBJ_FOOTPRINT = (1024 * 1024 * 1024); private final static int SHORT_LIVED_OBJ_FOOTPRINT = (100 * 1024 * 1024);// 1 GB static memory footprint private final static byte byteArrayLongLivedObj[] = new byte[LONG_LIVED_OBJ_FOOTPRINT];// 100 MB memory allocation (waste) created per execution public void generateShortLivedObj(String objId) { byte byteArrayShortLivedObj[] = new byte[SHORT_LIVED_OBJ_FOOTPRINT]; }

最后，在下面找到環(huán)境規(guī)格和用于創(chuàng)建，執(zhí)行和監(jiān)視此YG比較性能測試的軟件。

• 作業(yè)系統(tǒng)：Windows 7 @ 64-bit
• Java EE容器： WildFly 8 Beta1
• JVM：Oracle HotSpot 1.7 @ 64位，Java堆大小為5 GB（YG空間：1152 MB XX：NewRatio = 3）。 GC收集器：CMS
• IDE： JBoss Developer Studio 7.0.0.GA
• JVM監(jiān)視： JVisualVM
• JVM內(nèi)存泄漏分析器： Plumbr 3.0
• JVM verbose：gc日志分析器： GCMV
• 性能和負(fù)載測試： Apache JMeter 2.9

性能測試結(jié)果和觀察

以下性能測試模擬了一個(gè)現(xiàn)實(shí)生活中的應(yīng)用程序，該應(yīng)用程序需要處理大量的JVM暫停時(shí)間以及在峰值負(fù)載下的嚴(yán)重降級。 在模擬每個(gè)請求的應(yīng)用程序內(nèi)存占用量的改善（減少）之后，執(zhí)行了3次運(yùn)行，其中1次作為基線運(yùn)行，另外2次運(yùn)行。

基準(zhǔn)線

• 10個(gè)并發(fā)線程
• 每個(gè)JVM進(jìn)程每次執(zhí)行創(chuàng)建100 MB的短期對象

壽命短的對象的內(nèi)存占用空間可能看起來很極端，但這確實(shí)是我們最初要解決的問題。

結(jié)果

• 平均響應(yīng)時(shí)間：140毫秒
• 吞吐量：68請求/秒
• JVM總體暫停時(shí)間： 25.8％
• YG收集頻率：每秒7個(gè)收集
• GC速度：每分鐘308909 MB

根據(jù)JVisualVM，JVM看起來很健康（沒有內(nèi)存泄漏，穩(wěn)定且OldGen低等）。 但是，當(dāng)您在verbose：gc日志中進(jìn)一步深入研究時(shí)，您會發(fā)現(xiàn)JVM的總體暫停時(shí)間為25.8％，這都是由于YG收集頻率過高所致。 這有力地證明了正確分析verbose：gc日志和僅關(guān)注JVM持久空間趨勢的意義。

測試與調(diào)整＃1

• 10個(gè)并發(fā)線程
• 每個(gè)JVM進(jìn)程每次執(zhí)行創(chuàng)建50 MB的短期對象

此運(yùn)行模擬了應(yīng)用程序占用空間和內(nèi)存分配率從每個(gè)分配的100 MB到50 MB的初始改善。 通過簡單地減少每個(gè)請求的應(yīng)用程序內(nèi)存占用量，我們可以清楚地看到所有數(shù)字的改進(jìn)，特別是吞吐量。

結(jié)果

• 平均響應(yīng)時(shí)間：119 ms -21
• 吞吐量：79要求/秒+11
• JVM整體暫停時(shí)間： 15.59％-10.21
• YG收集頻率：每秒3-4次收集-3
• GC速度：每分鐘164950 MB -143959

測試與調(diào)整＃2

• 10個(gè)并發(fā)線程
• 每個(gè)JVM進(jìn)程每次執(zhí)行創(chuàng)建5 MB的短期對象

此運(yùn)行模擬了將應(yīng)用程序占用空間和內(nèi)存分配率從100 MB大大降低到每個(gè)分配僅5 MB的情況。

結(jié)果

• 平均響應(yīng)時(shí)間：107毫秒-33
• 吞吐量：90請求/秒+22
• JVM總體暫停時(shí)間： 1.9％-23.9
• YG收集頻率：每2-3秒收集1次*大幅減少
• GC速度：每分鐘15841 MB -293068

如您所見，對應(yīng)用程序占用空間和內(nèi)存分配的最終改進(jìn)確實(shí)將JVM暫停時(shí)間顯著減少到了可接受的1.9％。 重要的是要注意，在這3個(gè)測試中，OldGen占用空間和CMS活動對JVM暫停時(shí)間沒有任何實(shí)質(zhì)性影響，性能問題是由于活動過多以及與YG相關(guān)的世界停止事件數(shù)量過多所致集合。

解決方案和建議

我們的問題案例表明，通過調(diào)整和減少每個(gè)應(yīng)用程序請求的內(nèi)存占用空間，可以減少與過多的YG收集活動相關(guān)的JVM暫停時(shí)間，從而降低分配率和YG GC頻率。

但是，當(dāng)短期內(nèi)無法使用這種調(diào)整策略時(shí)，值得探索其他解決方案。 通過以下能力改進(jìn)策略可以潛在地獲得類似的結(jié)果：

• 水平和垂直擴(kuò)展：通過增加數(shù)量的JVM進(jìn)程來拆分流量，但以可用硬件為代價(jià)，從而降低了YG集合的分配率和頻率。 從本質(zhì)上講，這意味著將硬件投入該問題。 我的建議始終是先微調(diào)您的應(yīng)用程序內(nèi)存占用量，然后并行探索其他擴(kuò)展選項(xiàng)。
• Java堆大小和YG比率調(diào)整：增大YG空間的大小肯定會有助于減少停止世界YG集合的頻率。 現(xiàn)在請小心，不要使“舊Gen”空間“餓死”，否則您將直接解決問題，并產(chǎn)生更嚴(yán)重的后果，例如JVM抖動和OOM事件。

最后的話

我希望您喜歡本文，并且現(xiàn)在更好地了解過多的JVM YG集合對性能的潛在影響。

我建議您閱讀本文后做以下練習(xí)：

• 選擇您最繁忙的應(yīng)用程序之一。
• 查看verbose：gc日志，并通過GCMV確定JVM暫停時(shí)間。
• 確定YG收集的頻率和影響，并確定調(diào)整機(jī)會。

期待您的意見，并分享您的JVM調(diào)優(yōu)經(jīng)驗(yàn)。

參考： Java VM –在Java EE支持模式博客上，請我們的JCG合作伙伴 Pierre Hugues Charbonneau 注意YoungGen領(lǐng)域 。

翻譯自: https://www.javacodegeeks.com/2013/11/java-vm-beware-of-the-younggen-space.html

總結(jié)

以上是生活随笔為你收集整理的Java VM –提防YoungGen空间的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。