如何解决一个应用程序中有多少个Caffeine Cache实例太多?
我有一个用例,我想针对String键缓存元素映射,其中映射中的每个元素都可以有自己的到期时间。我打算使用缓存缓存,并利用咖啡因中非常酷的变量到期时间。
类似的东西。
Cache<String,Cache<String,ObjectWithVariableExpiry>>
现在,应该动态创建内部缓存,并且父缓存可以具有数千个条目。我想知道这样做是否可以,或者咖啡因的使用是否真的不好。我担心的是,对于每个内部Cache<String,ObjectWithVariableExpiry>
,计时器线程/逻辑都可能成为资源消耗。
任何建议都将不胜感激。
解决方法
我想如果没有剖析就无法看到对堆,对象流失,增长率等的影响,那么“太多”是没有答案的。
是否存在需要嵌套缓存的行为,或者具有复合键的单个缓存是否足够?这将具有相同数量的条目和可变的到期时间,但避免了新缓存实例的开销。通常,嵌套是围绕组执行操作,例如客户特定的缓存,并使其所有条目无效。如果是这种情况,则可以使用其他方法,例如向密钥添加世代ID,从而可以避免懒惰地检索和驱逐较早的一代。内部数据结构采用O(1)摊销,因此条目数对性能的影响很小。
缓存实例的开销是内存,因为缓存不会创建自己的线程。缓存由ConcurrentHashMap
支持,使用多个环形缓冲区,定时轮(用于防止变量过期),填充(防止虚假共享)和CountMin草图(如果大小有界)。这使高速缓存成为较重的对象,但对于集合而言则不会过多。如果将Scheduler
设置为快速到期,则它将为每个缓存实例安排一个计时器。
很有可能这不是问题。缓存旨在实现并发和更长的使用期限。这意味着它不适用于具有高实例创建的非并发案例,例如作用域为http请求。当然可以,但是与简单的数据结构相比,这给垃圾收集器增加了更多压力。
不幸的是,这个问题不足以给出一个好的答案。没关系,如果有负面影响,您可能有简单的解决方案,而负载测试可能会提供更强的信心。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。