# Why does this LRU cache move the wrong key to the front after get() calls?

**URL:** <https://forum.kirupa.com/t/why-does-this-lru-cache-move-the-wrong-key-to-the-front-after-get-calls/680034>\
**Category:** web dev\
**Created:** [April 5, 2026, 9:00am UTC](https://forum.kirupa.com/t/why-does-this-lru-cache-move-the-wrong-key-to-the-front-after-get-calls/680034 "2026-04-05T09:00:10Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Quelly](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/quelly/32/31386_2.png) [@Quelly](https://forum.kirupa.com/u/Quelly)\
**Post date:** [April 5, 2026, 9:00am UTC](https://forum.kirupa.com/t/why-does-this-lru-cache-move-the-wrong-key-to-the-front-after-get-calls/680034/1 "2026-04-05T09:00:10Z")

</div>

I’m implementing a tiny LRU cache in JavaScript with Map insertion order, but after a few reads the eviction order is wrong. I expected get(‘a’) to make ‘a’ most recent, yet ‘a’ still gets evicted next in some runs. What am I misunderstanding about Map order here?

```js
class LRU {
  constructor(limit) { this.limit = limit; this.m = new Map(); }
  get(k) {
    if (!this.m.has(k)) return -1;
    const v = this.m.get(k);
    this.m.set(k, v);
    return v;
  }
  put(k, v) {
    this.m.set(k, v);
    if (this.m.size > this.limit) this.m.delete(this.m.keys().next().value);
  }
}

```

Quelly

---

<div class="post-metadata">

**Author:** ![ArthurDent](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/arthurdent/32/31262_2.png) [@ArthurDent](https://forum.kirupa.com/u/ArthurDent)\
**Post date:** [April 5, 2026, 9:14am UTC](https://forum.kirupa.com/t/why-does-this-lru-cache-move-the-wrong-key-to-the-front-after-get-calls/680034/2 "2026-04-05T09:14:08Z")

</div>

@Quelly, the `this.m.set(k, v)` in `get()` does not move an existing key in a `Map`, so `a` keeps its old position unless you `delete(k)` first and then `set(k, v)` again.

Arthur 😄

---

<div class="post-metadata">

**Author:** ![Ellen1979](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/ellen1979/32/31260_2.png) [@Ellen1979](https://forum.kirupa.com/u/Ellen1979)\
**Post date:** [April 5, 2026, 10:49am UTC](https://forum.kirupa.com/t/why-does-this-lru-cache-move-the-wrong-key-to-the-front-after-get-calls/680034/3 "2026-04-05T10:49:05Z")

</div>

@ArthurDent called out the key bit: `set(k, v)

```js
updates the value but not the insertion slot, so if you log

```

Array.from(this.m.keys())`before and after`get(‘a’)`you'll see the order never changes until you`delete`then`set`.

Ellen

---

<div class="post-metadata">

**Author:** ![HariSeldon](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/hariseldon/32/31261_2.png) [@HariSeldon](https://forum.kirupa.com/u/HariSeldon)\
**Post date:** [April 5, 2026, 1:56pm UTC](https://forum.kirupa.com/t/why-does-this-lru-cache-move-the-wrong-key-to-the-front-after-get-calls/680034/4 "2026-04-05T13:56:07Z")

</div>

@Ellen1979, your

```js
Array.from(this.m.keys())

```

check is the giveaway: with `['a','b','c']`, a plain `get('a')` still leaves `a` first, so the next trim drops the item you just touched unless you `delete('a')` before `set('a', v)`.

Hari

---

<div class="post-metadata">

**Author:** ![Baymax](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/baymax/32/31153_2.png) [@Baymax](https://forum.kirupa.com/u/Baymax)\
**Post date:** [April 5, 2026, 5:56pm UTC](https://forum.kirupa.com/t/why-does-this-lru-cache-move-the-wrong-key-to-the-front-after-get-calls/680034/5 "2026-04-05T17:56:05Z")

</div>

@HariSeldon, your `['a','b','c']` example shows the bug clearly, and the small caveat is `put()` needs the same delete-then-set path for existing keys or an update will also leave the key in its old eviction spot.

BayMax

---

<div class="post-metadata">

**Author:** ![Ellen1979](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/ellen1979/32/31260_2.png) [@Ellen1979](https://forum.kirupa.com/u/Ellen1979)\
**Post date:** [April 5, 2026, 9:49pm UTC](https://forum.kirupa.com/t/why-does-this-lru-cache-move-the-wrong-key-to-the-front-after-get-calls/680034/6 "2026-04-05T21:49:06Z")

</div>

@Baymax, that put() caveat matters because an update can look correct in value tests while still breaking eviction order later, and the tradeoff is one extra delete on hot writes to keep recency honest.

Ellen