應(yīng)用程序性能是我們的首要考慮因素，垃圾收集優(yōu)化是取得小而有意義的進步的好地方

自動化垃圾收集（與JIT HotSpot編譯器一起）是JVM中最先進，最有價值的組件之一，但是許多開發(fā)人員和工程師對垃圾收集（GC），其工作方式以及如何影響應(yīng)用程序性能的了解都很少。 。

首先，GC還可以做什么？ 垃圾收集是堆中對象的內(nèi)存管理過程。 將對象分配給堆時，它們會經(jīng)歷幾個收集階段–通常相當(dāng)快，因為??堆中的大多數(shù)對象的壽命很短。

垃圾收集事件包含三個階段-標(biāo)記，刪除和復(fù)制/壓縮。 在第一階段，GC遍歷堆，并將所有內(nèi)容標(biāo)記為活動（引用）對象，未引用對象或可用內(nèi)存空間。 然后刪除未引用的對象，并壓縮剩余的對象。 在分代的垃圾收集中，對象“老化”并通過其生活中的3個空間進行提升-伊甸園，幸存者空間和保有權(quán)（舊）空間。 這種移動也作為壓實階段的一部分發(fā)生。

但是足夠了，讓我們進入有趣的部分！

了解Java中的垃圾回收（GC）

自動化GC的一大優(yōu)點是，開發(fā)人員實際上不需要了解其工作原理。 不幸的是，這意味著許多開發(fā)人員不了解其工作原理。 了解垃圾收集和許多可用的GC，有點像了解Linux CLI命令。 從技術(shù)上講，您不需要使用它們，但是了解和使用它們會對您的生產(chǎn)率產(chǎn)生重大影響。

就像CLI命令一樣，這里有絕對的基礎(chǔ)知識。 ls命令查看父文件夾中的文件夾列表， mv將文件從一個位置移動到另一個位置，等等。在GC中，這些類型的命令等同于知道有多個GC可供選擇，并且GC可能引起性能問題。 當(dāng)然，還有很多東西要學(xué)習(xí)（關(guān)于使用Linux CLI和垃圾回收）。

學(xué)習(xí)Java的垃圾回收過程的目的不僅是免費（無聊）的對話入門者，其目的還在于學(xué)習(xí)如何針對特定環(huán)境有效地實現(xiàn)和維護具有最佳性能的正確GC。 知道垃圾回收會影響應(yīng)用程序性能是基礎(chǔ)，并且有許多先進的技術(shù)可以增強GC性能并減少其對應(yīng)用程序可靠性的影響。

GC性能問題

1.內(nèi)存泄漏–

通過了解堆結(jié)構(gòu)以及如何執(zhí)行垃圾回收，我們知道內(nèi)存使用量逐漸增加，直到發(fā)生垃圾回收事件并且使用率回落為止。 被引用對象的堆利用率通常保持穩(wěn)定，因此下降幅度應(yīng)大致相同。

發(fā)生內(nèi)存泄漏時，每個GC事件都會清除一小部分堆對象（盡管沒有使用許多留在后面的對象），因此堆利用率將繼續(xù)增加，直到堆內(nèi)存已滿，并且將拋出OutOfMemoryError異常。 原因是GC僅將未引用的對象標(biāo)記為刪除。 因此，即使不再使用引用的對象，也不會從堆中清除該對象。 有一些有用的編碼技巧可以防止這種情況，稍后我們將介紹。

2.連續(xù)的“停止世界”活動–

在某些情況下，垃圾回收可以稱為Stop the World事件，因為當(dāng)垃圾回收發(fā)生時，JVM中的所有線程（并因此在其上運行的應(yīng)用程序）都將停止以允許GC執(zhí)行。 在健康的應(yīng)用程序中，GC執(zhí)行時間相對較短，并且不會對應(yīng)用程序性能產(chǎn)生太大影響。

但是，在次優(yōu)情況下，“停止世界”事件可能會極大影響應(yīng)用程序的性能和可靠性。 如果GC事件需要“停止世界”暫停并需要2秒鐘的時間執(zhí)行，則該應(yīng)用程序的最終用戶將遇到2秒的延遲，因為運行該應(yīng)用程序的線程被停止以允許GC。

當(dāng)發(fā)生內(nèi)存泄漏時，連續(xù)的“停止世界”事件也是有問題的。 由于每次執(zhí)行GC都會清除較少的堆內(nèi)存空間，因此剩余內(nèi)存填滿的時間會更少。 當(dāng)內(nèi)存已滿時，JVM會觸發(fā)另一個GC事件。 最終，JVM將運行重復(fù)的Stop the World事件，從而引起嚴重的性能問題。

3. CPU使用率–

而這全都取決于CPU使用率。 連續(xù)GC /“停止世界”事件的主要癥狀是CPU使用率激增。 GC是一項計算量大的操作，因此所花費的資源不應(yīng)該超過它的CPU能力。 對于運行并發(fā)線程的GC，CPU使用率可能更高。 為您的應(yīng)用程序選擇合適的GC將對CPU使用率產(chǎn)生最大的影響，但是還有其他方法可以優(yōu)化以提高該領(lǐng)域的性能。

從圍繞垃圾收集的性能問題中我們可以了解到，盡管高級GC獲得了（并且它們已經(jīng)相當(dāng)先進），但其致命弱點仍然保持不變。 冗余且不可預(yù)測的對象分配。 要提高應(yīng)用程序性能，僅選擇正確的GC是不夠的。 我們需要了解流程的工作方式，并且需要優(yōu)化代碼，以使我們的GC不會占用過多的資源或在應(yīng)用程序中造成過多的暫停。

世代GC

在深入研究不同的Java GC及其對性能的影響之前，了解世代垃圾收集的基礎(chǔ)很重要。 世代GC的基本概念基于這樣的思想，即對堆中某個對象的引用存在的時間越長，將其標(biāo)記為刪除的可能性就越小。 通過用具有象征意義的“年齡”標(biāo)記對象，可以將它們分隔到不同的存儲空間，以使GC進行標(biāo)記的頻率降低。

將對象分配給堆時，會將其放置在所謂的Eden空間中。 那是對象開始的地方，在大多數(shù)情況下，它們是標(biāo)記為刪除的地方。 在該階段幸存的對象將“慶祝生日”，并復(fù)制到Survivor空間。 此過程如下所示：

伊甸園和幸存者空間組成了年輕一代。 這是大部分操作發(fā)生的地方。 當(dāng)（如果）年輕一代中的某個對象達到一定年齡時，該對象將被提升到終身（也稱為舊）空間。 根據(jù)年齡劃分對象內(nèi)存的好處是GC可以在不同級別上運行。

次要GC是僅關(guān)注年輕一代的集合，實際上完全忽略了Tenured空間。 通常，年輕代中的大多數(shù)對象都標(biāo)記為刪除，并且不需要主要或完整GC（包括舊代）來釋放堆上的內(nèi)存。 當(dāng)然，必要時會觸發(fā)“主要”或“完全” GC。

在此基礎(chǔ)上優(yōu)化GC操作的一個快速技巧是調(diào)整堆區(qū)域的大小，以最適合您的應(yīng)用程序的需求。

收集器類型

有許多可用的GC可供選擇，盡管G1成為Java 9中的默認GC ，但它最初旨在替代低暫停的CMS收集器，因此使用吞吐量收集器運行的應(yīng)用程序可能更適合保留其當(dāng)前收集器。 對于Java垃圾收集器，了解操作差異以及性能影響差異仍然很重要。

吞吐量收集器

更適合需要針對高吞吐量進行優(yōu)化的應(yīng)用程序，并且可以交易更高的延遲來實現(xiàn)。

序列號–

串行收集器是最簡單的一種，也是您最不可能使用的一種，因為它主要用于單線程環(huán)境（例如32位或Windows）和小型堆。 該收集器可以垂直擴展JVM中的內(nèi)存使用量，但需要幾個主要/完全GC才能釋放未使用的堆資源。 這會導(dǎo)致頻繁的Stop the World暫停，從而使它在所有意圖和目的上都無法在面向用戶的環(huán)境中使用。

平行 -

顧名思義，此GC使用并行運行的多個線程來掃描并壓縮堆。 盡管Parallel GC使用多個線程進行垃圾回收，但它在運行時仍會暫停所有應(yīng)用程序線程。 Parallel收集器最適合需要針對最佳吞吐量進行優(yōu)化并且可以忍受更高延遲的應(yīng)用程序。

低暫停時間收集器

大多數(shù)面向用戶的應(yīng)用程序都需要低暫停GC，因此長時間或頻繁的暫停不會影響用戶體驗。 這些GC都是為了優(yōu)化響應(yīng)能力（時間/事件）和強大的短期性能。

并發(fā)標(biāo)記掃描（CMS）–

與并行收集器相似，并發(fā)標(biāo)記掃描（CMS）收集器利用多個線程來標(biāo)記和清除（刪除）未引用的對象。 但是，此GC僅在以下兩個特定實例中啟動“停止世界”事件：

（1）在初始化根的初始標(biāo)記（舊代對象中可以從線程入口點或靜態(tài)變量訪問的對象）或main（）方法的任何引用時，等等

（2）當(dāng)應(yīng)用程序在算法同時運行時更改了堆的狀態(tài)時，迫使它返回并進行最后的修改以確保它標(biāo)記了正確的對象

G1 –

垃圾第一收集器（通常稱為G1）利用多個后臺線程掃描通過堆將其劃分為多個區(qū)域。 它的工作方式是先掃描那些包含最多垃圾對象的區(qū)域，然后為其命名（垃圾優(yōu)先）。

這種策略減少了在后臺線程完成對未使用對象的掃描之前耗盡堆的機會，在這種情況下，收集器將不得不停止應(yīng)用程序。 G1收集器的另一個優(yōu)點是它可以在移動過程中壓縮堆，這是CMS收集器僅在完全Stop the World收集期間執(zhí)行的操作。

改善GC性能

垃圾收集的頻率和持續(xù)時間直接影響應(yīng)用程序的性能，這意味著可以通過減少這些指標(biāo)來優(yōu)化GC流程。 有兩種主要方法可以做到這一點。 首先，通過調(diào)整年輕人和老年人的堆大小 ，其次，以減少對象分配和提升的速度 。

在調(diào)整堆大小方面，它并不像人們期望的那么簡單。 合理的結(jié)論是，增加堆大小將減少GC頻率，同時增加持續(xù)時間，而減少堆大小將減少GC持續(xù)時間，同時增加頻率。

不過，事實是，次要GC的持續(xù)時間不取決于堆的大小，而是取決于可以幸存的對象數(shù)量。 這意味著對于大多數(shù)創(chuàng)建壽命短的對象的應(yīng)用程序，增加年輕代的大小實際上可以減少GC的持續(xù)時間和頻率。 但是，如果增加年輕代的大小會導(dǎo)致需要在幸存者空間中復(fù)制的對象顯著增加，則GC暫停將花費更長的時間，從而導(dǎo)致延遲增加。

編寫GC高效代碼的3個技巧

提示1：預(yù)測收集容量–

所有標(biāo)準Java集合以及大多數(shù)自定義和擴展的實現(xiàn)（例如Trove和Google的Guava）都使用基礎(chǔ)數(shù)組（基于原始或?qū)ο蟮臄?shù)組）。 由于數(shù)組一旦分配就不會改變大小，因此在許多情況下向集合中添加項目可能會導(dǎo)致丟棄舊的基礎(chǔ)數(shù)組，而使用較大的新分配的數(shù)組。

即使未提供預(yù)期的集合大小，大多數(shù)集合實現(xiàn)都嘗試優(yōu)化此重新分配過程并將其保持在攤銷后的最小值。 但是，通過在構(gòu)造時為集合提供預(yù)期的大小可以達到最佳效果。

提示2：直接處理流–

例如，在處理數(shù)據(jù)流（例如從文件讀取的數(shù)據(jù)或通過網(wǎng)絡(luò)下載的數(shù)據(jù)）時，通常會看到以下內(nèi)容：

byte[] fileData = readFileToByteArray(new File("myfile.txt"));

然后，可以將結(jié)果字節(jié)數(shù)組解析為XML文檔，JSON對象或協(xié)議緩沖區(qū)消息，以列舉一些常用的選項。

當(dāng)處理大文件或大小無法預(yù)測的文件時，這顯然不是一個好主意，因為在JVM無法實際分配整個文件大小的緩沖區(qū)的情況下，這會使我們面臨OutOfMemoryErrors。

解決此問題的更好方法是使用適當(dāng)?shù)腎nputStream（在這種情況下為FileInputStream），將其直接輸入解析器，而無需先將整個內(nèi)容讀取到字節(jié)數(shù)組中。 所有主要庫都公開了API以直接解析流，例如：

FileInputStream fis = new FileInputStream(fileName); MyProtoBufMessage msg = MyProtoBufMessage.parseFrom(fis);

提示3：使用不可變對象–

不變性有很多優(yōu)點。 很少受到關(guān)注的一個問題是它對垃圾收集的影響。

不變對象是指在構(gòu)造對象之后其字段（在我們的情況下尤其是非原始字段）無法修改的對象。

不變性意味著不變?nèi)萜饕玫乃袑ο蠖际窃谌萜鳂?gòu)造完成之前創(chuàng)建的。 用GC的術(shù)語來說：容器至少與所保存的最小引用一樣年輕。 這意味著，在年輕一代執(zhí)行垃圾回收周期時，GC可以跳過位于老一代中的不可變對象，因為它可以確定它們不能引用正在收集的一代中的任何對象。

要掃描的對象越少，意味著要掃描的內(nèi)存頁面越少，而要掃描的內(nèi)存頁面就越少，意味著GC周期越短，這意味著GC暫停時間越短，總體吞吐量就越高。

有關(guān)更多技巧和詳細示例，請查看這篇文章，其中涵蓋了用于編寫內(nèi)存效率更高的代碼的深入策略。

***非常感謝OverOps研發(fā)團隊的Amit Hurvitz對本文的熱情和見解！

翻譯自: https://www.javacodegeeks.com/2018/08/improve-application-performance-gc.html

總結(jié)

以上是生活随笔為你收集整理的使用这些先进的GC技术提高应用程序性能的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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