我有一个用例，我想根据字符串键缓存元素Map，其中Map中的每个元素都有自己的过期时间。我计划使用一个缓存，并利用咖啡因中真正酷的变量过期。
差不多吧。
Cache<String, Cache<String, ObjectWithVariableExpiry>>现在，应该动态创建内部缓存，父缓存可以有数千个条目。我想知道这样做是可以的，还是咖啡因的使用真的不好。我担心的是 Cache<String, ObjectWithVariableExpiry> 计时器线程/逻辑可能成为资源占用者。
如有任何建议，我们将不胜感激。
1条答案
按热度按时间pod7payv1#
我想如果不分析对堆、对象搅动、增长率等的影响，那么“太多”就没有答案了。
是否存在需要嵌套缓存的行为，或者一个具有复合密钥的单一缓存就足够了？这将具有相同的条目数和可变的过期时间，但可以避免新缓存示例的开销。通常，嵌套是围绕组执行操作，例如特定于客户的缓存并使其所有条目无效。如果是这样的话，还有其他选择，比如在密钥中添加一个世代id，这样就不会延迟地检索和逐出老一代。内部数据结构按o（1）进行摊销，因此条目数对性能的影响很小。
缓存示例的开销是内存，因为缓存不创建自己的线程。缓存由
ConcurrentHashMap，使用多个环形缓冲区，一个用于可变过期的计时轮，一个用于防止错误共享的填充，以及一个countmin草图（如果大小有限制）。这会使缓存成为较重的对象，但对于集合来说不会太多。如果设置Scheduler对于提示过期，它将为每个缓存示例安排一个计时器。很可能不会有问题。缓存是为并发和长寿命的使用而设计的。这意味着对于具有高示例创建的非并发情况来说，它并不是最佳的，比如作用域被限定为http请求。它当然可以正常工作，但是与更简单的数据结构相比，它会给垃圾收集器增加更多的压力。
不幸的是，这个问题没有足够的答案。如果有负面影响，您可能会有简单的解决方案，负载测试可能会提供更强的信心。