生产环境的延迟事故有一个共同特征：平均延迟正常，P99尚可，P99.9出现毛刺。毛刺的分布往往呈现周期性或与写入量正相关，排查到尽头，根因大概率落在GC。写入密集的负载对停顿格外敏感——一次数百毫秒的Full GC，期间全部写入请求排队，恢复后积压请求集中处理，又触发二次毛刺。对以Java实现的数据库系统而言，GC治理不是调优清单的末尾项，而是写入路径设计的约束条件。时序数据库的写入压力把这个问题推得更极端。
GC算法的停顿谱系
不同垃圾收集器的停顿特征差异，决定了它们在高写入场景的适用边界：
收集器 | 停顿类型 | 典型停顿量级 | 堆规模上限 | 适用判断 |
G1 | Young GC+Mixed GC | 数十至数百毫秒 | 数十GB | 通用默认，停顿可控但存在 |
ZGC | 并发标记+转移 | 亚毫秒至数毫秒 | TB级 | 大堆低停顿首选 |
Shenandoah | 并发转移 | 数毫秒 | 数百GB | 与ZGC同档，吞吐略异 |
Serial/CMS | Full GC | 秒级 | 小堆 | 高写入场景不可接受 |
G1的停顿目标参数（MaxGCPauseMillis）只是软目标：大对象分配、humongous分配、引用处理都可能击穿目标。ZGC与Shenandoah把标记与转移全部并发化，停顿与堆规模脱钩，代价是占用额外的CPU与屏障开销——写入吞吐高的进程，屏障成本会被放大。选型因此不存在全局最优，只有与负载特征匹配的局部最优。
停顿治理的第一步是可观测。GC日志（JDK 11起统一为-Xlog:gc*）应默认开启并纳入日志采集，关键字段包括停顿类型、时长、堆前后水位、原因码。单次停顿的时长说明有限，停顿的时间分布才暴露模式：与检查点落盘对齐的停顿指向堆内缓冲的集中失效，与流量高峰对齐的停顿指向分配速率超标。把GC停顿曲线与写入延迟P99曲线叠加在同一时间轴上，相关性一目了然——这一张图应当存在于每个存储集群的运维看板。
堆外内存的取舍
降低GC压力的根本手段是把数据搬出堆。堆外内存（DirectBuffer或Unsafe分配）不受GC管理，分配与回收由应用显式控制。数据库系统通常把两类结构移出堆：写入缓冲（memtable）与查询结果缓冲。留在堆内的只剩元数据与短生命周期对象，堆规模可以从数十GB压缩到数GB，G1在这个量级下的停顿变得可控。
堆外方案的代价写在代码复杂度里：显式内存管理引入泄漏风险，引用计数或池化机制需要全链路审计；堆外数据的序列化开销在某些路径上高于堆内对象。换个技术视角看，这本质是把GC的统计成本换成了工程的管理成本——前者不可预测，后者可控但持续。
堆外内存的容量核算容易被遗漏。JVM进程的内存占用不再等于堆上限，容器环境的OOM判定基于进程总RSS——堆外缓冲、直接内存、线程栈、代码缓存全部计入。只配堆参数不配MaxDirectMemorySize，进程会被cgroup以超限为由杀死，而堆内监控显示一切正常。容器化部署下，堆、堆外、元空间三者的配额必须显式规划，总和留出至少15%的余量给JVM自身开销。
写入路径上的缓冲池设计
写入路径的内存设计决定GC压力的上限。标准的写入链路为：网络IO线程解码→写入WAL→写入内存表→批量落盘。每一步都可能产生临时对象：解码产生字节缓冲，WAL序列化产生中间数组，内存表插入产生节点对象。高并发下，这些短生命周期对象以GB/分钟的速度产生，Young GC的频率随之攀升。
缓冲池化是对治手段：固定数量的大块缓冲循环复用，写入路径上零分配。池化的难点在尺寸规划——缓冲块过小则频繁扩容，过大则浪费驻留内存。工程上常见的配置是按最大批次大小对齐缓冲块，并以监控指标（池命中率、等待队列长度）驱动调参，而非凭经验设初值后不再触碰。
池化还有一个反模式需要警惕：把池化应用到错误的生命周期上。跨请求复用的对象若携带残留状态，会引发极难复现的数据错乱——症状是偶发的记录字段串扰，与并发时序相关。防护手段是出池即清理、入池即失效，并在测试环境以压力加故障注入的方式验证。内存泄漏的排查路径也要预先准备：堆外泄漏不触发GC日志告警，需要依赖RSS趋势监控与底层内存工具的现场分析。
语言层面的根本解法
JVM系方案的全部努力，目标是把GC影响压到可接受区间；另一条路线是从语言层面消除问题本身。C/C++实现的存储引擎没有托管堆，内存分配完全显式，停顿的来源只剩系统调用与锁竞争。TDengine选择C语言实现即基于这一判断：写入延迟的P99.9与P50之间不存在GC引入的数量级鸿沟，延迟分布曲线平滑，毛刺归因可以直接定位到IO或网络。这不是免费午餐——显式内存管理的缺陷风险由工程规范与测试覆盖兜底——但对延迟敏感的存储组件，确定性本身就是核心资产。
需要客观说明的是，C路线并非没有代价：生态组件的成熟度、团队的人才储备、与Java系中间件的互操作成本，都是真实的工程约束。语言选型的合理判断标准是负载的延迟敏感度与团队的驾驭能力之比，而非单纯的性能榜单。混合架构因此成为常见终态：存储核心用C或Rust，管理面与生态连接器保留JVM技术栈。
结语
JVM技术的演进持续压缩GC停顿的理论下限，分代ZGC等改进仍在推进。但语言路线的分化不会消失：基础设施软件向Rust、C、C++集中的趋势，本质上是对确定性延迟的投票。评估一套数据基础设施时，建议直接索要生产环境的P99.9延迟分布而非平均值——平均值掩盖的问题，长尾会全部暴露。
