LRU算法及应用

最新推荐文章于 2024-07-17 20:37:57 发布
最新推荐文章于 2024-07-17 20:37:57 发布
阅读量2.3k 收藏 12
点赞数 1
分类专栏： Java 文章标签： Java 算法 缓存 Redis LRU
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/o983950935/article/details/102164180
版权

文章目录

一 什么是LRU算法

  LRU的全名为Least Recently Used，意指最近少用，这是一种非常经典的算法，应用范围非常的广，典型的Redis缓存就采用了各类变种的LRU算法。

  LRU常常被用来处理大量缓存数据的排序问题。当下应用项目随着业务规模的上升，数据访问量也不断的攀升，对于静态、热点数据的访问已经对生产环境造成了巨大压力。

  常规的解决思路为对静态数据或热点数据进行缓存处理，比如说我当下参与的项目中，数据缓存就被分为三层（数据库自身的缓存处理不谈）：

  1. 应用进程级别全局缓存
  2. 数据库事务级别缓存
  3. 数据库连接级别缓存

  这里还不包括分布式部署的Redis缓存处理（我们仅将静态数据交予Redis管理）。

  虽然缓存数据使DB的访问压力问题得以解决，但是随之而来的是缓存造成的内存开支以及定位缓存所产生的效率问题。一旦缓存的数据量过大，那么对应用节点的内存消耗就非常严重；而且对于被缓存数据的检索也变得愈加困难，怎么办？对于内存消耗问题，解决思路是限制缓存大小；对于检索效率问题，解决思路为对数据进行热度排序。

  不论是缓存的内存消耗还是热度排序问题，其解决方案均为——LRU，将频繁访问的数据安置在缓存队列的头部，以实现快速检索；对于热度较低的数据，将其移除缓存节省内存开支（淘汰策略）。

  综上，LRU是一种缓存置换算法，一种数据淘汰策略，那么如何确定哪些数据属于“最近少用”就很关键了，大致从两个问题考虑，一是时间，二是频度。长时间没有被访问的数据可以淘汰，同时间段内访问频次低的也可以淘汰，下面就针对各种这种核心思想来看看如何实现LRU算法。

二 手工实现LRU

  手工实现LRU算法的思路非常多，之所以把这个章节放在最前，就是为了让道友门能理解算法的核心思想，后续的章节会把Redis中的LRU算法应用再整理一遍。

2.1 简单链表实现

  这是一种最简单的实现原型，算法处理过程如下：

  1. 新数据插入到链表头部；
  2. 每当缓存命中（即缓存数据被访问），则将数据移到链表头部；
  3. 当链表满的时候，将链表尾部的数据丢弃。

  这就需要程序中维护一个链表，并且每次有数据访问的时候，从链表头部开始遍历。常规情况下我们在访问一个数据的时候，一定是通过数据的ID来进行检索，所以用如下结构来示意存储数据的格式：

/**
 * @author 柠檬睡客
 */
class Data {
	/**
	 * 数据ID，一般为数据表的主键，如果是存放于Redis的缓存数据则ID更为复杂，需通过既定的编码规则来生成，甚至需要包含版本信息
	 */
	private String id;

	public String getId() {
		return this.id;
	}
}

  接下来我们使用LinkedList来描述缓存队列，并且限制队列的长度以控制缓存大小：

/**
 * @author 柠檬睡客
 * 
 * 以链表来实现的LRU算法
 */
public class ListLRU {

	/**
	 * 用以存放缓存数据的链表
	 */
	private static final LinkedList<Data> LRUCacheList = new LinkedList<Data>();
	/**
	 * 限制缓存链表的长度
	 */
	private static final int CacheLimit = 100;
}

  接下来需要实现数据的读取，注意：缓存工具不应该放开数据存放接口，对于应用来说数据访问应该是透明的，我们假定优先从缓存读取数据，若无缓存则从数据库读取，若数据库读取成功则将数据加入缓存，再返回给应用：

/**
 * 供应用访问，优先从缓存获取数据，无缓存再访问DB
 */
public static Data getData(String id) {
	Data data = null;
	synchronized (LRUCacheList) {
		for (int i = 0; i < LRUCacheList.size(); i++) {
			// 当命中数据时，需要将数据移动至链表头部
			if (id.equals(LRUCacheList.get(i).getId())) {
				data = LRUCacheList.remove(i);
				putData(data);
				return data;
			}
		}
	}
	if (data == null) {
		data = getDataFromDB(id);
	}
	if (data != null) {
		putData(data);
	}
	return data;
}

/**
 * 从DB访问数据，此方法对应用不放开
 */
private static Data getDataFromDB(String id) {
	return null;
}

  因为getData方法已经解决了数据重复的问题，所以存放数据的时候一律添加至头部，如果此时队列已满，则删除队列末尾的数据即可，以此实现淘汰策略：

/**
 * 增加缓存数据的方法不应对应用放开
 */
private static void putData(Data data) {
	synchronized (LRUCacheList) {
		if (LRUCacheList.size() == CacheLimit) {
			LRUCacheList.removeLast();
		}
		LRUCacheList.addFirst(data);
	}
}

  OK，一个基于链表的简单LRU算法已经实现了，仔细分析下这个实现过程，它是存在缺陷的：

  1. 命中率问题：每次访问数据都需要从链表头开始遍历，这对于热点数据的访问效果很好（热点数据都聚集在链表头部附近，很快就能遍历到结果），可一旦数据分散较为均匀时，访问命中率急剧下降；
  2. 性能损耗问题：每次命中数据后，都需要将数据重新移动至链表头部，存在相当大的性能损耗；
  3. 缓存污染问题：并非所有数据有必要缓存（可能整个应用运行过程中某些数据被访问的次数很少），但是算法实现过程没办法对热点数据（频繁访问的数据，这才是有价值进行缓存的）进行区分，使得缓存队列贬值。

  针对上述问题，我们再从不同的维度看如何优化，见下文。

2.2 解决命中率和缓存污染问题

  为了解决上述实现过程中的命中率问题，我们对缓存数据结构再封装，加入一个表示命中次数的成员，并且额外开辟一个临时队列，用以存储当前访问过的数据，每次命中数据则对计数器+1，达到临界值的时候才将数据从临时队列转移到缓存队列，实现逻辑如下：

  1. 初次访问数据，将数据加入临时队列，命中次数+1；
  2. 再次访问数据，命中次数继续+1；
  3. 命中次数大于临界值，转入缓存队列；
  4. 临时队列可采取FIFO或者LRU或者时间排序算法实现淘汰；
  5. 缓存队列可按命中次数排序、FIFO或者时间排序算法实现淘汰；

  这里为化简演示过程，我对临时队列采用FIFO模式进行淘汰处理，缓存队列则按命中次数排序后淘汰访问最少，首先调整缓存数据结构：

class CacheData {
	Data data;
	/**
	 * 补充命中次数统计
	 */
	int hitCount;

	public CacheData(Data data) {
		this.data = data;
		this.hitCount = 1;
	}

	public Data getData() {
		return this.data;
	}

	public int getHitCount() {
		return this.hitCount;
	}

	public int hitData() {
		return ++hitCount;
	}
}

  然后补充临时队列，以及数据命中次数的阈值，并调整缓存数据类型：

/**
 * @author 柠檬睡客
 * 
 *         补充命中统计解决命中率问题
 *
 */
public class HitListLRU {
	/**
	 * 用以存放缓存数据的链表
	 */
	private static final LinkedList<CacheData> LRUCacheList = new LinkedList<CacheData>();
	/**
	 * 限制缓存链表的长度
	 */
	private static final int CacheLimit = 100;
	/**
	 * 用以临时存放数据的链表
	 */
	private static final LinkedList<CacheData> TemporaryList = new LinkedList<CacheData>();
	/**
	 * 限制临时链表的长度
	 */
	private static final int TemporaryLimit = 100;
	/**
	 * 命中次数阈值，达到阈值后从临时队列转移到缓存队列
	 */
	private static final int HitLimit = 5;
}

  接下来需要为缓存队列设计排序，这里简单的用一个比较器来实现，实现一个Comparator与CacheData解耦：

class CacheDataComparator implements Comparator<CacheData> {
	public int compare(CacheData data1, CacheData data2) {
		if (data1.getHitCount() > data2.getHitCount()) {
			return 1;
		} else if (data1.getHitCount() < data2.getHitCount()) {
			return -1;
		} else {
			return 0;
		}
	}
}

  然后我们重写getDate方法：

/**
 * 供应用访问，优先从缓存获取数据，无缓存再访问DB
 */
public static Data getData(String id) {
	Data data = null;
	// 优先从缓存队列中访问
	synchronized (LRUCacheList) {
		for (int i = 0; i < LRUCacheList.size(); i++) {
			// 命中数据时，更新命中次数统计值
			if (id.equals(LRUCacheList.get(i).getData().getId())) {
				LRUCacheList.get(i).hitData();
				return LRUCacheList.get(i).getData();
			}
		}
	}
	// 若缓存队列没有，再遍历临时队列
	data = getDataFromTemporaryList(id);
	// 如果临时队列也没有，则访问DB
	if (data == null) {
		data = getDataFromDB(id);
	}
	if (data != null) {
		putTemporaryData(new CacheData(data));
	}
	return data;
}

  从临时队列遍历数据的方法和getData差不多，只不过多了处理命中阈值的逻辑而已：

/**
 * 从临时队列查询数据
 */
private static Data getDataFromTemporaryList(String id) {
	CacheData cacheData = null;
	synchronized (TemporaryList) {
		for (int i = 0; i < TemporaryList.size(); i++) {
			cacheData = LRUCacheList.get(i);
			// 命中数据时，更新命中次数统计值，并且一旦达到命中阈值需要转移到缓存队列
			if (id.equals(cacheData.getData().getId())) {
				if (cacheData.hitData() >= HitLimit) {
					TemporaryList.remove(i);
					putCacheData(cacheData);
					return cacheData.getData();
				}
			}
		}
	}
	return null;
}

  最后，还有两个方法需要实现，将数据加入临时队列和缓存队列：

/**
 * 将数据从临时队列加入到缓存队列
 */
private static void putCacheData(CacheData cacheData) {
	synchronized (LRUCacheList) {
		if (LRUCacheList.size() >= CacheLimit) {
			// 对缓存队列按命中次数排序，移除最末数据
			Collections.sort(LRUCacheList, new CacheDataComparator());
			LRUCacheList.removeLast();
		}
		LRUCacheList.addFirst(cacheData);
	}
}

/**
 * 将数据加入临时队列
 */
private static void putTemporaryData(CacheData cacheData) {
	synchronized (TemporaryList) {
		// 以FIFO模式淘汰数据
		if (TemporaryList.size() >= TemporaryLimit) {
			TemporaryList.removeLast();
		}
		TemporaryList.addFirst(cacheData);
	}
}

  结束，这一次我们没有轻易的将数据加入到缓存队列，而是像新入职的实习生一样，待观察一段时间，如果这段时间内数据的访问频次很高，再将其加入到缓存队列，这样就有效的解决了命中问题。并且置于缓存队列中的数据一定是经过命中频次保证的，如此也解决了缓存污染问题，使缓存队列中的数据都是热点数据。

  再总结一下，如上只是一种解决思路，其实还是有很多问题的，算法复杂度高了，内存开销虽然可以通过调整队列长度来限制，但是临时队列的额外内存开销还是客观存在的。

  而且对于数据的命中过程，依然是从头部开始遍历整个队列，访问效率问题还是没有得到解决。

  这里我再给出一些其他思路，比如说以访问频度来划分出多个队列，然后数据在多个队列间传递，直到频度最高的队列中的数据将其转入缓存等等。但不论如何，因其数据结构的限制，访问效率问题永远存在，内存开销问题也无法解决，那么到底该怎么解决？改变数据结构！见下文。

2.3 解决执行效率问题

  当我们无法通过算法进一步提升程序执行效率，并减少内存开支的时候，我们就需要转过头来重新考虑一下数据结构的问题了。执行效率目前的瓶颈就在于链表的遍历，有什么数据结构能快速的命中数据呢？HashMap！

  在链表的基础上，我们在补充一个HashMap，Key值存放数据的ID，Value则存放缓存数据，如此快速定位缓存数据问题得到解决，只要Key存在，那么缓存数据一定存在。

  那么如何解决链表元素的移动问题呢？因为缓存链表还是需要调整数据的位置的，当前的数据结构无法做到不对全表（最糟糕情况，数据在链表末尾）遍历，可行办法是双向链表，链表中的每一个元素（链表节点）都包含前、后节点的引用，此时不再需要遍历链表，仅需要调整元素的前后节点引用即可。这种设计思想跟CLHLock自旋锁很像，CLHLock在本地成员自旋（可以参考我之前写过的博客Java锁手册），双向链表的元素移动则在自己的成员引用上做手脚。

  开工，先设计一个双向链表结构，元素（后文称节点吧）定义如下：

/**
 * @author 柠檬睡客
 *
 *         链表节点
 */
class Node {
	/**
	 * 数据ID
	 */
	private String id;
	private Data data;
	/**
	 * 指向前一个节点的引用
	 */
	private Node pre;
	/**
	 * 指向后一个节点的引用
	 */
	private Node next;

	public Node(String key, Data data) {
		this.id = key;
		this.data = data;
	}

	public String getKey() {
		return id;
	}

	public void setKey(String key) {
		this.id = key;
	}

	public Data getData() {
		return data;
	}

	public void setData(Data data) {
		this.data = data;
	}

	public Node getPre() {
		return pre;
	}

	public void setPre(Node pre) {
		this.pre = pre;
	}

	public Node getNext() {
		return next;
	}

	public void setNext(Node next) {
		this.next = next;
	}
}

  接下来重新设计缓存结构，注意咯：

  1. 因为Map的Value为链表节点，而节点中已经包含了缓存数据，以及前后节点的引用，那么就无需在额外的定义链表结构了，Map中的Value集合已经隐式的形成了一个链表结构（节省结构定义产生的内存开支）；
  2. 但是！！！仍然需要在程序中保留头部和尾部节点的哨兵引用，目的是方便在头尾操作节点的引用；
  3. 为了避免每次都对Map长度进行计算（对Map尺寸进行计算还是有开销的），我们需要一个全局的长度计数器。

  所以工具定义如下：

/**
 * @author 柠檬睡客
 *
 *         以双向链表+HashMap结构实现LRU算法
 */
public class NodeListLRU {
	/**
	 * 限制缓存链表的长度
	 */
	private static final int CacheLimit = 100;
	/**
	 * 当前有多少节点的统计，避免计算Map尺寸产生的开销
	 */
	private static volatile int count = 0;
	/**
	 * 缓存数据的Map结构
	 */
	private static HashMap<String, Node> CacheMap;
	/**
	 * 头节点哨兵（不是头节点，它的后继节点才是头节点）
	 */
	private static Node head;
	/**
	 * 尾节点哨兵（不是尾节点，它的前驱节点才是尾节点）
	 */
	private static Node tail;
}

  接下来需要在静态代码块中对静态成员进行初始化动作：

static {
	CacheMap = new HashMap<String, Node>();
	// 初始化头节点和尾节点，利用哨兵模式减少判断头结点和尾节点为空
	Node headNode = new Node(null, null);
	Node tailNode = new Node(null, null);
	headNode.next = tailNode;
	tailNode.pre = headNode;
	head = headNode;
	tail = tailNode;
}

  基础设施准备完毕后需要重写getData方法：

/**
 * 优先从缓存获取数据，没有缓存则再访问DB
 */
public static Data getData(String id) {
	Data data = null;
	synchronized (CacheMap) {
		// 如果存在缓存，则将数据移动至链表头部
		Node node = CacheMap.get(id);
		if (node != null) {
			moveNodeToHead(node);
			data = node.getData();
		} else {
			data = getDataFromDB(id);
		}
		if (data != null) {
			putData(data);
		}
	}
	return data;
}

  如果是新增数据，那么需要将其加入到缓存链表，这时需要注意链表长度（由count计数器替代）是否已经达到阈值：

/**
 * 将数据加入缓存链表，一定是头部
 */
private static void putData(Data data) {
	synchronized (CacheMap) {
		// 如果队列超限，则将尾部节点移除
		if (count > CacheLimit) {
			removeTail();
		}
		// 将节点插入到头部
		Node node = new Node(data.getId(), data);
		addHead(node);
	}
}

  最后我们需要把移除节点、新增节点和转移节点三个方法补充完整：

/**
 * 新增节点到头部
 */
private static void addHead(Node node) {
	synchronized (CacheMap) {
		// 原头部节点的后继取出
		Node next = head.getNext();
		// 设置原头部节点的前驱为新增节点
		next.setPre(node);
		// 设置新增节点的后继为原头部节点
		node.setNext(next);
		// 设置新增节点的前驱为头部哨兵
		node.setPre(head);
		// 设置头部哨兵的后继为新增节点
		head.setNext(node);
		CacheMap.put(node.getKey(), node);
		count++;
	}
}

/**
 * 移除尾节点
 */
private static void removeTail() {
	synchronized (CacheMap) {
		// 被移除的节点
		Node node = tail.getPre();
		// 被移除节点的前驱和后继
		Node pre = node.getPre();
		Node next = node.getNext();
		// 拼接被移除节点的前驱和后继，使两者相连
		pre.setNext(next);
		next.setPre(pre);
		// 从链表里面移除
		node.setNext(null);
		node.setPre(null);
		CacheMap.remove(node.getKey());
		count--;
	}
}

/**
 * 移动节点到头
 */
private static void moveNodeToHead(Node node) {
	// 从链表里面移除，参考removeTail
	Node pre = node.getPre();
	Node next = node.getNext();

	pre.setNext(next);
	next.setPre(pre);

	node.setNext(null);
	node.setPre(pre);
	// 添加节点到头部
	addHead(node);
}

  完活，一个基于双向链表和HashMap的LRU算法就实现了。如此我们不但能够通过散列KEY值快速的定位缓存数据，还能够节省一个链表的结构定义，这些缓存数据的物理内存不是连续的，全部通过Node节点自身的成员引用串联。

  上述的实现方式依然采用尾部淘汰策略，这样做不是不可以，但是相对来说还是存在更多优化空间的，典型的LRU算法的应用——Redis，大名鼎鼎，它几乎将LRU算法实现的出神入化了。

  在完全理解并手动实现了若干版本的LRU之后，我们再看看Redis是如何实现的，源码部分建议大家自行阅读，后文我仅把实现的理念整理一遍。

三 Redis如何利用LRU

3.1 缓存淘汰策略

  在介绍Redis如何利用LRU之前，必须要先说明下Redis对与缓存的淘汰策略（当缓存达到上限后），上文介绍过一些简单的淘汰策略，包括FIFO、用时最久或者命中频度等等，而Redis给出了更为丰富和高效的策略模式：

  1. noeviction：默认策略，不接受任何写入请求，直接报错，简单粗暴；
  2. allkeys-lru：对KEY进行LRU计算，执行淘汰；
  3. volatile-lru：对设置了过期时间的KEY进行LRU计算，执行淘汰；
  4. allkeys-random：随机取KEY，执行淘汰；
  5. volatile-random：对设置了过期时间的KEY，随机选取执行淘汰；
  6. volatile-ttl：对设置了过期时间的KEY，按时间排序淘汰，越早过期越优先 。

  需要注意的是，当使用volatile-lru、volatile-random、volatile-ttl这三种策略时，如果没有计算出可淘汰的key，结果和noeviction一样直接报错。

  再介绍下和淘汰策略相关的指令：

  1. config get maxmemory-policy：获取当前的淘汰策略；
  2. config set maxmemory-policy allkeys-lru（模式自选）：设置淘汰策略。

  当然可以直接修改配置文件，不多说。我更想多说的是Redis中对LRU算法的实现。

3.2 LRU实现

  Redis的不同版本中对LRU算法的实现略有不同，我按照自己检索到的资料分步整理。这部分内容大部分摘自想不到！面试官问我：Redis 内存满了怎么办？

3.2.1 近似算法

  Redis使用的是近似LRU算法，它跟常规的LRU算法还不太一样。近似LRU算法通过随机采样法淘汰数据，每次随机出5（默认）个key，从里面淘汰掉最近最少使用的key。

  可以通过maxmemory-samples参数修改采样数量：例：maxmemory-samples 10，参数值越大，淘汰的结果越接近于严格的LRU算法。

  Redis为了实现近似LRU算法，给每个key增加了一个额外增加了一个24bit的字段，用来存储该key最后一次被访问的时间。

  之所以采用近似算法而非精准算法，是因为LRU算法是需要内存开支的，精准的LRU对内存的消耗远大于近似算法，而且近似算法已经能够应对大多数应用场景了。

3.2.2 近似算法优化

  Redis3.0版本中对近似LRU算法进行了一些优化。

  新算法会维护一个候选池（大小为16），池中的数据根据访问时间进行排序，第一次随机选取的key都会放入池中，随后每次随机选取的key只有在访问时间小于池中最小的时间才会放入池中，直到候选池被放满。当放满后，如果有新的key需要放入，则将池中最后访问时间最大（最近被访问）的移除。

  当需要淘汰的时候，则直接从池中选取最近访问时间最小（最久没被访问）的key淘汰掉就行。

3.2.3 LFU算法

  LFU算法是Redis4.0里面新加的一种淘汰策略。它的全称是Least Frequently Used，它的核心思想是根据key的最近被访问的频率进行淘汰，很少被访问的优先被淘汰，被访问的多的则被留下来。

  LFU算法能更好的表示一个key被访问的热度。假如你使用的是LRU算法，一个key很久没有被访问到，只刚刚是偶尔被访问了一次，那么它就被认为是热点数据，不会被淘汰，而有些key将来是很有可能被访问到的则被淘汰了。如果使用LFU算法则不会出现这种情况，因为使用一次并不会使一个key成为热点数据。

  LFU一共有两种策略：

  1. volatile-lfu：在设置了过期时间的key中使用LFU算法淘汰key；
  2. allkeys-lfu：在所有的key中使用LFU算法淘汰数据。

  设置使用这两种淘汰策略跟前面讲的一样，不过要注意的一点是这两周策略只能在Redis4.0及以上设置，如果在Redis4.0以下设置会报错。

四 结语

  如果想关注更多硬技能的分享，可以参考积少成多系列传送门，未来每一篇关于硬技能的分享都会在传送门中更新链接。

柠檬睡客
关注
  • 1
    点赞
  • 踩
  • 12
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
c语言实现的LRU算法
04-04
在实际应用中，LRU算法广泛应用于数据库系统、操作系统、Web服务器的缓存管理等领域，以提高数据访问效率。通过理解这个C语言实现的LRU算法，你可以深入学习到如何结合数据结构和算法来解决实际问题。
Java实现LRU算法.zip
11-13
在实际应用中，LRU算法不仅可以用于操作系统中的页面替换，还可以应用于数据库查询缓存、编程语言的内存管理（如Java的SoftReference和WeakReference）以及Web服务器的静态资源缓存等场景。 总的来说，Java实现LRU...
全面讲解LRU算法
热门推荐
Apple_Boy的博客
11-09 10万+
文章目录概念理解LRU原理基于 HashMap 和 双向链表实现 LRU 的Redis的LRU实现实际运用 概念理解 1.LRU是Least Recently Used的缩写，即最近最少使用页面置换算法，是为虚拟页式存储管理服务的，是根据页面调入内存后的使用情况进行决策了。由于无法预测各页面将来的使用情况，只能利用“最近的过去”作为“最近的将来”的近似，因此，LRU算法就是将最近最久未使用的页面予...
LRU算法的应用场景
YangYoung_的博客
07-20 823
LRU算法的实现具体在leetcode146题，其真实的应用场景是在类似于redis等缓存排序。每个被访问频繁的缓存都应该被排到前面去，超过缓存大小的数据就应该被删除掉。
LRU算法原理及实现
Lee_SmallNorth的博客
04-08 1699
什么是LRU？ 全名(Least recently used 最近最少使用)，非常经典的一种算法，像MySQL的Buffer Pool中以及redis的删除策略使用的都是这个。 前一篇文章说过MySQL的Buffer Pool和redis都是基于内存的，且内存大小都是有限的。所以当内存空间不足时，需要淘汰一些很少使用的数据，释放内存空间给热点数据使用。 LRU是一种缓存的置换算法，一种数据淘汰策略，所以不论是缓存的内存消耗还是热度排序问题，最优的解决方案其实都是-LRU算法。那么如何确定哪些数据...
LRU算法学习笔记：实现以及应用
zsiming的博客
09-07 596
所谓LRU（Least Recently Used）就是最近最少使用算法。其核心的思想就是根据每个节点的最后一次访问事件来对每个结点进行排序。最近一次使用的排在队头，依次类推。
算法 —— LRU算法
最新发布
qq_67693066的博客
07-17 1098
算法 —— LRU算法
对LRU算法的理解和应用场景
goutinga的博客
03-21 1811
lru
经典算法之LRU算法
小道仙的后宫
12-07 1110
LRU算法算是个常见的算法，很有必要去了解它，现在我们就来看看什么是 LRU LRU 的全称是 Least Recently Used（最近最少使用），就如它的含义一样，最近最少使用的。在实际的场景中大多会把它当作一种 淘汰策略 它的应用场景也很简单，我们的存储空间总是有限的，一旦超过了最大限度就必须要淘汰一些数据，那淘汰哪种数据才算是合理的呢？合理的方式有很多，不同的场景也不一样，但淘汰 最近最少使用的数据，在绝大部分场景下都是合理的，所以LRU算法很常见。
题解LRU算法
qq_47938856的博客
03-26 1875
LRU算法，最久未被使用算法，有一个固定大小的cache，当装不下任务的时候，就会选取，最久未被使用过的任务，进行淘汰。对于LRU要求有如下： 1，查找和删除都是O1级别的，O1级别立马就想到了hash表结构，满足这个要求。 2，要求把使用过的任务安放起来，用的时候，就去寻找，这个想到了用链表来实现。 实际上java中提供了这两种结构的结合题，这就是LinkedHashMap。用这种结构就能解决力扣上的LRU算法题，代码如下： class LRUCache { private int ca
LRU算法
weixin_47027760的博客
07-01 723
注意：（1）给双向链表添加头尾的虚拟节点，虚拟节点不包含信息，只起到连接的作用，这样的好处是不用再特殊考虑链表中有数据的第一个节点和最后一个节点，可以把这两个节点也当成普通节点一样对待了。Redis会基于server.maxmemory_samples配置选取固定数目的key，然后比较它们的lru访问时间，然后淘汰最近最久没有访问的key，maxmemory_samples的值越大，Redis的近似LRU算法就越接近于严格LRU算法，但是相应消耗也变高，对性能有一定影响，样本值默认为5。
LRU.rar_lru算法
09-21
在实际应用中，LRU算法有一些变种和优化。例如，有些系统会采用近似LRU（ALRU）算法，因为完全实现LRU可能会带来较高的开销。ALRU会在一定程度上牺牲精确性，以换取更快的性能。 总结起来，LRU算法是一种重要的策略...
LRU.rar_LRU_lru算法
09-23
LRU算法广泛应用于数据库缓存、Web服务器缓存、文件系统缓存等场景，有效地提高了系统的响应速度和效率。通过理解并掌握LRU算法的工作原理，我们可以更好地设计和优化存储系统，以应对日益增长的数据处理需求。在...
LRU算法的自编c++实现及源码。 .rar_LRU_lru算法
09-21
在这个场景中，"LRU算法的自编c++实现及源码。 .rar_LRU_lru算法" 是一个包含LRU算法C++实现的压缩包文件，里面包含了源代码和相关文档。 首先，我们需要理解LRU算法的基本原理。LRU算法的核心思想是：如果一个数据...
DJB算法
o983950935的博客
11-12 6870
文章目录一 缓存原理二 随机性三 Time33四 近似碰撞五 位移计算5.1 取整形最大值5.2 乘除2的N次方5.3 乘33的位移元算六 其他Hash算法七 结语 一 缓存原理   诸如我们经常使用的Redis，其读写速度非常快的原因在于它的存储结构是一个Hash表，这是一个非常基础的数据结构，缓存便以K-V的形式存储在Hash表中。Hash表的读写时间复杂度为O(1)，其工作流程如下： 计算...
JVM参数设置——配置入口篇
o983950935的博客
10-07 4298
文章目录一 前言二 配置JVM参数的入口2.1 JavaApplication的参数配置入口2.2 IDE工具的参数配置入口2.2 WEB容器的参数配置入口2.3 服务端进程的配置入口三 查看JVM配置信息四 结语 一 前言   从今年六月份开始，一直到节前，都在给数据中心进行我公司平台部分的技能培训，其中也穿插了一些Java服务开发、运维相关的知识点介绍。   令人惊讶的是，这样一个非常专业的运...
ORM框架设计及实现
o983950935的博客
11-03 1995
文章目录一 对象记录映射二 效率和性能三 数据访问描述信息四 字段类型转换五 数据访问基类六 统一异常处理七 数据访问框架八 数据源创建工厂九 SQL指令解析十 补充DAO接口实现十一 测试十二 其他问题 一 对象记录映射   本质上来说，ORM框架需要处理的就是如何将JAVA对象与数据表记录进行关联，便于JAVA对象的持久化，以及将表记录自动转换为JAVA对象。   这就需要存在一个中间态的描述...
Log4j2代码方式配置实现线程级动态控制
o983950935的博客
10-17 1949
文章目录一 需求二 对外暴露的接口三 代码方式配置Log4j2日志对象四 线程级日志对象的设计五 标准日志头六 异常日志的堆栈信息打印七 测试 一 需求   最近平台进行升级，要求日志工具从Log4j升级到Log4j2，以求性能上的提升。之前我写过以代码方式的配置Log4j，来实现线程级日志对象的管理，今天把版本升级到Log4j2，依然采用原有思路来做，但是实现上有诸多区别，这是因为Log4j2的...
LRU算法面对TLB算法
05-24
LRU算法与TLB算法有些类似，两者都是通过缓存来提高系统性能，但是它们的应用领域不同。LRU算法主要用于缓存淘汰，而TLB算法则用于地址转换。具体而言，当CPU访问内存时，先查看TLB（Translation Lookaside Buffer，即地址转换缓冲区）里是否有该地址的映射，如果有，则直接访问内存，否则需要访问内存中的页表，将虚拟地址翻译成物理地址，再进行访问。LRU算法则是在内存的缓存中，将访问时间最远的缓存块替换掉，以达到优化缓存的目的。因此，LRU算法和TLB算法各自独立使用，它们没有相互竞争的情况。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

柠檬睡客

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值