试想一下，你手中握着一把特殊的“尺子”——它不是用来测量长度，而是专为捕捉JVM内存分配的真实瞬间而生。无需依赖GC日志中那些复杂的扫描、标记与清理过程，它直接以“崩溃”作为最终结果，清晰地告诉你：内存耗尽，这便是你的实际消耗。Epsilon垃圾收集器正是这样一款工具：专为微服务与Serverless场景设计的内存行为分析利器。通过禁用垃圾回收、以OOM退出作为信号，它能精准量化单次请求的内存分配速率，验证无状态特性，同时帮助你在容器资源限制上实现极致对齐。

更具体地说：Epsilon并非旨在“提升性能”的通用垃圾回收器，而是一款特制的测量工具——它将JVM转变为内存分配计数器，崩溃即是结果。在微服务与无状态计算的场景中，它的价值不在于让你运行更长时间，而是赤裸裸地揭示真实的内存行为。

精准刻画单次请求的内存足迹

微服务（尤其是Serverless函数）本质上遵循“一次执行、用完即弃”的模式。Epsilon强制将-Xmx设置为硬性上限，所有对象分配均在这个边界内发生，不会因GC干扰而产生抖动。这样一来，你就能在零GC噪声的环境中直接观测到：

• 某次HTTP请求处理过程中创建的对象总数，以及堆空间的占用情况
• DTO转换、JSON序列化、规则引擎执行等轻量级逻辑的真实内存开销
• 不同实现方式（例如Stream.collect 与 for-loop）在相同输入下的内存分配差异

用退出信号替代GC日志进行量化对比

传统的GC日志充满了扫描、标记、清理等中间步骤，很难直接映射到业务耗时。Epsilon则把“内存耗尽”转化为明确的退出信号（退出码137），配合运行时长即可构成可复现的基准点：

• 同一段代码在-Xmx128m下运行5.3秒后退出 → 表明该逻辑单位时间内的内存分配速率约为24MB/s
• 优化后同样配置下运行8.7秒退出 → 分配速率下降约39%，说明临时对象的创建显著减少
• 这个指标相比GC次数或暂停时间，更能贴近无状态函数的实际资源消耗模型

验证无状态假设是否真正成立

许多微服务自称“无状态”，但背后可能隐藏着隐式缓存、静态Map堆积、线程局部变量未清理等问题。Epsilon会立即将其暴露出来：

• 如果函数在固定输入下每次运行时间递减，说明有对象被跨请求复用——这直接违反了无状态原则
• 如果Runtime.getRuntime().totalMemory() - freeMemory()持续增长且不重置，表明存在静态引用泄漏
• WeakReference与PhantomReference在Epsilon下完全失效，正好用来检验是否错误地依赖了GC时机进行清理

与容器资源限制对齐，杜绝超卖风险

在Kubernetes或Serverless平台中，cgroup内存限制必须与JVM堆上限严格一致。Epsilon让这个对齐变得可验证：

• 设定cgroup limit=256MiB，同时-Xmx256m → JVM退出即表示容器内存已满，不存在OOM模糊地带
• 避免G1或ZGC因预留内存、元空间增长、GC线程栈等原因导致实际占用超出limit而被强制kill
• 配合Prometheus抓取JVM进程退出事件，可以构建出“内存压测→容器驱逐”的因果链监控