通過優銳課核心java學習筆記中，我們可以看到，碼了很多專業的相關知識， 分享給大家參考學習。
在容器化環境中啓用類共享
OpenJ9最初設計爲可在2000年代早期的移動設備上運行，它是一種用於雲的Java虛擬機，它使用的內存大約是JDK8 Hotspot的一半，而吞吐量卻幾乎與其相當。這種性能提升直截了當；但是，還有更多的調整可以做。在本文中，瞭解在容器化環境中運行時如何啓用OpenJ9的類共享功能。
如果你不熟悉OpenJ9中的類共享功能，那麼教程“ Eclipse OpenJ9中的類共享”（IBM Developer，2018年6月）深入探討了類共享的工作原理以及爲什麼要使用它。簡短的版本是類共享允許OpenJ9 JVM在Java代碼上編譯和執行優化，並將該信息緩存在一個公共位置，以供其他OpenJ9 JVM使用。類共享提供了顯着的好處，包括提高了啓動速度並減少了CPU和內存使用量。
在容器化環境之外，使用OpenJ9的類共享功能就像將JVM arg -Xshareclasss添加到啓動腳本中並讓OpenJ9的默認值處理其餘部分一樣簡單。但是，在容器化環境中（如在雲中運行Java應用程序時經常發生的情況），需要做更多的工作。讓我們看一下在容器化環境中設置OpenJ9的類共享的兩種方法，並權衡每種方法的優缺點。
方法1：使用Docker
將Docker卷用作共享類緩存直接來自OpenJ9 Docker頁面。 設置共享類以使用Docker卷非常簡單。
1.創建Docker。
2.這是我用來創建我的代碼：
3.docker卷創建java共享類
4，在帶有CMD或ENTRYPOINT的Dockerfile中，你需要啓用類共享並顯式定義存儲類信息的位置：
5.ENTRYPOINT [“ java”，“ -Xshareclasses：cacheDir = / cache”，“ -Xscmx300M”，...]
6.-Xshareclasses可以有幾個子選項，其中一個是cacheDir，這使我們可以顯式定義用於存儲類數據的目錄。你還可以選擇定義緩存的大小。 在這種情況下，我將緩存設置爲非常大的300MB。
7.在運行Docker容器時必須裝入該卷。 在Docker運行命令的腳本中，添加以下內容：
8.docker運行--mount source = java-shared-classes，target = / cache <映像名稱>
9，重要的是，目標與Dockerfile中的-Xshareclasss中的cacheDir是同一目錄。
注意: 你希望共享類緩存多大取決於許多因素，包括以下注意事項：
是否僅在執行相同Java應用程序的容器之間共享它？
運行Java應用程序的任何Docker容器都將使用緩存嗎？
Java應用程序之間有多少共同點？
請查閱-Xshareclasses上的OpenJ9用戶文檔，以獲取有關運行和維護共享類緩存的實用程序方法的信息。
方法2：“預熱” Docker容器
我的同事Mike向我介紹了“預熱” Docker容器的方法。
通過預構建將在構建Docker映像時運行的Java應用程序來“預熱” Docker容器。 通過使用-Xshareclasss執行Java應用程序，可以預填充緩存並將其存儲在Docker映像中。 稍後運行Docker映像時，可以從預先存在的緩存中提取將要執行的Java應用程序。 爲此，我們將使用Docker RUN命令：
RUN /bin/bash -c 'java -Xshareclasses -Xscmx20M -jar batch-processor-0.0.1-SNAPSHOT.jar --run_type=short &' ; sleep 15 ; xargs kill -1
Show more設計RUN命令時有許多注意事項。 稍後我將對此進行更詳細的介紹。 但首先，讓我們比較一下使用Docker卷和預熱Docker容器的性能。
性能比較
爲了比較我之前描述的使用-Xshareclass的兩種不同方法的性能，我使用了一個爲OpenJ9演示創建的演示應用程序。 該演示是一個執行Spring Batch流程的Spring Boot應用程序，該流程正在對約200條記錄進行轉換。 如果你想了解有關應用程序正在執行的操作的更多詳細信息，請查看我的項目的自述文件。
依次運行三個容器：
“冷”容器是運行上述演示的Docker容器，但未打開類共享
“卷”容器，這是使用外部卷存儲類數據的Docker容器
“熱”容器使用上述方法預先用類數據預熱Docker映像
每個圖像運行了約30次，並收集了它們的運行時間和最大內存使用量，並在下圖中顯示。 我們來看看圖1和2中的圖表，以瞭解如何比較類共享方法。
圖1顯示了執行批處理應用程序花費了多長時間的結果。
圖1.折線圖，比較了每個Docker容器在大約30次運行中的執行時間
“暖”和“冷”容器都有兩個峯值。但是，總體而言，如趨勢線所示，它們的性能是相當一致的。這是可以預料的，因爲他們僅利用容器本身的內容。真正突出的是“體積”容器。
在我的演示中，我從一個空的緩存開始，這意味着“卷”容器不僅必須像“冷”容器那樣編譯類，而且還要將這些類寫入緩存。圖1中的圖表顯示了這些結果，從而導致相當大的吞吐量損失。 “冷”容器始終在大約9秒內完成執行，而“大容量”容器的初始運行花費了將近13秒。 （注意：未顯示，但我運行了使用空的緩存多次啓動“ volume”容器的場景，以驗證上面看到的結果。）
但是，雖然“體積”容器在第一次運行中要慢得多，但第二次運行卻與“溫暖”容器一樣快。這是有道理的，因爲“熱”容器在構建時也執行了一次批處理應用程序。
我最終對每個“卷”容器執行了更多的執行。 “冷”和“暖”的性能保持相當一致，“容積”容器繼續變得更好。這是因爲每次執行容器時，OpenJ9都會向緩存添加更多的類信息和JIT優化。第一次執行的好處是巨大的，而第三次執行容器時還有另一個明顯的顛簸（此後，好處卻停滯了）。與“溫暖”方法相比，“體積”方法隨着時間的推移確實繼續有所改善。
圖2中的圖表提供了更多有關權衡成本和缺點的分析，但讓我們首先看看另一個性能因素：內存使用情況。
爲了演示不同圖像之間的內存使用差異，我使用了一個盒子和晶須圖。在“晶須”中看到每次運行Docker容器時使用的最大和最小（換句話說，最小的最大）內存，而在“方框”中看到使用的中間50％內存。希望該圖表顯示了運行演示時發生的異常值，但也給出了預期的典型內存使用情況的想法。如此說來，讓我們分析圖2中的圖表。
圖2.盒子和鬍鬚圖，比較每個Docker容器的內存佔用量
通過類共享，你將顯着減少內存使用量。 如果沒有類共享，則“冷”容器的內存將達到140MB左右，峯值可能高達240MB。 “熱”和“大容量”容器的容量約爲125MB，從未超過150MB。
權衡不同的方法
一種方法並不比另一種方法完全好，在確定應爲組織使用哪種方法時，有許多因素需要考慮，其中有些因素不是上面描述的那麼好，或者僅僅是在本地計算機上測試而已。讓我們仔細考慮這些因素，以更好地瞭解這兩種方法在更現實的情況下的行爲。
我要介紹的第一個因素是延遲。我在本地計算機上運行了以上測試，因此我創建的卷與正在運行的Docker容器位於同一硬盤上。在雲環境中，情況並非總是如此。卷的邏輯位置在物理上獨立的計算機上時的額外延遲可能會對應用程序的啓動時間產生顯着影響。
對於使用預熱的卷，還需要考慮幾個因素。首先是與它們相關的額外存儲開銷。在我的示例中，預熱的Docker容器的大小爲390MB，而“冷”和“卷”對應的容器爲369MB。根據你的組織作爲Docker容器維護的服務數量以及圖像保留的時間長短，可能會導致存儲使用量顯着增加。也就是說，適當的修剪做法可以輕鬆解決此問題。
要考慮的另一個因素是正確預熱Docker容器可能需要一些工作。在我的演示中，我正在使用帶有預定義數據集的Spring Batch作業，因此我只是使用RUN命令簡單地執行了該作業的簡化版本。但是，大多數應用程序不是批處理作業。對於這些，需要更多的工作來模擬負載。否則，當JIT最初啓動時，它不會在緩存中提供許多優化。
我認爲這些因素都不是特別重要。如果你的性能標準非常嚴格，那麼它們可能在很大程度上變得非常重要。但是，通常來說，這些因素是需要克服的相對較小的技術障礙。
結論
在學習OpenJ9的短時間內，我迷上了它。 與Hotspot的性能相匹配的大量內存節省使OpenJ9真正令人興奮，並且交談和編寫都很有趣。
本文探討的類共享可進一步節省內存並改善啓動，並結合使用-Xquickstart等功能（有關更多信息，請參見OpenJ9用戶文檔），這使得OpenJ9對於無服務器功能非常有趣。 請繼續關注，我計劃在以後的文章中探討後者。
喜歡這篇文章的可以點個贊，歡迎大家留言評論，記得關注我，每天持續更新技術乾貨、職場趣事、海量面試資料等等
> 如果你對java技術很感興趣也可以交流學習，共同學習進步。
不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代
文章寫道這裏，歡迎完善交流。最後奉上近期整理出來的一套完整的java架構思維導圖，分享給大家對照知識點參考學習。有更多JVM、Mysql、Tomcat、Spring Boot、Spring Cloud、Zookeeper、Kafka、RabbitMQ、RockerMQ、Redis、ELK、Git等Java乾貨
