我有一个用例，我想针对字符串键缓存元素映射，其中映射中的每个元素都可以有自己的到期时间。我打算使用缓存的缓存并利用咖啡因中非常酷的变量到期。
所以类似的东西。
Cache<String, Cache<String, ObjectWithVariableExpiry>>
现在，内部缓存应该是动态创建的，父缓存可以有数千个条目。我想知道这是否可以做，或者它是否真的不好使用咖啡因。我担心的是，对于每个内部Cache<String, ObjectWithVariableExpiry>，计时器线程/逻辑可能会成为资源消耗。
非常感谢任何建议。
我想如果不分析对堆、对象流失、增长率等的影响，就没有关于“太多”的答案。
是否存在需要嵌套缓存的行为，或者具有复合键的单个缓存就足够了？这将具有相同数量的条目和可变过期时间，但避免了新缓存实例的开销。通常嵌套是围绕组执行操作，例如特定于客户的缓存并使他们的所有条目无效。如果是这种情况，还有其他替代方法，例如向密钥添加世代 id，从而允许老一代不会被懒惰地检索和驱逐。内部数据结构摊销为 O(1)，因此条目数对性能的影响很小。
缓存实例的开销是内存，因为缓存不创建自己的线程。缓存由 a 支持ConcurrentHashMap，使用多个环形缓冲区、用于变量过期的计时轮、用于防止错误共享的填充以及 CountMin 草图（如果大小有界）。这使得缓存成为较重的对象，但对于一个集合来说并不过分。如果设置一个Scheduler提示过期，那么它将为每个缓存实例安排一个计时器。
很可能不会有问题。缓存旨在实现并发性和更长的使用寿命。这意味着它对于具有高实例创建的非并发情况不是最佳的，例如范围为 http 请求。它当然可以正常工作，但与更简单的数据结构相比，给垃圾收集器增加了更多压力。
不幸的是，从这个问题来看，还不足以给出一个好的答案。可能没问题，如果有负面影响，您可能会有简单的解决方案，并且负载测试可能会提供更强的信心。