Java 一个应用程序中有多少缓存实例太多？

我有一个用例，我想根据字符串键缓存元素映射，其中映射中的每个元素都有自己的到期日。我计划使用缓存，并利用咖啡因中真正酷的变量过期

差不多吧

Cache<String, Cache<String, ObjectWithVariableExpiry>>

缓存

现在，内部缓存应该是动态创建的，父缓存可以有数千个条目。我想知道这样做是可以的，还是咖啡因的使用真的很糟糕。我担心的是，对于每个内部

缓存

来说，计时器线程/逻辑可能会占用资源

---

非常感谢您的任何建议。

我想如果不分析对堆、对象搅动、增长率等的影响，就无法回答“太多”

是否存在需要嵌套缓存的行为，或者具有复合密钥的单个缓存就足够了？这将具有相同的条目数和变量过期时间，但可以避免新缓存实例的开销。通常，嵌套是围绕组执行操作，例如，客户特定缓存并使其所有条目无效。如果是这样的话，还有其他选择，比如在密钥中添加一个代际id，这样就不必延迟地检索和逐出老一代。内部数据结构按O（1）摊销，因此条目数量对性能的影响很小

缓存实例的开销是内存，因为缓存不会创建自己的线程。缓存由一个

ConcurrentHashMap

支持，使用多个环形缓冲区，一个用于变量过期的计时轮，一个用于防止错误共享的填充，以及一个CountMin草图（如果大小有限制）。这使缓存成为较重的对象，但对于集合而言不会过多。如果为提示过期设置

调度程序

，则它将为每个缓存实例安排一个计时器

很可能这不会是个问题。缓存旨在实现并发性和更长的使用寿命。这意味着，对于具有高实例创建的非并发情况（如作用域到http请求），它并不是最佳的。它当然可以正常工作，但与更简单的数据结构相比，它会给垃圾收集器带来更大的压力

---

不幸的是，这个问题没有足够的答案。这可能没关系，如果有负面影响，您可能会有简单的解决方案，负载测试可能会提供更强的信心。

感谢您的快速响应。我的用例涉及到您提到的组用例，但是一旦一个组形成，它通常会一直保留到缓存的生命周期，因为不会一次删除整个组。嵌套的条目可以每分钟更新一次（仍然没有每次http调用更新一次那么疯狂）。我将探索键的生成id——这可能不起作用，因为在我的情况下，相同的键将继续获得新的值。我将做一个负载测试，检查嵌套映射中总共5000*100个条目的5000个键消耗了多少内存。