日日操夜夜添-日日操影院-日日草夜夜操-日日干干-精品一区二区三区波多野结衣-精品一区二区三区高清免费不卡

。定位到根本原因，每個表達式都是一個類中一個方法。隨著運行時間越長，執行次數增加，這些方法會被JIT優化編譯進入到Code Cache中，導致CodeCache越來越大。

解決方法：JIT有一些參數配置可以調整JIT編譯的條件，但對于我們的問題都不太適用。我們最終通過業務優化解決，刪除不需要執行的Aviator表達式，從而避免了大量Aviator方法進入CodeCache中。

值得一提的是，我們并不是在所有這些問題都解決后才全量部署所有集群。即使開始有各種各樣的毛刺，但計算后發現，有各種問題的ZGC也比之前的CMS對服務可用性影響小。所以從開始準備使用ZGC到全量部署，大概用了2周的時間。在之后的3個月時間里，我們邊做業務需求，邊跟進這些問題，最終逐個解決了上述問題，從而使ZGC在各個集群上達到了一個更好表現。

升級ZGC效果

延遲降低

| TP（Top Percentile）是一項衡量系統延遲的指標：TP999表示99.9%請求都能被響應的最小耗時；TP99表示99%請求都能被響應的最小耗時。

在Zeus服務不同集群中，ZGC在低延遲（TP999 < 200ms）場景中收益較大：

• TP999：下降12~142ms，下降幅度18%~74%。

• TP99：下降5~28ms，下降幅度10%~47%。

超低延遲（TP999 < 20ms）和高延遲（TP999 > 200ms）服務收益不大，原因是這些服務的響應時間瓶頸不是GC，而是外部依賴的性能。

吞吐下降

對吞吐量優先的場景，ZGC可能并不適合。例如，Zeus某離線集群原先使用CMS，升級ZGC后，系統吞吐量明顯降低。究其原因有二：第一，ZGC是單代垃圾回收器，而CMS是分代垃圾回收器。單代垃圾回收器每次處理的對象更多，更耗費CPU資源；第二，ZGC使用讀屏障，讀屏障操作需耗費額外的計算資源。

總結

ZGC作為下一代垃圾回收器，性能非常優秀。ZGC垃圾回收過程幾乎全部是并發，實際STW停頓時間極短，不到10ms。這得益于其采用的著色指針和讀屏障技術。

Zeus在升級JDK 11+ZGC中，通過將風險和問題分類，然后各個擊破，最終順利實現了升級目標，GC停頓也幾乎不再影響系統可用性。

最后推薦大家升級ZGC，Zeus系統因為業務特點，遇到了較多問題，而風控其他團隊在升級時都非常順利。

參考文獻

• ZGC官網

• 彭成寒.《新一代垃圾回收器ZGC設計與實現》. 機械工業出版社, 2019.

• 從實際案例聊聊JAVA應用的GC優化

• Java Hotspot G1 GC的一些關鍵技術

附錄

如何使用新技術

在生產環境升級JDK 11，使用ZGC，大家最關心的可能不是效果怎么樣，而是這個新版本用的人少，網上實踐也少，靠不靠譜，穩不穩定。其次是升級成本會不會很大，萬一不成功豈不是白白浪費時間。所以，在使用新技術前，首先要做的是評估收益、成本和風險。

評估收益

對于JDK這種世界關注的程序，大版本升級所引入的新技術一般已經在理論上經過驗證。我們要做的事情就是確定當前系統的瓶頸是否是新版本JDK可解決的問題，切忌問題未診斷清楚就采取措施。評估完收益之后再評估成本和風險，收益過大或者過小，其他兩項影響權重就會小很多。

以本文開頭提到的案例為例，假設GC次數不變（10次/分鐘)，且單次GC時間從40ms降低10ms。通過計算，一分鐘內有100/60000 = 0.17%的時間在進行GC，且期間所有請求僅停頓10ms，GC期間影響的請求數和因GC增加的延遲都有所減少。

評估成本

這里主要指升級所需要的人力成本。此項相對比較成熟，根據新技術的使用手冊判斷改動點。跟做其他項目區別不大，不再具體細說。

在我們的實踐中，兩周時間完成線上部署，達到安全穩定運行的狀態。后續持續迭代3個月，根據業務場景對ZGC進行了更契合的優化適配。

評估風險

升級JDK的風險可以分為三類：

• 兼容性風險：Java程序JAR包依賴很多，升級JDK版本后程序是否能運行起來。例如我們的服務是從JDK 7升級到JDK 11，需要解決較多JAR包不兼容的問題。

• 功能風險：運行起來后，是否會有一些組件邏輯變更，影響現有功能的邏輯。

• 性能風險：功能如果沒有問題，性能是否穩定，能穩定的在線上運行。

經過分類后，每類風險的應對轉化成了常見的測試問題，不再屬于未知風險。風險是指不確定的事情，如果不確定的事情都能轉化成可確定的事情，意味著風險已消除。

升級JDK 11

選擇JDK 11，是因為在JDK 11中首次支持ZGC，而且JDK 11屬于長期支持（Long Term Support，LTS）版本，至少會被維護三年，普通版本（如JDK 12、JDK 13和JDK 14）只有6個月的維護周期，不建議使用。

本地測試環境安裝

從兩個源OpenJDK和OracleJDK下載JDK 11，二個版本的JDK主要區別是長時期的免費和付費，短期內都免費。注意JDK 11版本中的ZGC不支持mac OS系統，在Mac OS系統上使用JDK 11只能用其他垃圾回收器，如G1。

生產環境安裝

升級JDK 11不僅僅是升級自己項目的JDK版本，還需要編譯、發布部署、運行、監控、性能內存分析工具等項目支持。美團內部的實踐：

編譯打包：美團發布系統支持選擇JDK 11進行編譯打包。

線上運行 & 全量部署：要求線上機器已安裝JDK 11，有3種方式：

1. 新申請默認安裝JDK 11的虛擬機：試用JDK 11時可用這種方式；全量部署時，如果新申請機器數量過多，可能沒有足夠機器資源。

2. 通過手寫腳本給存量虛擬機安裝JDK 11：不推薦，業務同學過多參與到運維當中。

3. 使用容器提供的鏡像部署功能，在打包鏡像時安裝JDK 11：推薦方式，不需要新申請資源。

監控指標：主要是GC的時間和頻率，我們通過美團的CAT監控系統支持ZGC數據的收集（CAT已開源）。

性能內存分析：線上遇到性能問題時，還需要借助Profiling工具，美團的性能診斷優化平臺Scalpel已支持JDK 11的性能內存分析。如果你的公司沒有相關工具，推薦使用JProfier。

解決組件兼容性

我們的項目包含二十多萬行代碼，需要從JDK 7升級到JDK 11，依賴組件眾多。雖然看起來升級會比較復雜，但實際只花了兩天時間即解決了兼容性問題。具體過程如下：

1. 編譯，需要修改pom文件中的build配置，根據報錯作修改，主要有兩類：

a. 一些類被刪除：比如“sun.misc.BASE64Encoder”，找到替換類java.util.Base64即可。

b. 組件依賴版本不兼容JDK 11問題：找到對應依賴組件，搜索最新版本，一般都支持JDK 11。

2. 編譯成功后，啟動運行，此時仍有可能組件依賴版本問題，按照編譯時的方式處理即可。

升級所修改的依賴：

<dependency>
<groupId>javax.annotation</groupId>
<artifactId>javax.annotation-api</artifactId>
<version>1.3.2</version>
</dependency>
<dependency>
<groupId>javax.validation</groupId>
<artifactId>validation-api</artifactId>
<version>2.0.1.Final</version>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.18.4</version>
</dependency>
<dependency>
<groupId>org.hibernate.validator</groupId>
<artifactId>hibernate-validator-parent</artifactId>
<version>6.0.16.Final</version>
</dependency>
<dependency>
<groupId>com.sankuai.inf</groupId>
<artifactId>patriot-sdk</artifactId>
<version>1.2.1</version>
</dependency>
<dependency>
<groupId>org.Apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
<version>3.9</version>
</dependency>
<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
<version>2.6</version>
</dependency>
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-all</artifactId>
<version>4.1.39.Final</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
</dependency>

JDK 11已經出來兩年，常見的依賴組件都有兼容性版本。但是，如果是公司內部提供的公司級組件，可能會不兼容JDK 11，需要推動相關組件進行升級。如果對方升級較為困難，可以考慮拆分功能，將依賴這些組件的功能單獨部署，繼續使用低版本JDK。隨著JDK 11的卓越性能被大家悉知，相信會有更多團隊會用JDK 11解決GC問題，使用者越多，各個組件升級的動力也會越大。

驗證功能正確性

通過完備的單測、集成和回歸測試，保證功能正確性。

---------- END ----------

招聘信息

看完文章的你，如果內心燃起了想與筆者一起共事的沖動，不要猶豫，直接把簡歷砸過來！團隊正在尋同道中人，詳細崗位介紹如下，歡迎大家踴躍自薦、推薦！

資深Java工程師（風控方向）

工作城市：北京、上海

崗位職責：

1. 負責開發高并發高可用低延時的風控系統 ，對現有產品和系統進行改進和優化。從業務和技術出發，實現面向未來的系統規劃、設計和落地。

2. 獨立完成較復雜的系統分析、設計，并主導完成詳細設計和編碼的任務，確保項目的進度和質量。

3. 在團隊中完成Code Review任務，確保相關代碼的有效性和正確性，并能夠通過Code Review提供相關性能以及穩定性的建議。

4. 技術預研和技術難點攻關，保障系統可用性、穩定性、和可擴展性。

任職要求：

1. 扎實的Java編程基礎，良好的編程素養，對代碼美感有追求。

2. 熟悉分布式系統和架構，對高性能、高可用架構的最佳實踐以及設計原則有理解。

3. 精通微服務、一致性等分布式技術；對互聯網常用技術有深入的了解，對開源產品本身有過開發經驗者。

4. 對技術有激情，喜歡鉆研，能快速接受和掌握新技術，有較強的獨立、主動的學習能力，良好的溝通表達能力和團隊協作能力。

5. 具備系統調試、性能調優等技能，對疑難技術問題具備較強的排查能力；有強烈的責任心和使命感。

6. 具備大規模、高吞吐量的系統開發實踐經驗。

歡迎發送簡歷至：sunny.fang@dianping.com。郵件主題請注明（城市-美團技術團隊公眾號）

此外，美團信息安全部更多職位持續開放中，虛位以待，就等你來！具體崗位介紹，歡迎大家點擊【閱讀原文】了解！

GIAC 全球互聯網架構大會 2020 將于 8 月 14 - 15 日在深圳舉行，本屆 GIAC 議題共設置有 24 個專題，大會包含

技術原創及架構實踐文章，歡迎通過公眾號菜單「聯系我們」進行投稿。

高可用架構

改變互聯網的構建方