亚洲乱码卡一卡二卡三永久-亚洲乱码一二三四区-亚洲乱码一区二区三区在线观看-亚洲伦理一区-成人在色线视频在线观看免费大全-成人在线91

云原生雖沒有限定的編程語言，但應(yīng)用所使用的編程語言已經(jīng)決定了應(yīng)用部署運行的行為。

Java 誕生于20年前，擁有大量優(yōu)秀的企業(yè)級框架，踐行 OOP 理念，更多體現(xiàn)的是嚴謹以及在長時間運行條件下的穩(wěn)定性和高性能。反觀如今，在要求快速迭代交付的云場景下，語言的簡單性似乎成了首要的要求，而傳統(tǒng)的 Java 語言顯得有一些過于重量了。

ElasticHeap

Java 常因為耗資源而受詬病，其中最顯著一點就是 Heap 對內(nèi)存的占用，即便沒有請求在處理也沒有對象分配，進程仍然會保留完整的堆內(nèi)存空間，保障 GC 進行分配內(nèi)存和操作內(nèi)存的快速敏捷。

AJDK ZenGC/ElasticHeap 雙十一全面支持核心鏈路上百應(yīng)用和數(shù)十萬實例。

JDK12 開始支持固定時間的觸發(fā) concurrent mark 并在 remark 中收縮 Java 堆歸還內(nèi)存的功能，然而并未解決在 stw 中增加暫停時間的問題，因此無法在每次 young GC 時做內(nèi)存歸還。ElasticHeap 在并發(fā)異步線程中完成內(nèi)存處理反復(fù) map/unmap 以及 page fault 的開銷，因此任意一次 young GC 都可以敏捷的及時歸還內(nèi)存，或重新恢復(fù)內(nèi)存使用。

ElasticHeap 阿里巴巴實戰(zhàn)

ElasticHeap場景1：可預(yù)測的流量高峰

ElasticHeap 場景 2 ：單機運行多個 Java 實例

多個 Java 實例接受的流量任務(wù)較為隨機，峰值不會重疊，在閑時可以有效降低多個實例整體的內(nèi)存占用，提高部署密度。

雙11驗證核心交易系統(tǒng)使用 ElasticHeap 進行低功耗模式運行，大幅降低 WSS(Working Set Size) 規(guī)模的實例。

靜態(tài)編譯

很多云上的新應(yīng)用不約而同地選擇了 Go 語言，很大的原因是 Go 應(yīng)用對運行時沒有依賴，靜態(tài)編譯的程序啟動速度快，也不需要通過 JIT 來預(yù)熱。在阿里有大量 Java 代碼的前提下，我們是如何為 Java 注入這方面的能力的呢？

Java 靜態(tài)編譯技術(shù)是一種激進的 AOT 技術(shù)，通過單獨的編譯階段將 Java 程序編譯為本地代碼，在運行時無需傳統(tǒng) Java 虛擬機和運行時環(huán)境，只需操作系統(tǒng)類庫支持即可。其工作基本原理如下圖所示。靜態(tài)編譯技術(shù)實現(xiàn)了 Java 語言與原生 native 程序的“合體”，將原本的 Java 程序編譯成為了一個自舉的具有 Java 行為的原生 native 程序，由此兼有 Java 程序和原生 native 程序的優(yōu)點。

JVM 團隊與 SOFAStack 團隊密切合作，在中間件應(yīng)用上率先實現(xiàn)靜態(tài)編譯的落地。將一個應(yīng)用的啟動速度從 60 秒優(yōu)化到 3.8 秒，雙十一期間靜態(tài)編譯的應(yīng)用運行穩(wěn)定，沒有故障， GC 停頓時間在 100 毫秒，在業(yè)務(wù)允許范圍之內(nèi)，內(nèi)存占用和 RT 與傳統(tǒng) Java 應(yīng)用持平。

綜上所述，靜態(tài)編譯的應(yīng)用在穩(wěn)定性、資源占用、RT 響應(yīng)等各方面指標與傳統(tǒng) Java 應(yīng)用基本持平的狀況下，將啟動時間降低了 2000% 。

Wisp2

當(dāng)你用時下最酷炫的 Vert.X 開發(fā)一個簡單的 Web 服務(wù)，準備體驗一下最強的性能， QA 同學(xué)拿來一臺 1C 2G 的容器讓你壓一下，你卻發(fā)現(xiàn)你怎么也拼不過別人 Go 應(yīng)用。研究之后發(fā)現(xiàn)，原來協(xié)程模型在這樣的少核心的情況下性能要好很多。是時代變了， Java 落伍了？

AJDK Wisp2 回答了這個問題：Java 同樣可以擁有高性能的協(xié)程。今年是 Wisp2 大規(guī)模上線的第一年， Wisp2 具有如下特點:

在整個Java runtime中支持了協(xié)程調(diào)度，線程阻塞會變成更輕量的協(xié)程切換。

如 Socket.getInputStream().read() 

完全兼容 Thread API ，在開啟 Wisp2 的 JDK 中，Thread.start() 實際創(chuàng)建的是一個協(xié)程(輕量級線程)，可以類比 Go 只提供協(xié)程關(guān)鍵字 go 而沒有暴露線程接口；我們同樣只提供創(chuàng)建協(xié)程的方式，應(yīng)用可以透明切換到協(xié)程。

支持 work stealing ，調(diào)度策略特別適合 web 場景，在高壓力下調(diào)度開銷極小。

在今年雙十一， Wisp 支持了上百應(yīng)用，十萬級容器，其中 90% 的容器已經(jīng)升級到 Wisp2 。

我們可以看到峰值附近， Wisp2 機器的 CPU 要低 7%( Wisp1 更低，Wisp2的取向是 RT ，因此 CPU 會高一些)左右，這主要是輕量級調(diào)度所節(jié)省的 sys CPU 。0 點的 CPU 是相等的，這也說明一點：Wisp2 解決的是調(diào)度開銷，當(dāng) CPU 低，調(diào)度沒有壓力時是看不出差距的。

從 RT 角度看， Wisp2 機器的 RT 要低 20% 左右， RT 減少明顯的一個原因是這批機器的 CPU 壓力很大，協(xié)程的調(diào)度優(yōu)勢更容易體現(xiàn)出來。這樣的優(yōu)勢可以幫助系統(tǒng)摸高到更高的水位，整體地提高利用率而擔(dān)心 RT 過高導(dǎo)致系統(tǒng)雪崩。

FDO

雙十一正零點相對后面幾分鐘會有一個明顯的 CPU 峰值，根據(jù)數(shù)據(jù)分析，主要原因是雙十一零點觸發(fā)了 JIT 編譯。舉個例子，程序里有邏輯:

假設(shè)預(yù)熱時一直在走 branch2 ，那么 JIT 有理由相信后續(xù)基本也都會走 branch2 ，而不會對 branch1編譯。在零點時，我們進入 branch1 ，此時就需要觸發(fā)退優(yōu)化重新編譯方法。我們來看 AJDK 如何通過 profiling 解決這個問題。

退優(yōu)化原理及其危害

JDK 運行代碼的時候，采用分層編譯的方式對 Java 方法進行動態(tài)編譯。在最高等級(峰值性能最好)的編譯中，出于性能的考慮，編譯的時候會根據(jù)收集的信息做一些比較樂觀的假設(shè)，一旦這些假設(shè)條件不滿足了，就會出現(xiàn)退優(yōu)化的現(xiàn)象。

比如某個熱點方法中某段代碼僅會在雙十一中執(zhí)行，那么在預(yù)熱過程中這段代碼不會被編譯，雙十一到來時這段代碼一旦被執(zhí)行，就會觸發(fā)整個方法的退優(yōu)化。

發(fā)生退優(yōu)化有兩個方面的負面影響，一是需要運行的方法由高效率的編譯執(zhí)行變成了解釋執(zhí)行，運行速度降低百倍以上；二是流量高峰期退優(yōu)化的方法會很快被重新編譯，編譯線程會消耗 CPU 。因此在雙十一這種流量短時間劇增且與預(yù)熱流量不太一樣的場景下，退優(yōu)化的危害會特別明顯。

通過 FDO 減少退優(yōu)化

FDO 是 feedback directed optimization 的縮寫，即參考以往 JVM 運行時的編譯信息，指導(dǎo)本次運行時進行更好的編譯。具體的，我們采用了兩個層面的方法來減少退優(yōu)化。

將每次運行時的退優(yōu)化信息記錄到文件中，下次運行時讀取這個文件，在決定是否做樂觀假設(shè)的時候參考文件中的信息做判斷，從而減少退優(yōu)化的概率。

信息顯示出現(xiàn)最多的退優(yōu)化與 if-else 相關(guān)，占總數(shù)量的一半以上。我們提供了一個方法根據(jù)以往出現(xiàn) if-else 退優(yōu)化的信息，關(guān)閉某個路徑上所有相關(guān)的樂觀假設(shè)。

雙十一中 FDO 的效果

FDO 今年雙十一上線，目標解決兩個問題：

雙十一 0 點流量高峰和退優(yōu)化/編譯高峰疊加造成的 CPU 使用率脈沖過高。

預(yù)熱效率低，壓測經(jīng)過前長時間預(yù)熱后，增大流量時仍然伴隨著大量的編譯及退優(yōu)化。

針對第一個問題，我們收集了雙十一高峰第一分鐘的退優(yōu)化／C2 編譯次數(shù)以及 CPU 數(shù)據(jù)。

可見開啟 FDO 后高峰期 C2 編譯數(shù)目減少約 45% ，退優(yōu)化數(shù)目減少約 70% 。

CPU 數(shù)據(jù)上，高峰期第一分鐘內(nèi)開啟 FDO 后 CPU 由約 67.5 降低到 63.1 ，降低約 7.0% 。

第二個目標可以通過壓測第一分鐘的 CPU 數(shù)據(jù)驗證。

開啟 FDO ，壓測第一分鐘 CPU 使用率由 66.19 降低到 60.33% ，降低約 10% 。

Grace

ZProfiler 一直是全集團排查 Java 應(yīng)用各類問題的利器，而 Grace 作為其平臺化的版本，對其實施了一系列的優(yōu)化，從原來的單機版本到現(xiàn)在的 Master/Worker 架構(gòu)，同時引入了任務(wù)排隊機制，在高壓力情況下對用戶的任務(wù)進行排隊從而解決 Worker 不堪重負的問題。在可維護性、拓展性、以及用戶體驗上得到了質(zhì)的提升，為后續(xù)工具平臺的上云、開源事項打下了夯實的基礎(chǔ)。

目前已經(jīng)集成了 Heap Dump 功能，在繼承 ZProfiler 功能的基礎(chǔ)上做了一定的優(yōu)化，提升了解析引擎的版本，支持更全面的 OQL 語法等等。

JDK11

JDK8 作為一個經(jīng)典版本，正被大規(guī)模使用，雖然從 JDK6 和 7 遷移上來有一定的陣痛，但是升級后普遍的反饋是：“真香”。

OpenJDK 8的下一個穩(wěn)定版本是 OpenJDK 11 。JVM 團隊自然會在這個方向上積極跟進，目前 AJDK11 支持了 AJDK8 的 Wisp2 、多租戶特性。本次雙十一的部分集群已經(jīng)上線到 JDK11 ，表現(xiàn)穩(wěn)定。

升級 JDK11 是否會和升級 JDK8 一樣給我們帶來同樣的的驚喜呢？在 JDK11 上我們可以體驗到最新的 ZGC 。

ZGC

JDK11 引入了一個重要特性：ZGC 內(nèi)存垃圾回收器。這個垃圾回收器號稱能夠在幾十 GB 至若干 TB 的堆上把暫停時間保持在 10ms 以內(nèi)。許多 Java 開發(fā)者苦于過去的垃圾回收器的暫停時間帶來延遲， ZGC 短暫停的特性未來無疑會成為 Java 開發(fā)者的新寵。

目前 ZGC 在 OpenJDK 中仍然處于實驗特性，而且 JDK11 尚未在產(chǎn)業(yè)界完全普及， JDK11 只支持 Linux 上的 ZGC（ MacOS 和 Windows 的 ZGC 預(yù)計在 2020 年 3 月發(fā)布的 JDK14 版本才會支持），許多 Java 開發(fā)者仍然只能垂涎欲滴，處于觀望狀態(tài)。

向來敢于吃螃蟹的我們豈能望而卻步？阿里 JVM 團隊和數(shù)據(jù)庫團隊已經(jīng)開始讓數(shù)據(jù)庫應(yīng)用運行在 ZGC 上，并根據(jù)運行的效果對 ZGC 進行了相應(yīng)的改進工作，包括 ZGC 的頁緩存機制優(yōu)化、ZGC的觸發(fā)時機優(yōu)化等等。

從 9 月開始，兩個團隊推動線上數(shù)據(jù)庫應(yīng)用在 ZGC 上運行，目前已經(jīng)穩(wěn)定運行兩個月，并順利通過雙十一大考。線上反饋的效果可喜可賀：

JVM 暫停時間保持在官方的 10ms 以內(nèi)；

ZGC 大大改善了線上運行集群的平均 RT 與毛刺指標。

小結(jié)

從上述的功能特性可以看到 AJDK 已經(jīng)從一個傳統(tǒng)的 Managed Runtime 脫胎換骨。今后 AJDK 將繼續(xù)致力于提高云上的應(yīng)用的開發(fā)體驗，通過底層的創(chuàng)新為上層應(yīng)用提供更多的可能。

在 Dragonwell 上使用 AJDK 功能

上述的這些經(jīng)過雙十一考驗的功能都將隨著 Dragonwell 陸續(xù)開源和交付到廣大用戶手中，敬請關(guān)注。

AlibabaDragonwell8是一款免費的OpenJDK發(fā)行版。它提供長期支持，包括性能增強和安全修復(fù)。Alibaba Dragonwell 8 目前支持 X86-64/Linux 平臺，在數(shù)據(jù)中心大規(guī)模 Java 應(yīng)用部署情況下， 可以大幅度提高穩(wěn)定性、效率以及性能。

AlibabaDragonwell8是OpenJDK 的下游，使用了和 OpenJDK 一樣的 license。Alibaba Dragonwell 8 與 Java SE 標準兼容，用戶可以使用 Alibaba Dragonwell 8 開發(fā)和運行 Java 應(yīng)用程序。

此次開源的 Alibaba Dragonwell 8 是阿里巴巴內(nèi)部 OpenJDK 定制版 AJDK 的開源版本， AJDK 為在線電商，金融，物流做了結(jié)合業(yè)務(wù)場景的優(yōu)化，運行在超大規(guī)模的，1,000,000+ 服務(wù)器的阿里巴巴數(shù)據(jù)中心。

近期我們正在緊密籌備 Alibaba Dragonwell 11 的 release 。Dragonwell 11 是基于 OpenJDK 11 的 Dragonwell 發(fā)行版本，擁有更多特性，可以更多地為云上場景賦能，模塊化更加清晰，并將獲得長期的支持，因此推薦大家關(guān)注和適時升級。