Baike.dev
All toolsAI codingTrendingOpen sourceNewsSubmit
Log in
Back to tool/Back to issues
#422·bigcache

hashmapStats allocated unconditionally regardless of StatsEnabled

Author: marianacrCreated May 12, 2026Updated May 12, 2026

Description

In v3.1.0, hashmapStats was added to each shard in initNewShard:

go
return &cacheShard{
    hashmap:      make(map[uint64]uint32, config.initialShardSize()),
    hashmapStats: make(map[uint64]uint32, config.initialShardSize()),  // always allocated
    ...
}

However, hashmapStats is only read/written when StatsEnabled: true. DefaultConfig sets StatsEnabled: false, so the vast majority of users never use stats — yet they pay the full memory cost of hashmapStats at startup.

Memory impact

The allocation cost per shard is initialShardSize() * sizeof(map entry). With DefaultConfig:

  • MaxEntriesInWindow = 600_000, Shards = 1024
  • initialShardSize = 600_000 / 1024 = 585 entries per shard
  • Each map pre-allocates ~17.5 KB of buckets

For a setup with many independent BigCache instances (e.g. 16), the unconditional hashmapStats allocation adds:

16 instances × 1024 shards × ~17.5 KB = ~286 MiB

This memory is entirely wasted when StatsEnabled: false.

Expected behavior

hashmapStats should only be allocated when StatsEnabled: true:

go
if config.StatsEnabled {
    shard.hashmapStats = make(map[uint64]uint32, config.initialShardSize())
}

Suggested fix

Allocate hashmapStats conditionally in initNewShard, and guard all reads/writes to it with a StatsEnabled check (they likely already are, given the field only makes sense with stats on).

Version

v3.1.0 (not present in v3.0.2)

Source: allegro/bigcache

View original on GitHubView discussion on GitHub