It is not possible to use Items() race-free if a janitor is running

[lmb]

Since the lock on the map is released once Items() returns, the janitor can come along and concurrently modify the map while user code is accessing it. Adding a wrapper of synchronisation as suggested by the documentation is useless.

The solution is to explicitly copy the map and return the copy.

[patrickmn]

Yeah, my desire to make the cache trivially serializable continues to haunt me. There probably should never have been an Items() method (or Load/LoadFile/Save/SaveFile) in the first place.

Out of curiosity, why are you using Items()?

[lmb]

The original use case was to store metrics in the cache, and then dump them all in one instant. For that you need to know what is in the cache. The whole thing doesn't work for other reasons, so I just replaced go-cache with a map and mutex.

[hikhvar]

I hit that race condition too. My usecase for go-cache is to store values with a TTL. At certain points in time I want to iterate over all Items with a valid TTL. My first surprise while using Items() was that I have to check for a valid TTL by myself. The second one was that I can not interate over all stored Items without a data race.

[patrickmn]

Since this is clearly undesirable behavior, I've changed Items() to return a new map of unexpired items: a2d8b56

Hopefully this addresses the issue.