guava cache 在未设置 maximumsize 时无硬性条目数上限，理论最大值为 integer.max_value（约 21 亿），但实际受限于 jvm 堆内存，通常在耗尽内存前就已触发 oom。
当使用 CacheBuilder.newBuilder().build() 创建缓存（如 Cache
从实现角度看，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）均旨在引导用户显式定义缓存治理策略。缺失这些策略将导致：
- 内存泄漏风险（尤其当 key/value 持有长生命周期对象时）；
- GC 频繁 Full GC 或 G1 Mixed GC 超时；
- 缓存雪崩时无法快速驱逐旧数据，加剧系统抖动。
✅ 正确做法示例（推荐始终设置合理上限）：
Cache<String, Object> safeCache = CacheBuilder.newBuilder()
.maximumSize(10_000) // 明确限制最多 1 万条目
.expireAfterWrite(10, TimeUnit.MINUTES)
.removalListener((RemovalListener<String, Object>)
notification -> log.debug("Evicted: {} → {}",
notification.getKey(), notification.getCause()))
.build();⚠️ 注意事项：
- 不要依赖 maximumSize 缺失时的“无限”行为做生产部署；
- 若业务确实需要大容量缓存，请结合 weigher() + maximumWeight 实现基于内存估算的弹性控制；
- 监控 CacheStats（如 hitRate()、evictionCount()）可辅助验证容量策略是否合理；
- 在容器化环境（如 Kubernetes）中，务必同步配置 JVM -Xmx 与缓存 maximumSize，避免因内存超限被 OOMKilled。
总之，Guava Cache 的“无 maximumSize” ≠ “无约束”，而是将约束权移交至 JVM 内存层——这恰恰是最不可控、最难调试的一层。工程实践中，显式声明容量边界，是稳健缓存设计的第一道防线。
