epsilon收集器是专为微服务与serverless设计的内存行为测量工具，通过禁用gc、以oom退出为信号，精准量化单次请求内存分配速率、验证无状态性并校准容器资源限制。
Epsilon收集器不是用来“提升性能”的通用GC，而是为特定场景设计的测量工具——它把JVM变成一个内存分配计数器，崩溃即结果。在微服务与无状态计算中，它的价值不在于运行得更久，而在于暴露真实内存行为。
精准刻画单次请求的内存足迹
微服务（尤其是Serverless函数）本质是“一次执行、即用即弃”。Epsilon强制设定-Xmx作为硬性上限，所有对象分配都在此边界内发生，不会因GC干扰产生抖动。这使得你能在零GC噪声下，直接观测：
- 某次HTTP请求处理全程创建了多少对象、占用了多少堆空间
- DTO转换、JSON序列化、规则引擎执行等轻量逻辑的真实内存开销
- 不同实现方式（如Stream.collect vs 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 memory limit与JVM堆上限必须严格一致。Epsilon让这个对齐变得可验证：
- 设cgroup limit=256MiB，同时-Xmx256m → JVM退出即表示容器内存已满，无OOM模糊地带
- 避免G1/ZGC因预留内存、元空间增长、GC线程栈等导致的实际占用超出limit而被kill
- 配合Prometheus抓取JVM进程退出事件，可构建“内存压测-容器驱逐”因果链监控
