tag gc

標籤
貢獻19
66
12:49 PM · Nov 03 ,2025
jdcdevloper 頭像 lazytimes 頭像 dewujishu 頭像 aipaobudehoutao 頭像 codelogs 頭像 zzger 頭像 soroqer 頭像 alijishu 頭像 chanmufeng 頭像 chen_67f9ccbe6f07b 頭像 kimmking 頭像 edwardlee 頭像

@gc / 博客 RSS 訂閱

qinchuan_5d6e16e8918fd 頭像

秦川 - 關於 Go arena 的討論的學習

原因 目前 Go 的 GC 雖然高效，但是也是有代價的。 對於一些會有大量堆對象生成的場景，GC 相關的內存和CPU資源佔用，會導致服務吞吐量和相應速度受到影響。 因此需要一個效率更高且安全的內存管理機制，應對內存(GC)密集型的需求場景。 這也是個人長期以來對於 Go 的一個特別關注點。之前見過一些基於 mmap 系統內存自己管理的方案，但是很遺憾，這些方案看起來都很難真正的在項目中使用（接口複

protobuf , 內存管理 , gc , 內存分配 , go

收藏 評論

aipaobudehoutao 頭像

愛跑步的獼猴桃 - 垃圾回收機制：談談自己準備面試的時候一些理解

垃圾回收策略 1. JVM 垃圾回收策略機制描述 垃圾回收（GC）是JVM自動管理內存的一部分，用於釋放不再使用的對象所佔的內存空間。它的目標是： （1）提升內存的使用率 （2）減少開發者手動管理內存的複雜性 2. 垃圾回收的主要策略 JVM的GC策略圍繞分代收集理論展開，任務不同時期的對象適合不同方式的回收 （1）分代收集： 新生代垃圾回收採用 Minor GC（輕量級且頻繁）。

jvm , gc

收藏 評論

guguji_fly 頭像

咕咕雞 - 記一次線上FGC問題排查

引言 本文記錄一次線上 GC 問題的排查過程與思路，希望對各位讀者有所幫助。過程中也走了一些彎路，現在有時間沉澱下來思考並總結出來分享給大家，希望對大家今後排查線上 GC 問題有幫助。 背景 服務新功能發版一週後下午，突然收到 CMS GC 告警，導致單台節點被拉出，隨後集羣內每個節點先後都發生了一次 CMS GC，拉出後的節點垃圾回收後接入流量恢復正常（事後排查發現被重啓了）。 告警信息如下（已

性能優化 , jvm調優 , gc , JAVA

收藏 評論

dewujishu 頭像

得物技術 - 亞毫秒 GC 暫停到底有多香？JDK17+ZGC 初體驗｜得物技術

1 前言 垃圾回收器的暫停問題一直是Java工程師關注的重點，特別是對實時響應要求較高的服務來説，CMS和G1等主流垃圾回收器的數十毫秒乃至上百毫秒的暫停時間相當致命。此外，調優門檻也相對較高，需要對垃圾回收器的內部機制有一定的瞭解，才能夠進行有效的調優。 為了解決此類問題，JDK 11開始推出了一種低延遲垃圾回收器ZGC。ZGC使用了一些新技術和優化算法，可以將GC暫停時間控制在10毫秒以

jdk17 , gc

收藏 評論

bin_60080bc5146e1 頭像

bin的技術小屋 - 以 ZGC 為例，談一談 JVM 是如何實現 Reference 語義的

本文基於 OpenJDK17 進行討論 1. Reference 相關概念及其應用場景總覽 Reference（引用）是 JVM 中非常核心且重要的一個概念，垃圾回收器判斷一個對象存活與否都是圍繞着這個 Reference 來的，JVM 將 Reference 又細分為幾種具體的引用類型，它們分別是：StrongReference，SoftReference，WeakReference，Phan

jvm-hotspot , jvm虛擬機 , jvm , gc , JAVA

收藏 評論

jdcdevloper 頭像

京東雲開發者 - 給祖傳系統做了點 GC調優，暫停時間降低了 90% | 京東雲技術團隊

問題描述 公司某規則引擎系統，在每次發版啓動會手動預熱，預熱完成當流量切進來之後會偶發的出現一次長達1-2秒的Young GC（流量並不大，並且LB下的每個節點都會出現該情況） 在這次長暫停之後，每一次的年輕代GC暫停時間又都恢復在20-100ms以內 2秒雖然看起來不算長吧，但規則引擎每次執行也才幾毫秒，這誰能忍？而且這玩意一旦超時，出單可能也跟着超時失敗！ 問題分析 在分析該系統GC日誌後發現

jvm , jvm調優 , gc , JAVA , 後端

收藏 評論

jdcdevloper 頭像

京東雲開發者 - 線上問題處理案例：出乎意料的數據庫連接池 | 京東雲技術團隊

導讀 本文是線上問題處理案例系列之一，旨在通過真實案例向讀者介紹發現問題、定位問題、解決問題的方法。本文講述了從垃圾回收耗時過長的表象，逐步定位到數據庫連接池保活問題的全過程，並對其中用到的一些知識點進行了總結。 一、問題描述 大促期間，某接口超時次數增多，經排查直接原因是GC耗時過長，查看監控FullGC達500ms以上，接口超時時間與FullGC發生時間吻合。 圖1 FullGC耗時監控 二

MySQL , gc , 數據庫 , 連接池

收藏 評論

ynthia 頭像

桃瑾 - go-GC

併發三色標記法 三色：黑、灰、白 黑對象代表，對象自身存活，且其指向對象都已標記完成 灰對象代表，對象自身存活，但其指向對象還未標記完成 白對象代表，對象尙未被標記到，可能是垃圾對象 標記過程： 初始化：所有對象都被標記為白色 將根對象（全局對象、棧上局部變量等）置黑，將其所指向的對象置灰 從灰對象出發，將其所指向的對象都置灰. 所有指向對象都置灰後，當前灰對象置黑 標記結束後

gc , go

收藏 評論

jdcdevloper 頭像

京東雲開發者 - 頻繁 FullGC 的原因竟然是 “開源代碼”？ | 京東雲技術團隊

前言 首先java語言的特性是不需像C和C++那樣自己手動釋放內存，因為java本身有垃圾回收機制（垃圾回收稱為GC），顧名思義就是釋放垃圾佔用的空間，防止內存泄露。JVM運行時佔用內存最大的空間就是堆內存，另外棧區和方法區也會佔用空間但是佔用有限本章就不探究了。那麼堆中的空間又分為年輕代和老年代，所以我們粗略的把垃圾回收分為兩種：年輕代的垃圾回收稱為Young GC，老年代的垃圾回收稱為Full

jvm , gc , JAVA , 後端

收藏 評論

jdcdevloper 頭像

京東雲開發者 - 完蛋！我被 Out of Memory 包圍了！ | 京東雲技術團隊

是極致魅惑、灑脱自由的Java heap space？ 是知性柔情、温婉大氣的GC overhead limit exceeded？ 是純真無邪、活潑可愛的Metaspace？ 如果以上不是你的菜，那還有…… 刁蠻任性，無跡可尋的CodeCache！ 性感火辣、心思細膩的Direct Memory 高貴冷豔，獨愛你一人的OOM Killer！ 總有一款，能讓你鍾情！BUG 選擇權

gc , 內存泄漏 , Linux , JAVA , 後端

收藏 評論

labilezhu 頭像

MarkZhu - eBPF 求證坊間傳聞：Java GC 日誌可導致整個 JVM 服務卡頓？

概述 實現世界的 Java 應用，都會記錄 GC 日誌。但不是所有人都知道小小的日誌可能導致整個 JVM 服務卡頓。本文嘗試用 eBPF 等分析方法，去證明具體環境下，問題的存在與否。 審誤和發佈本文時，我才是二陽後活過來數小時而已，寫了數週的文章實在不想再拖延發布了。如文章有錯漏，還請多多包涵和指正。 引 Java 服務卡頓，是 Java 世界永恆的話題之王。想到 Java 卡頓，大部分人的第一

jvm , gc

收藏 評論

lazytimes 頭像

阿東 - 【Java】GC Logging – user, sys, real – which time to use

Source GC Logging – user, sys, real – which time to use? Gandhi In the Garbage Collection log file, 3 types of time are reported for every single GC event: 在垃圾回收日誌文件中，每個 GC 事件都會報告 3 種類型的時間： ‘user’

gc

收藏 評論

jdcdevloper 頭像

京東雲開發者 - 淺析JVM GC配置指南 | 京東雲技術團隊

本文旨在簡明扼要説明各回收器調優參數，如有疏漏歡迎指正。 1、JDK版本 以下所有優化全部基於JDK8版本，強烈建議低版本升級到JDK8，並儘可能使用update_191以後版本。 2、如何選擇垃圾回收器 響應優先應用：面向C端對響應時間敏感的應用，堆內存8G以上建議選擇G1，堆內存較小或低版本JDK選擇CMS； 吞吐量優先應用：對響應時間不敏感，以高吞吐量為目標的應用（如MQ、Worker），建

jvm , jvm調優 , gc

收藏 評論

pingcap 頭像

PingCAP - TiDB 組件 GC 原理及常見問題

導讀 本文詳細介紹了 TiDB 的 Garbage Collection（GC）機制及其在 TiDB 組件中的實現原理和常見問題排查方法。 TiDB 底層使用單機存儲引擎 RocksDB，並通過 MVCC 機制，基於 RocksDB 實現了分佈式存儲引擎 TiKV，以支持高可用分佈式事務。 GC 過程旨在清理舊數據，減少其對性能的影響，主要包括四個步驟： 計算 GC safepoint、解析鎖（R

gc , 數據庫 , tidb

收藏 評論

jdcdevloper 頭像

京東雲開發者 - 從歷代GC算法角度刨析ZGC

作者：京東科技 文濤 前言 本文所有介紹僅限於HotSpot虛擬機， 本文先介紹了垃圾回收的必要手段，基於這些手段講解了歷代垃圾回收算法是如何工作的， 每一種算法不會講的特別詳細，只為讀者從算法角度理解工作原理，從而引出ZGC，方便讀者循序漸進地瞭解。 GC 是 Garbage Collection 的縮寫，顧名思義垃圾回收機制，即當需要分配的內存空間不再使用的時候，JVM 將調用垃圾回收機制來回

jvm , 算法 , gc , 垃圾回收 , 後端

收藏 評論

jdcdevloper 頭像

京東雲開發者 - 談JVM參數GC線程數ParallelGCThreads合理性設置

作者：京東零售 劉樂 1. ParallelGCThreads參數含義 在講這個參數之前，先談談JVM垃圾回收(GC)算法的兩個優化標的：吞吐量和停頓時長。JVM會使用特定的GC收集線程，當GC開始的時候，GC線程會和業務線程搶佔CPU時間，吞吐量定義為CPU用於業務線程的時間與CPU總消耗時間的比值。為了承接更大的流量，吞吐量越大越好。 為了安全的垃圾回收，在GC或者GC某個階段，所有業務線程都

jvm調優 , parallels-tools , gc , 線程 , JAVA

收藏 評論

jinyeyoudianerliang 頭像

今夜有點兒涼 - GC的三種收集方法詳解

GC的三種收集方法詳解 1. 標記-清除算法 (Mark-Sweep) 原理 標記階段：從根對象（GC Roots）開始，標記所有可達的對象 清除階段：掃描整個內存區域，回收所有未被標記的對象 特點 優點：實現簡單，不需要對象移動 缺點： 產生內存碎片，導致大對象可能無法找到連續內存空間而提前觸發Full GC 標記和清除兩個階段都需要掃描整個堆內存，效率較低

算法 , gc , 垃圾回收

收藏 評論

chanmufeng 頭像

蟬沐風 - 我是一個垃圾

噠噠噠...... 回收者的腳步聲越來越清晰，我竭力鎖緊身體讓自己別那麼引人注目，儘管氣喘吁吁，但我仍然壓抑住自己的呼吸。 終歸是藏不住的，但是多活個幾毫秒也是好的，我們都這麼想。 因為回收者是來殺我們的。 第0回 我是一個垃圾 我是一個垃圾，至少我的主人是這麼喊我的。 我不知道自己做錯了什麼，甚至不知道自己做了什麼。 我只是被他創造了出來，然後被挪來挪去，我的一生都在漂泊。 聽説C帝國的朋友都是

jvm , gc , 垃圾回收

收藏 評論

lazytimes 頭像

阿東 - 【Java】Garbage Collection Logging to a File in Java

原文 https://www.baeldung.com/java-gc-logging-to-file 1. Overview Garbage collection is a marvel of the Java programming language providing us with automatic memory management. 垃圾回收是 Java 編程語言的一個奇蹟，它為我們

gc , JAVA

收藏 評論

zzger 頭像

我不是碼農 - 記錄一次使用線程池調用kafka發送消息產生的內存泄漏問題

在需求實現裏，我需要把持久化在數據庫中的對象一直往kafka裏發送，然後由flink進行消費，把當前的對象和存儲的用户軌跡記錄等等信息進行比對，如果比對成功則觸發 最開始我是通過單線程發送，發現發送速度有點慢，這裏面我需要把對象做一些處理（比如split,flat,fitler）後才發送到kafka，大概30w+的對象需要十多分鐘那邊才能預警到，於是開始進行性能優化，使用並行流進行處理，改變

gc , 多線程 , JAVA , 內存溢出

收藏 評論

jdcdevloper 頭像

京東雲開發者 - 當小白遇到FullGC | 京東雲技術團隊

起初沒有人在意這場GC,直到它影響到了每一天! 前言 本文記錄了一次排查FullGC導致的TP99過高過程,介紹了一些排查時思路,線索以及工具的使用,希望能夠幫助一些新手在排查問題沒有很好的思路時,提供一些思路,讓小白也能輕鬆解決FullGC問題,文中實際提到的參數配置不一定適合其他業務場景,在調優自己的項目時還是需要實際試驗過才能得出最佳參數配置 我也是小白,如有不合理的地方,歡迎大佬們進行指正

full-stack , gc , JAVA , 後端

收藏 評論

dewujishu 頭像

得物技術 - ZGC關鍵技術分析

一、引言 垃圾回收對於Javaer來説是一個繞不開的話題，工作中涉及到的調優工作也經常圍繞垃圾回收器展開。面對不同的業務場景沒有一個統一的垃圾回收器能保證可GC性能。因此對程序員來説不僅要會編寫業務代碼，同時也要卷一下JVM底層原理和調優知識。這種局面可能因為ZGC的出現而發生改變，新一代回收器ZGC幾乎不需要調優的情況下GC停頓時間可以降低到亞秒級。 Oracle從JDK11開始正式引入ZGC，

gc , 高性能 , JAVA

收藏 評論

soroqer 頭像

soroqer - []A 與 []*A 的內存分配、生命週期-Golang 🔥

一、內存分配 無論 []A 還是 []*A，切片本身的元數據（切片頭）結構是完全相同的。切片頭是一個包含 3 個字段的結構體： ptr：指向底層數組的指針（8 字節）。 len：切片長度（8 字節）。 cap：切片容量（8 字節）。 因此，切片頭本身佔用的內存大小 24 字節，內存完全一致。 切片的核心是底層數組，內存分配的核心差異源於底層數組的元素類型：[]A 存儲完整結構體實例，[]

生命週期 , slice , gc , 指針 , go

收藏 評論

jdcdevloper 頭像

京東雲開發者 - Java21上手體驗-分代ZGC和虛擬線程 | 京東雲技術團隊

一、導語 幾天前Oracle剛剛發佈了Java21， 由於這是最新的LTS版本，引起了大家的關注。 我也第一時間在個人項目中進行了升級體驗。 一探究竟，和大家分享。 二、Java21更新內容介紹 官方release公告： https://jdk.java.net/21/release-notes 開源中國介紹： https://my.oschina.net/waylau/blog/10

java21 , gc , 線程 , JAVA , 後端

收藏 評論