JVM内存管理需精细调优而非依赖自动回收：堆分代模型（新生代/老年代）、System.gc()仅为建议、Metaspace泄漏隐蔽性强，四者不匹配易致OOM或卡顿。
JVM 内存管理不是靠“自动回收”就万事大吉的，它把堆划成固定区域、对不同对象区别对待，GC 策略和参数稍调错，就会频繁 Full GC 或 OutOfMemoryError: Java heap space。
堆内存分代模型为什么必须理解
JVM 默认把堆（-Xms/-Xmx 指定的区域）分成新生代（Young Gen）和老年代（Old Gen），新生代又细分为 Eden、From Survivor、To Survivor。这个结构直接决定对象生命周期和 GC 行为：
- 新对象优先分配在
Eden区； - 一次
Minor GC后仍存活的对象，年龄+1，达到阈值（默认 15，由-XX:MaxTenuringThreshold控制）才晋升到老年代； - 大对象（如长数组）可能直接进老年代（受
-XX:PretenureSizeThreshold影响）； - 如果 Survivor 空间不够存放存活对象，会触发
担保失败（Handle Promotion Failure），直接把 Eden 中部分对象提前送入老年代。
System.gc() 调用后为什么不一定立刻回收
System.gc() 只是向 JVM 发出“建议”，是否执行、何时执行、用哪种 GC 算法，完全由 JVM 自行决定（尤其是开启 -XX:+DisableExplicitGC 时，该调用会被忽略）。常见误解是把它当“强制清理”用，结果：
WebChat Voice Proxy
下载
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
- 在 G1 或 ZGC 下基本无效果；
- 在 CMS 中可能触发一次
Concurrent Mode Failure； - 频繁调用反而干扰 GC 周期，导致 STW 时间变长；
- 真正需要控制时机的场景（如大文件导出后），应优先考虑对象及时置为
null、复用ByteBuffer、用try-with-resources保证释放。
元空间（Metaspace）泄漏比堆泄漏更隐蔽
JDK 8+ 用本地内存中的 Metaspace 替代永久代（PermGen），类定义、常量池、字段/方法信息都放这里。它不归堆 GC 管，而是靠类卸载（Class Unloading）——但前提是：该类的 ClassLoader 实例能被回收。所以真实泄漏常发生在：
立即学习“Java免费学习笔记（深入）”；
- OSGi、热部署框架（如 Spring Boot DevTools）、自定义
ClassLoader频繁加载/卸载类，但引用未清； - 使用
java.lang.reflect.Proxy或 CGLIB 动态生成大量代理类； -
-XX:MetaspaceSize设置过小（默认 21845K），导致频繁触发Metaspace GC，而实际类没卸载，最终抛OutOfMemoryError: Metaspace； - 查泄漏要用
jstat -gcmetacapacity <pid></pid>看MC/MU，配合jcmd <pid> VM.native_memory summary</pid>观察本地内存增长。
堆大小、GC 算法、元空间阈值、类加载行为——这四者只要一个配得不匹配业务对象生命周期，就容易在压测或上线后突然卡顿或 OOM。别只盯着 heap dump，GC log（加 -Xlog:gc*:file=gc.log:time）才是第一手证据。
