强制清除内存

Question

我的项目遇到了一些内存问题，所以我决定对一些部分进行压力测试，以查看一些性能度量。我正在使用Google的ConcurrentLinkedHashMap库作为LRU内存缓存。我的测试代码的相关部分如下所示：

final ConcurrentLinkedHashMap cache = new ConcurrentLinkedHashMap.Builder<Long,Long>()
            .maximumWeightedCapacity(200000)
            .build();

for (int i = 0; i < 10; i++) {
    new Thread(new Runnable() {
        @Override
        public void run() {
            int count = 0;
            while (count < 1000000) {
                if (throttle) {
                    Thread.sleep(1000);
                    continue;
                }
                cache.put(random.nextLong(), random.nextLong());
                count++;
            }
        }
    }).start();
}

this.wait();

当内存超过50%时，我将throttle（油门）标志设置为true（真）。我有一个监视线程，它每2秒进行一次测量。以下是我得到的数字：

Size: 423902    Weighted Size: 200001   Memory: 0.11229571913729916
Size: 910783    Weighted Size: 200001   Memory: 0.25812696264655144
Size: 1373394   Weighted Size: 200001   Memory: 0.38996117352719034
Size: 2120239   Weighted Size: 200001   Memory: 0.6203725762957892
Size: 2114424   Weighted Size: 200000   Memory: 0.6233790564491212
Size: 2114424   Weighted Size: 200000   Memory: 0.6233790564491212
Size: 2114424   Weighted Size: 200000   Memory: 0.6233790564491212
Size: 2114424   Weighted Size: 200000   Memory: 0.6233790564491212
Size: 2114424   Weighted Size: 200000   Memory: 0.6233790564491212
Size: 2114424   Weighted Size: 200000   Memory: 0.6233790564491212

由于某种原因，我没有看到LRU缓存的被逐出的条目被清理。我听说手动调用系统。gc（）是个坏主意。如果是这样，有什么好方法可以有效地清理内存？

另一方面：有人知道ConcurrentLinkedHashMap返回什么吗weightedSize（）返回正确的值，但我担心size会返回更大的值。。




Answer 1

默认的驱逐策略不是先进先出吗？如果是这样，您是否正在查看第一个插入以查看它们被驱逐？如果您正在查看最后一个，您将看不到它们。

这来自文档：

The default
 * weigher assigns each value a weight of 1 to bound the map by the
 * total number of key-value pairs. A map that holds collections may choose to
 * weigh values by the number of elements in the collection and bound the map
 * by the total number of elements that it contains. A change to a value that
 * modifies its weight requires that an update operation is performed on the
 * map.

因此，根据我的读数，默认情况下加权大小不会改变。

Answer 2

正如您的数字所示，缓存并不严格保证最大值，但会尝试保持高水位线。如果它确实提供了强有力的保证，那么它将通过对每个写操作进行阻塞调用来限制并发性，并且无法有效地维护顶级LRU策略。在Guava的缓存中，我们确实通过使用锁条带来进行限制，但这种权衡是有限制的。

由于CLHM异步连接哈希表和LRU数据结构，这两个数字可能会出现偏差。大小由修饰的ConcurrentHashMap测量。这是在任何给定时刻对键值对的最准确估计。当LRU策略根据其数据结构重播映射操作以确定最近顺序并执行逐出时，将计算加权大小。加权大小保持在预期的最大值，因为当超过阈值时，策略将退出。

预计大小在突发中会有所不同，但缓存始终会尝试快速自我更正。在您的示例中，这种行为会加剧，因为操作系统会为一个大的时间片安排一个线程。这使得它可以执行比真实场景中可能执行的插入更多的插入。摊销的LRU管理意味着逐出无法跟上，因为它在任何给定时刻都会从一个线程中窃取一点时间。为了更好地模拟实际行为，MemoryLeakTest强制在操作之间切换上下文。

如果您实现了逐出侦听器，您应该会看到计数增加，并且已经达到稳定状态。如果强制进行上下文切换，则应该看到大小保持在下限。如果您希望对地图中可能出现的条目总数有更严格的限制，那么最好使用Guava实现。