Guava Cache 默认容量限制与内存约束分析

guava cache 在未设置 maximumsize 时无硬性条目数上限，理论最大值为 integer.max_value（约 21 亿），但实际受限于 jvm 堆内存，通常在耗尽内存前就已触发 oom。

当使用 CacheBuilder.newBuilder().build() 创建缓存（如 Cache cacheWithoutSize = CacheBuilder.newBuilder().build();）时，Guava 不会自动施加任何容量限制——既无基于条目数的上限（maximumSize），也无基于权重或过期时间的强制约束。这意味着该缓存的行为本质上是“无界缓存”（unbounded cache），其容量仅受 JVM 可用堆内存和 Java 对象引用结构的底层限制所制约。

从实现角度看，Guava Cache 底层基于 LocalCache，其内部条目存储在哈希表结构中，条目总数由 int 类型索引管理，因此理论绝对上限为 Integer.MAX_VALUE（即 2³¹−1 ≈ 2.147 × 10⁹）。但这仅是一个数值边界，绝非安全可用的实践上限。

例如，假设缓存中每个条目包含一个 String key（16 字节）和一个轻量 Long value（8 字节），忽略对象头、引用指针、哈希桶数组扩容、并发分段等开销，单条目基础内存占用约 24–40 字节。即便按最乐观的 32 字节/条目估算，容纳 1 亿条目需约 3.2 GB 堆空间；达到 5 亿条目则需超 16 GB——此时 LocalCache 自身的元数据（如 Segment[]、ReferenceEntry 链表节点、弱/软引用队列等）开销已显著上升，GC 压力剧增，响应延迟不可控。

更关键的是：Guava 明确不推荐无界缓存。官方文档虽未直接声明“禁止不设 maximumSize”，但在 CacheBuilder 的设计哲学中，所有构建参数（如 maximumSize、maximumWeight、expireAfterWrite、refreshAfterWrite）均旨在引导用户显式定义缓存治理策略。缺失这些策略将导致：

CG Faces

免费的 AI 人物图像素材网站

下载

• 内存泄漏风险（尤其当 key/value 持有长生命周期对象时）；
• GC 频繁 Full GC 或 G1 Mixed GC 超时；
• 缓存雪崩时无法快速驱逐旧数据，加剧系统抖动。

✅ 正确做法示例（推荐始终设置合理上限）：

Cache safeCache = CacheBuilder.newBuilder()
    .maximumSize(10_000)           // 明确限制最多 1 万条目
    .expireAfterWrite(10, TimeUnit.MINUTES)
    .removalListener((RemovalListener) 
        notification -> log.debug("Evicted: {} → {}", 
            notification.getKey(), notification.getCause()))
    .build();

⚠️ 注意事项：

• 不要依赖 maximumSize 缺失时的“无限”行为做生产部署；
• 若业务确实需要大容量缓存，请结合 weigher() + maximumWeight 实现基于内存估算的弹性控制；
• 监控 CacheStats（如 hitRate()、evictionCount()）可辅助验证容量策略是否合理；
• 在容器化环境（如 Kubernetes）中，务必同步配置 JVM -Xmx 与缓存 maximumSize，避免因内存超限被 OOMKilled。

总之，Guava Cache 的“无 maximumSize” ≠ “无约束”，而是将约束权移交至 JVM 内存层——这恰恰是最不可控、最难调试的一层。工程实践中，显式声明容量边界，是稳健缓存设计的第一道防线。