如何使用可用 RAM 有效地缓存 Java 中的对象？
我需要使用一定比例的可用 RAM 来缓存 Java 中的对象。我知道其他人也问过这个问题，但没有一个答案符合我的要求。
我的要求是：
- 简单、轻量级
- 不会比普通的 HashMap 慢很多
- 使用 LRU，或者一些近似 LRU 的删除策略
我尝试过 LinkedHashMap，但是它要求您指定最大元素数，而且我不知道它有多少个元素将需要填满可用的 RAM（它们的大小会有很大差异）。
我目前的方法是使用 Google Collection 的 MapMaker，如下所示：
Map<String, Object> cache = new MapMaker().softKeys().makeMap();
这看起来很有吸引力，因为它应该在需要更多 RAM 时自动删除元素，但是存在一个严重的问题：它的行为是填满所有可用的 RAM，此时 GC 开始崩溃，整个应用程序的性能急剧下降。
我听说过 EHCache 之类的东西，但对于我的需要来说，它似乎相当重量级，而且我不确定它对于我的应用程序来说是否足够快（请记住，该解决方案不能比 HashMap 慢得多） 。
I need to cache objects in Java using a proportion of whatever RAM is available. I'm aware that others have asked this question, but none of the responses meet my requirements.
My requirements are:
- Simple and lightweight
- Not dramatically slower than a plain HashMap
- Use LRU, or some deletion policy that approximates LRU
I tried LinkedHashMap, however it requires you to specify a maximum number of elements, and I don't know how many elements it will take to fill up available RAM (their sizes will vary significantly).
My current approach is to use Google Collection's MapMaker as follows:
Map<String, Object> cache = new MapMaker().softKeys().makeMap();
This seemed attractive as it should automatically delete elements when it needs more RAM, however there is a serious problem: its behavior is to fill up all available RAM, at which point the GC begins to thrash and the whole app's performance deteriorates dramatically.
I've heard of stuff like EHCache, but it seems quite heavy-weight for what I need, and I'm not sure if it is fast enough for my application (remembering that the solution can't be dramatically slower than a HashMap).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（12）
我有与您类似的要求 - 并发性（在 2 个六核 CPU 上）和 LRU 或类似的要求 - 并且还尝试了 Guava MapMaker。我发现 softValues() 比weakValues() 慢得多，但是当内存填满时，两者都会使我的应用程序极其缓慢。
我尝试了 WeakHashMap，它的问题更少，奇怪的是甚至比通过其 removeEldestEntry() 方法使用 LinkedHashMap 作为 LRU 缓存更快。
但对我来说最快的是 ConcurrentLinkedHashMap 它使得我的应用程序比我尝试过的任何其他缓存快 3-4 (!!) 倍。经过几天的沮丧之后，喜悦！它显然已被合并到 Guava 的 MapMaker 中，但 LRU 功能无论如何都没有出现在 Guava r07 中。希望它对你有用。
I've got similar requirements to you - concurrency (on 2 hexacore CPUs) and LRU or similar - and also tried Guava MapMaker. I found softValues() much slower than weakValues(), but both made my app excruciatingly slow when memory filled up.
I tried WeakHashMap and it was less problematic, oddly even faster than using LinkedHashMap as an LRU cache via its removeEldestEntry() method.
But by the fastest for me is ConcurrentLinkedHashMap which has made my app 3-4 (!!) times faster than any other cache I tried. Joy, after days of frustration! It's apparently been incorporated into Guava's MapMaker, but the LRU feature isn't in Guava r07 at any rate. Hope it works for you.
我已经实现了serval缓存，它可能与实现新的数据源或线程池一样困难，我的建议是使用jboss-cache或另一个众所周知的缓存库。
所以你会睡得很好，没有任何问题
I've implemented serval caches and it's probably as difficult as implementing a new datasource or threadpool, my recommendation is use jboss-cache or a another well known caching lib.
So you will sleep well without issues
我真不知道是否可以说 EHCache 是重量级的。至少，我不认为 EHCache 是这样的，特别是在使用 Memory Store （这是由扩展的
LinkedHashMap和当然是最快的缓存选项）。你应该尝试一下。I really don't know if one can say that EHCache is heavy-weight. At least, I do not consider EHCache as such, especially when using a Memory Store (which is backed by an extended
LinkedHashMapand is of course the the fastest caching option). You should give it a try.我相信
MapMaker将是满足您要求的唯一合理方式。如果“GC 开始崩溃并且整个应用程序的性能急剧下降”，您应该花一些时间正确设置各种调整参数。这份文档乍一看可能有点吓人，但实际上写得非常清楚，是有关 GC 的有用信息的金矿：https://www.oracle.com/technetwork/java/javase/memorymanagement-whitepaper-150215.pdf
I believe
MapMakeris going to be the only reasonable way to get what you're asking for. If "the GC begins to thrash and the whole app's performance deteriorates dramatically," you should spend some time properly setting the various tuning parameters. This document may seem a little intimidating at first, but it's actually written very clearly and is a goldmine of helpful information about GC:https://www.oracle.com/technetwork/java/javase/memorymanagement-whitepaper-150215.pdf
我不知道这是否是一个简单的解决方案，特别是与 EHCache 或类似的解决方案相比，但是您看过 Javolution 库?它不是这样设计的，但在 javolution.context 包中，它们有一个分配器模式，可以重用对象而不需要垃圾收集。通过这种方式，它们可以将对象创建和垃圾收集保持在最低限度，这是实时编程的一个重要功能。也许您应该看一下并尝试使其适应您的问题。
I don't know if this would be a simple solution, especially compared with EHCache or similar, but have you looked at the Javolution library? It is not designed for as such, but in the
javolution.contextpackage they have an Allocator pattern which can reuse objects without the need for garbage collection. This way they keep object creation and garbage collection to a minimum, an important feature for real-time programming. Perhaps you should take a look and try to adapt it to your problem.使用软键仅允许垃圾收集器在没有其他对象引用对象时（即，当引用缓存键的唯一事物是缓存本身时）从缓存中删除对象。它不保证任何其他类型的驱逐。
您找到的大多数解决方案都是在 java Map 类之上添加的功能，包括 EhCache。
您看过 commons-collections LRUMap 吗？
请注意，存在针对 MapMaker 的未决问题提供LRU/MRU功能。也许你也可以在那里发表你的意见
Using soft keys just allows the garbage collector to remove objects from the cache when no other objects reference them (i.e., when the only thing referring to the cache key is the cache itself). It does not guarantee any other kind of expulsion.
Most solutions you find will be features added on top of the java Map classes, including EhCache.
Have you looked at the commons-collections LRUMap?
Note that there is an open issue against MapMaker to provide LRU/MRU functionality. Perhaps you can voice your opinion there as well
使用现有的缓存，存储 WeakReference 而不是普通的对象引用。
如果 GC 开始耗尽可用空间，则 WeakReferences 所持有的值将被释放。
Using your existing cache, store WeakReference rather than normal object refererences.
If GC starts running out of free space, the values held by WeakReferences will be released.
过去我使用过JCS。您可以设置配置来尝试满足您的需求。我不确定这是否能满足您的所有要求/需求，但当我使用它时，我发现它非常强大。
In the past I have used JCS. You can set up the configuration to try and meet you needs. I'm not sure if this will meet all of your requirements/needs but I found it to be pretty powerful when I used it.
你不能“删除元素”，你只能停止硬引用它们并等待 GC 清理它们，所以继续使用 Google Collections...
You cannot "delete elements" you can only stop to hard reference them and wait for the GC to clean them, so go on with Google Collections...
我不知道在 Java 中找出对象大小的简单方法。因此，我认为您不会找到一种方法来限制数据结构所占用的 RAM 量。
基于这个假设，您必须通过缓存对象的数量来限制它。我建议运行一些现实生活中的使用场景的模拟，并收集进入缓存的对象类型的统计数据。然后您可以计算统计平均大小以及您可以缓存的对象数量。尽管它只是您想要专用于缓存的 RAM 量的近似值，但它可能已经足够了。
至于缓存实现，在我的项目（性能关键型应用程序）中，我们使用 EhCache，我个人认为它根本不是重量级的。
无论如何，请使用几种不同的配置（关于大小、驱逐策略等）运行多次测试，并找出最适合您的配置。
I'm not aware of an easy way to find out an object's size in Java. Therefore, I don't think you'll find a way to limit a data structure by the amount of RAM it's taking.
Based on this assumption, you're stuck with limiting it by the number of cached objects. I'd suggest running simulations of a few real-life usage scenarios and gathering statistics on the types of objects that go into the cache. Then you can calculate the statistically average size, and the number of objects you can afford to cache. Even though it's only an approximation of the amount of RAM you want to dedicate to the cache, it might be good enough.
As to the cache implementation, in my project (a performance-critical application) we're using EhCache, and personally I don't find it to be heavyweight at all.
In any case, run several tests with several different configurations (regarding size, eviction policy etc.) and find out what works best for you.
缓存某些东西，
SoftReference可能是迄今为止我能想象到的最好的方法。或者你可以重新发明一个对象池。每一个你不使用的物体，你都不需要销毁它。但它节省CPU而不是节省内存
Caching something,
SoftReferencemaybe the best way until now I can imagine.Or you can reinvent an Object-pool. That every object you doesn't use, you don't need to destroy it. But it to save CPU rather than save memory
假设您希望缓存是线程安全的，那么您应该检查 Brian Goetz 的书《Java Concurrency in Practice》中的缓存示例。我强烈推荐这个。
Assuming you want the cache to be thread-safe, then you should examine the cache example in Brian Goetz's book "Java Concurrency in Practice". I can't recommend this highly enough.