guava cache 在未显式设置 `maximumsize()` 时无硬性条目数量上限，理论最大容量为 `integer.max_value`（约 21 亿），但实际受限于 jvm 堆内存，通常在达到理论极限前就会因 oom 而失败。
当使用 CacheBuilder.newBuilder().build() 创建缓存（如 Cache<String, Object> cacheWithoutSize = CacheBuilder.newBuilder().build();）时，Guava 不会自动施加任何容量限制——既无基于条目的 maximumSize()，也无基于权重的 maximumWeight()，更不启用基于时间或引用的自动驱逐策略。这意味着该缓存本质上是一个无自动淘汰机制的强引用映射容器，其生命周期和容量完全由 JVM 内存与用户代码逻辑控制。
从源码与设计契约来看，Guava 的 Cache 实现（底层为 LocalCache）在未配置容量约束时，条目数量的理论上限由 Java 数组索引与内部哈希表结构决定，即 Integer.MAX_VALUE（2³¹−1 ≈ 2.147×10⁹）。但这仅是数据结构层面的数学边界，绝非可用的安全阈值。
⚠️ 实际使用中，请务必注意以下关键事实：
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 内存早于数量见顶：假设每个缓存条目平均占用 128 字节（含 String 键、轻量对象值及 LocalCache 自身节点开销），容纳 1 千万个条目即需约 1.2 GB 堆空间；1 亿条目则超 12 GB。绝大多数生产环境 JVM 难以长期稳定支撑数十 GB 缓存堆，更不用说逼近 20+ GB 的临界点。
- 无自动回收 → 内存泄漏风险极高：未配置 expireAfterWrite、expireAfterAccess 或 refreshAfterWrite，且未手动调用 invalidate() / invalidateAll()，缓存将无限增长，最终触发 OutOfMemoryError: Java heap space。
- GC 压力陡增：大量短生命周期缓存对象会加剧年轻代 GC 频率；若对象被长期持有，还会抬高老年代占用，影响整体吞吐。
✅ 正确实践建议：
-
始终显式设限：即使业务“暂无明确上限”，也应基于监控数据设定保守值，例如：
Cache<String, Object> safeCache = CacheBuilder.newBuilder() .maximumSize(10_000) // 明确条目上限 .expireAfterWrite(10, TimeUnit.MINUTES) // 辅助过期保障 .recordStats() // 开启统计便于观测 .build(); -
结合权重控制更灵活：对大小差异大的值，优先使用 weigher() + maximumWeight()：
Cache<String, byte[]> blobCache = CacheBuilder.newBuilder() .maximumWeight(100_000_000) // 100 MB 总权重 .weigher((k, v) -> v.length) // 按字节数计算权重 .build(); - 监控先行：通过 cache.stats() 定期采集 hitRate()、evictionCount()、estimatedSize()，结合 JVM 堆使用率告警，实现容量治理闭环。
总之，CacheBuilder.newBuilder().build() 创建的是一个“自由但危险”的缓存——它赋予你完全控制权，也把内存安全责任全盘托付给你。在生产系统中，不设限 ≠ 无限制，而是将容量瓶颈从框架层转移到了运维与架构决策层。
