3. JVM内存模型基础：堆、栈、元空间、直接内存与GC机制对Collector的影响
Collector作为常驻Java进程，其内存布局直接决定SLI采集的稳定性与延迟。理解JVM各内存区域的作用及GC行为，是调优Collector内存参数的前提。本章从内存分区、GC交互、直接内存三个维度展开，并给出Collector场景下的关键结论。
3.1 JVM运行时数据区全景
JVM将内存划分为线程私有与线程共享两大区域。Collector的采集线程、上报线程、指标聚合线程各自拥有独立的栈与程序计数器，而堆与元空间则由所有线程共享。
| 区域 | 线程归属 | 存储内容 | Collector典型问题 |
|---|---|---|---|
| 堆（Heap） | 共享 | 采集指标对象、缓存、上报队列 | GC暂停导致采集延迟抖动 |
| 栈（Stack） | 私有 | 方法调用帧、局部变量 | 深度采集链导致StackOverflow |
| 元空间（Metaspace） | 共享 | 类定义、方法内联缓存、常量池 | 动态类加载过多触发Full GC |
| 直接内存（Direct Memory） | 共享 | Netty ByteBuf、堆外缓存 | 未及时释放导致OOM（无法被GC直接回收） |
| 程序计数器（PC） | 私有 | 当前执行指令地址 | 无直接调优影响 |
3.2 堆内存结构与GC机制
堆是Collector内存调优的核心。堆分为新生代（Young）与老年代（Old），新生代进一步划分为Eden、Survivor From、Survivor To。大多数采集指标对象在Eden区分配，经过多次Minor GC后晋升至老年代。
3.2.1 堆分区与对象流转
- Eden区： 新创建的指标对象、采集上下文、临时缓冲区。Minor GC频率高，对象存活率低。
- Survivor区（S0/S1）： 存放经过一次Minor GC仍存活的对象。Collector的短生命周期对象通常在此被回收。
- 老年代： 存放长期存活的对象，如缓存、连接池、全局配置。Major GC（或Full GC）发生时会导致较长的STW暂停。
3.3 栈与元空间对Collector的影响
3.3.1 栈（Stack）
每个采集线程拥有独立的栈，存储方法调用帧、局部变量、操作数栈。Collector的采集链路可能包含多层嵌套：采集器→数据清洗→指标聚合→格式转换→上报。若采集深度过大（如递归解析复杂指标），栈帧数量可能超过默认阈值（通常1024KB），导致StackOverflowError。
-Xss256k 或 -Xss512k 调整栈大小，同时代码层面限制最大采集深度。
3.3.2 元空间（Metaspace）
元空间存储类的元数据、方法内联缓存、运行时常量池。Collector若使用动态类加载（如Groovy脚本、SPI扩展），每次采集周期可能生成新的类定义。元空间默认无上限（仅受本地内存限制），但频繁的类加载/卸载会导致元空间GC，进而引发STW暂停。
| 参数 | 默认值 | Collector推荐值 | 说明 |
|---|---|---|---|
-XX:MetaspaceSize |
约21MB（依赖平台） | 256m | 触发元空间GC的初始阈值 |
-XX:MaxMetaspaceSize |
无上限 | 512m | 防止动态类加载导致内存泄漏 |
-XX:CompressedClassSpaceSize |
1GB | 256m | 压缩类指针空间，Collector类较少可缩减 |
3.4 直接内存（Direct Memory）
直接内存是堆外内存，通过java.nio.DirectByteBuffer分配。Collector使用Netty进行指标上报时，发送缓冲区、接收缓冲区均使用直接内存。直接内存的分配与回收不受JVM堆GC管理，而是依赖Cleaner机制或显式调用DirectBuffer::cleaner。
OutOfMemoryError: Direct buffer memory，但堆内存可能仍然充裕。此时GC无法回收直接内存，只能通过调整 -XX:MaxDirectMemorySize 或排查Netty缓冲区泄漏。
3.4.1 直接内存调优参数
-XX:MaxDirectMemorySize：默认等于堆最大值（-Xmx）。Collector建议显式设置为堆大小的50%~70%，避免直接内存抢占堆内存。-Dio.netty.maxDirectMemory：Netty内部直接内存上限，建议与MaxDirectMemorySize一致。-Dio.netty.leakDetectionLevel=advanced：开启Netty内存泄漏检测，定位未释放的ByteBuf。
3.5 GC机制对Collector采集稳定性的影响
GC暂停（Stop-The-World）是影响Collector SLI采集稳定性的最大因素。不同GC算法对采集延迟的影响差异显著：
| GC算法 | STW暂停特点 | Collector适用性 | 推荐场景 |
|---|---|---|---|
| Serial GC | 单线程，暂停时间长 | 不适用 | 单核小内存测试环境 |
| Parallel GC | 多线程，吞吐量高，暂停时间中等 | 一般 | 批量采集，可容忍秒级暂停 |
| CMS GC | 并发标记，低暂停，但存在浮动垃圾 | 较好 | 低延迟采集，暂停<200ms |
| G1 GC | 分区化，可预测暂停时间 | 推荐 | 大堆（>4GB），暂停<100ms |
| ZGC / Shenandoah | 几乎无暂停（<10ms） | 最佳 | 超低延迟采集，堆>16GB |
-XX:MaxGCPauseMillis=50 控制暂停时间；堆超过16GB且SLI要求P99延迟<10ms时，升级至ZGC。
3.6 本章小结
- 堆： 新生代占比40%~50%，避免对象过早晋升；老年代需容纳缓存峰值。
- 栈： 限制采集递归深度，通过
-Xss256k调整栈大小。 - 元空间： 设置
-XX:MaxMetaspaceSize=512m防止动态类加载泄漏。 - 直接内存： 显式设置
-XX:MaxDirectMemorySize，开启Netty泄漏检测。 - GC选型： 优先G1或ZGC，根据堆大小与延迟要求选择。