Zing虛拟機文檔Understanding Java Garbage Collection(了解Java垃圾收集)
首先說明這個Zing是收費的，但是他也是優秀的，我覺得我們可以研究下他的一些思想對于怎麼提高JVM，以及目前的JVM有什麼缺陷是非常有幫助的。
中文版簡介：https://cn.azul.com/
Zing的優勢：
1）更好的性能
支援 Zing 的 Falcon JIT 編譯器是使用 LLVM 技術建構的，其可提供深入的優化。
2）無停頓執行
Azul 解決了Java 的垃圾回收問題。停止和應用程式逾時、GC 停頓、停滞和抖動周旋。
3）更快速啟動
憑借 ReadyNow!® 技術，Java 應用程式啟動速度快，且能保持高速運作。
Zing：虛拟機
Zing FAQ：
https://www.azul.com/products/zing/zinqfaq/
下面是我結合谷歌翻譯後再适當修改了下的FAQ，删掉了購買等和技術無關的部分：
什麼是Zing®？
Zing是一個相容并符合Java SE規範的JVM。Zing針對Linux和x86進行了優化。Zing專為需要大記憶體，高事務率，一緻響應時間或高持續吞吐量的任意組合的企業應用程式和工作負載而設計，是唯一能夠提供與堆大小無關的可預測響應時間的JVM。
Zing與傳統JVM在部署Java應用程式方面有何不同？
Zing是一個高度優化的 JVM和彈性運作時，它打破了傳統的Java規模障礙，并為Java應用程式，規模和吞吐量提供了數量級的改進。Zing發行版包括一個非侵入式，生産時應用程式可見性工具，稱為Zing Vision（ZVision）。
借助ZVision，IT組織首次擁有零開銷，細粒度的可見性工具，可幫助發現問題并加速解決難以捉摸的生産問題。
Zing是另一個JVM嗎？
Zing是一個更好的 JVM，它利用先進技術為主流Java應用程式提供更高的性能。我們的大多數客戶不需要巨大的Java堆或超低延遲 - 他們隻是希望他們的Java應用程式可靠地運作。Zing通過Azul C4提供這些優勢 (Continuously Concurrent Compacting Collector) （連續并發壓縮收集器）消除了限制所有傳統JVM可擴充性的“stop-the-world”(“全局停頓”)。由于單執行個體可以擴充到幾千兆位元組到多達8TB記憶體，是以Zing可以顯着減少支援企業應用程式或多租戶SaaS / PaaS解決方案所需的執行個體總數，進而簡化部署，顯着提高響應時間一緻性并降低營運支出和資本支出。Zing還附帶ReadyNow！解決Java預熱問題的技術，允許您的應用程式快速啟動并保持快速。
Zing如何提供比其他JVM更好的性能？
Zing消除了“stop-the-world”(“全局停頓”)式的垃圾收集，其他JVM限制了這樣的可擴充性，是以每個Zing執行個體可以擴充到8TB的堆記憶體。Zing還使用高度優化的即時（JIT）編譯器，預設使用分層編譯。
傳統的Java熱身問題由Zing的ReadyNow解決！允許應用程式快速啟動并保持快速運作的技術，允許營運團隊在運作之間儲存和重用累積的編譯器優化，并避免在工作負載或條件發生變化時可能減慢處理速度的去優化停頓。
什麼是Zing Vision？
Zing Vision是一個安裝在Zing裡的零開銷，永遠線上的線上監控，診斷和調整工具。
Zing總是收集資料作為其必須完成的工作的輔助任務，這使得系統管理者可以通過Zing Vision利用這些資訊，而不必擔心影響正在運作的應用程式。
Zing如何解決Java熱身問題（Java warm up）？
Zing使用Azul創新的ReadyNow！™ 技術來解決熱身問題。ReadyNow專為低延遲系統而設計！允許Java應用程式在啟動時實作最佳性能和一緻性，并最大限度地減少負載條件發生變化時可能發生的破壞優化。
為什麼要介紹Zing的名為“Falcon”的新編譯器？
Falcon JIT編譯器的開發是為了確定Java開發人員和基于Java的企業能夠從當今的伺服器硬體中擷取最大性能。
Falcon JIT編譯器基于什麼技術？
Falcon JIT編譯器基于LLVM技術，這是一個受歡迎的編譯器基礎設施項目，得到了一流大學和包括Adobe，Apple，Google，NVIDIA和Intel在内的數十家企業貢獻者的積極參與。
Falcon比C2更快嗎？
是。
Falcon支援哪些版本的Java？
Falcon适用于使用Java SE 7和Java SE 8建構的應用程式。作為功能預覽，Falcon還可以與Java SE 10和11一起使用（即将推出）
Zing如何支援大堆大小以及它是如何彈性的？
Zing允許Java應用程式利用他們需要執行的任何數量的記憶體，僅受系統中實體記憶體或虛拟機管理程式可識别的數量的限制。
由于Zing獨特的垃圾收集器，基于Azul的開創性C4 （連續并發壓縮收集器）技術，GC暫停與JVM堆的大小無關，并且不限制應用程式可伸縮性。
此外，Zing還包括一項專利創新的“記憶體池”（即記憶體儲備），允許JVM根據實時需求動态增加記憶體占用量; 當需求減少時，Zing将此記憶體傳回給系統。
此記憶體預留不僅可確定在高負載下保持一緻的性能，而且可以充當因錯誤或編碼錯誤而遇到“記憶體洩漏”的JVM的緊急記憶體。
什麼是Zing ReadyNow！™？
ReadyNow！是Zing運作時内置的技術，可以很好地解決Java熱身問題。
他有兩個主要特點：
首先，它使營運團隊能夠跨運作儲存和重用編譯器優化。
第二，ReadyNow！為開發人員提供強大的API和編譯器指令，以預編譯常用的代碼或必須快速的方法，即使它們不經常被調用。
Zing如何提供無間斷操作？
Zing預設使用Azul C4垃圾收集器。無論堆大小如何，C4收集器都在不斷地進行壓縮，并且永遠不會使用“stop-the-world”(“全局停頓”)的暫停來進行垃圾收集。
什麼是C4垃圾收集器？
該C4（連續并行壓縮收集器） 是一個更新的代執行Azul Pauseless GC算法，是Zing的預設垃圾收集器。
Zing能幫助解決資料庫争用嗎？
是。使用較少的應用程式執行個體，您的資料庫可以看到更少的連接配接和更少的争用
Zing是否已經使用各種Java應用程式進行了測試？
是。對于每個版本，我們測試各種應用程式堆棧（包括Wildfly，Active MQ，Cassandra，WebLogic Server，WebSphere Application Server，JBoss和Tomcat），以及其他開源軟體和第三方應用程式。
企業主為什麼要關心Zing？
Java應用程式通常是關鍵業務和關鍵任務。影響收入和使用的性能和可伸縮性問題通常不是由應用程式，資料庫或網絡引起的，而是通常與JVM的選擇有關。
通過選擇Zing，您可以消除意外長時間的使用者等待時間和記憶體不足崩潰，進而捕獲收入和客戶的損失，并在需求突然出現時提供一緻的使用者體驗。
Azul C4垃圾收集器
大多數垃圾收集器的主要缺點是需要長時間的應用程式暫停。這些暫停是不可避免的要求壓縮堆以釋放空間的結果。收集器使用不同的政策來延遲這些事件，但是除了使用連續并發壓縮收集器的Azul C4垃圾收集器之外，所有商業可用收集器都不可避免地壓縮。
C4（連續并發壓縮收集器）是Azul Pauseless GC算法是Zing®的預設收集器。 C4通過支援同時生成并發來差別于其他世代垃圾收集器：使用可以同時且獨立活動的并發（非停頓）機制收集不同代。與其他算法不同，它不是“大部分”并發，而是完全并發，是以它永遠不會回到 stop-the-world 的壓縮。
垃圾收集器摘要如下。有關術語的更多資訊以及有關收集器的更多詳細資訊，請閱讀Understanding Java GC白皮書。
垃圾收集（GC）是Java平台上應用程式行為的一個組成部分。Java開發人員可以通過了解GC的工作原理以及更好地選擇垃圾收集器來提高應用程式性能，可伸縮性和可靠性。
更多資源：
關于Azul C4收集器的技術白皮書»
*請注意，使用IBM的J9和Oracle的JRockit，您可以選擇使用單代或2代垃圾收集器
ReadyNow！® - 啟動更快，保持快速
解決Java熱身問題
專為基于Java的應用程式而設計，必須滿足特定的服務級别
幫助開發人員管理Java的運作時去優化
減少CPU資源消耗
允許儲存和重複使用累積的編譯器優化配置檔案
為開發人員提供對Java編譯的更多控制
減少因合成測試或“假”資料的需要而導緻的運作預熱風險
在市場開放等關鍵時刻確定一緻的峰值性能
允許Java快速啟動并保持快速
要了解有關ReadyNow的更多資訊！®特性和功能，下載下傳 資料表
了解更多有關Azul的ReadyNow的資訊！®技術在 InfoQ采訪阿祖爾首席技術:Azul ReadyNow！尋求消除JVM熱身
Java“熱身”問題的背後:
基于Java的系統在運作編譯和優化代碼時可提供出色的性能。但是，JVM需要時間來“預熱”或優化常用代碼，是以應用程式可以以最快的速度運作。
為什麼會這樣？ Java旨在快速啟動，然後根據實際使用情況提高性能。JVM的即時（JIT）編譯器（如Zing的Falcon編譯器）依賴于描述應用程式的哪些部分被稱為最多（“熱”代碼）的配置檔案資料。
JIT編譯允許JVM優化性能，但這可能需要時間。在資本市場等用例中，通常系統會“熱身”以提供最佳性能。雖然Java應用程式通常需要一段時間才能啟動，但是當打開鈴聲響起時，它必須準備好進行全面優化。
目前的Java預熱政策:
需要最佳Java性能和一緻性的公司（如金融服務公司）已經嘗試了多種方法來加熱JVM，例如模拟測試資料，“虛假”交易，甚至是市場開放時的小型實時交易。
在其他問題中，這些政策可能會引入操作風險，即“虛假”資料可能會洩漏到“真實”交易日，或者實際情況可能與用于預熱JVM的方案不同。有效的政策需要複制真正的端到端行為。
如果條件發生變化，Java會恢複為已解釋的代碼，這種情況稱為“去優化”，這會使性能降低到爬行速度，直到重新編譯和重新優化關鍵方法。Azul的ReadyNow！技術提供兩個關鍵功能。首先是營運團隊能夠跨運作儲存和重用累積的優化配置檔案。第二個是一組強大的API和編譯器指令，使開發人員能夠更好地控制JVM去優化的時間和影響。
解決方案：ReadyNow！®AzulSystems的技術:
好了！®是用于Java的Zing運作時内置的技術。它允許基本系統在交易日開始時實作最佳性能和一緻性。常見的熱身技術有時會針對錯誤的條件進行優化，Zing的ReadyNow！
當“真實”交易與用于預熱的配置檔案不同時，技術可以防止大多數去優化。有了ReadyNow！營運團隊可以從一天或一組市場條件中節省累積的優化，以便以後重複使用。
此外，開發人員可以更好地控制Java編譯，包括API，配置指令，政策控制以及對“未實作”代碼處理的改進。ReadyNow專為低延遲系統而設計！技術使Java應用程式從開幕式開始就能快速上市 - 并且它們保持快速。
垃圾收集（GC）調整
為什麼垃圾收集（GC）調整？
大多數垃圾收集器必須停止應用程式處理 (“stop-the-world”)以确定哪些對象仍在使用中，這些對象可以被垃圾收集以及對記憶體堆進行碎片整理和壓縮。暫停時間随記憶體堆大小線性增加，是以大堆可能導緻使用者明顯延遲和應用程式性能不佳。
GC調整 - 一些基礎知識
調整垃圾收集所花費的大部分時間都是為了延遲壓縮。由于大多數物體都很年輕，是以可以在年輕一代上進行垃圾收集一段時間，但最終需要回收舊的沒用的對象。可以通過跟蹤舊的gen對象被删除的位置并使用釋放的記憶體來進一步延遲完整的GC。但是，在某些時候，這個空間将變得支離破碎，需要回收。您可以嘗試通過調整盡可能地延遲垃圾收集，但實際情況是您不能永遠延遲它。
消除垃圾收集暫停和GC調整的需要
Zing虛拟機使用 Azul創新的C4收集器，可提高應用程式性能，無需進行大多數GC調整。使用Zing，應用程式可在堆和GC設定的廣泛，平穩操作範圍内始終如一地執行。另一個關鍵的好處是“你測試的是你得到的東西”，是以生産中的性能與測試的性能相比對。
C4是一種高度并發，一緻的算法，能夠同時壓縮Java堆，并允許應用程式在執行記憶體重映射時繼續執行。其他JVM需要“停止世界”暫停才能完全壓縮堆。請參閱下面的Zing GPGC和HotSpot JVM CMS的比較。
HotSpot JVM CMS與Zing Pauseless垃圾收集的比較：
Hotspot JVM CMS
年輕代：會停頓。
年老代：大部分是并發的，非壓縮的
├主要是并發标記
├在mutator運作時同時标記，
├跟蹤卡片标記中的突變，
├重新通路變異卡片（根據需要重複），
└停頓Stop-the-world以趕上突變，ref處理等。
├并發打掃
└不壓縮（維護空閑清單，不移動對象）
FGC：停頓Stop-the-world
而Azul PGC 總之是并發，壓縮，且沒有停頓的！
Java堆大小
Java堆是配置設定給在JVM中運作的應用程式的記憶體量。堆記憶體中的對象可以線上程之間共享。
由于垃圾收集暫停，傳統JVM中Java堆大小的實際限制通常約為2-8 GB。許多類型的應用程式都可以從非常大的堆中受益，例如記憶體計算，NoSQL資料庫，大資料 應用程式，分析，Web個性化和電子商務。
一個100GB的堆不會在典型的JVM上崩潰，它會一次定期暫停幾分鐘。這限制了應用程式性能和可伸縮性，并阻止Java應用程式使用當今商用伺服器的全部資源。
如果可以消除相關的性能問題，非常大的堆大小通常非常實用。Azul的Zing®是解決Java的垃圾回收問題，并允許堆多達8TB沒有性能損失的第一個JVM。
更大的Java記憶體堆：
允許建立更多對象；
填充需要更長時間；
允許應用程式在垃圾收集（GC）事件之間運作更長時間。
較小的Java記憶體堆：
保留較少的對象；
填寫更快；
是否更頻繁地收集垃圾（但暫停時間較短）；
可能導緻記憶體不足錯誤。
2-8GB的記憶體堆是否足以滿足大多數Java應用程式的需求？
我們已經找到了大量證據表明對更多堆的需求被壓抑了：
機器内“橫向尺度”的常見用途
使用“外部”記憶體和不斷增長的資料集（更大的資料庫以及使用外部資料緩存，如memcached，JCache和JavaSpaces）
持續研究永無止境的配置設定問題
問題出在軟體堆棧中，它會對每個執行個體的記憶體施加人為限制。
GC暫停時間是執行個體大小的唯一限制因素，正如我們在實踐中發現的那樣，即使是廣泛的垃圾收集（GC）調整也不會讓它消失。
一旦你解決了GC，你就解決了這個問題。Azul的創新C4垃圾收集算法是完全并發的，消除了非常大堆的性能影響。
JVM調優
JVM調優：主要指記憶體堆大小和垃圾收集（GC）調優。
如果您正在尋找有關Zing調整标志的特定資訊，請檢視ZVM指令行選項下的線上Zing文檔。
記憶體堆大小
對于大多數JVM，調整堆大小需要分析應用程式如何使用記憶體，更改參數和重新分析。應用程式需要盡可能靠近生産負載運作。這是特别難以做到的，因為在實驗室中不會看到一些現實中出現的負載。大多數JVM使您能夠設定初始堆大小（-Xms）和最大堆大小（-Xmx），但有些也允許其他參數，如大頁。如果堆大小設定得太大，垃圾收集暫停會變得太長; 如果堆大小設定得太小，應用程式将抛出記憶體不足錯誤并可能崩潰。是以，記憶體和GC調優是影響應用程式性能的密切相關主題。
Zing®消除了大部分JVM調整的需要。Zing支援堆記憶體的“銀行系統” ( ‘banking system’ )，允許運作時執行個體根據需要可靠地增長和縮小記憶體堆。Zing可以以多個GB /秒的速度在執行個體之間轉移實體資源。不必将記憶體堆調整“完全正确”可以節省大量時間。您可以專注于為業務增加更多價值并啟動新計劃，而不是花時間調整和重新調整Java基礎架構以修複生産故障。
此外，該平台還包括Zing Vision，一種零開銷，始終線上監控，調整和可視性工具。使用Zing Vision，您可以快速啟動應用程式，進而加快産品上市速度并随時調整生産。下面是傳統JVM和Zing的實際JVM調整參數的示例。
介紹Falcon JIT編譯器
Zing的Falcon JIT編譯器
在将近二十年之後，Java有了一個新的實時（JIT）編譯器，它隻能在Zing運作時中用于Java。 Azul Systems建構了Falcon JIT編譯器，以確定Java開發人員和基于Java的企業能夠從當今的伺服器硬體中擷取最大性能。
Falcon JIT編譯器與Azul的無暫停垃圾收集技術以及ReadyNow完全內建！技術，解決了延遲敏感應用程式中Java的預熱問題。
LLVM - Falcon JIT背後的技術
Falcon JIT編譯器基于LLVM技術，這是一個受歡迎的編譯器基礎設施項目，得到了一流大學和包括Adobe，Apple，Google，NVIDIA和Intel在内的數十家企業貢獻者的積極參與。
今天，LLVM被用于Java和JVM之外的各種程式設計語言和架構，包括Swift和Rust等新平台以及許多其他平台，包括C / C ++，Objective-C，Swift，Clang，OpenCL，CUDA等等。
LLVM被認為是最先進的編譯器技術，LLVM社群不斷采用新的優化技術并支援新的處理器指令集和硬體平台。
使用Zing的新Falcon JIT編譯器運作時，Java工作負載的性能優勢具有顯着的業務優勢：
更好的應用程式服務級别名額：減少延遲，減少逾時，提高一緻性;
更好的客戶體驗：即使在不可預測的負載下也能可靠地實作客戶期望，提高客戶滿意度;
降低營運成本：減少記憶體占用要求，提高雲/ AWS部署中類似大小的執行個體的承載能力;
降低開發成本：實作所需性能，一緻性和規模所需的工程時間更短.
問：Zing什麼時候和Falcon一起發貨？
答：Falcon JIT已與Zing一起運作了幾個月。從版本17.03開始，Falcon是Zing的預設JIT編譯器，取代了傳統的C2編譯器。
問：Falcon JIT比C2更快嗎？
答：是的。
問：Zing還支援C2嗎？
答：是的，可以通過在JVM啟動時指定标志來使用C2。
問：我是否需要重新編譯現有的應用程式以使用Falcon？
答：不用。
問：Falcon支援哪些版本的Java？
答：Falcon适用于使用Java SE 7和Java SE 8建構的應用程式。
問：Falcon會支援Java 9嗎？
答：是的，在Zing的未來版本中。