Comments (5)
The issue that you referenced had 2 fixes. One was already applied to the LayeredCache, but the other wasn't. item.promotion is now protected in the layeredcache like it is in the main cache 692cd61
Not sure what your issue was, so not sure if this will fix your actual problem though.
If you're still having issues, maybe you can describe it or provide code to reproduce it?
from ccache.
"item falling out of scope", what does that mean? let's say the next nanosecond it's garbage collected...
anyhow, can you provide the code for testing read/write contention locking test? e.g. saving a large file while reading it.
from ccache.
"item falling out of scope" was with respect to #23. When the Cache's gc logic runs, it doesn't actually free the memory, it merely removes the cache's reference to it (as far as I know, there's no way to force gc of a specific memory in Go). Removing the cache's reference allows the real GC to clean up the memory. But Go's GC won't release the memory if something else is referencing it, and in your example, that something else is the item
variable.
Imagine data held by the cache (with no other code running)
---------- ---------- -------- --------
| ccache | -> | bucket | -> | item | -> | DATA |
---------- ---------- -------- --------
When ccache's "gc" runs, item
becomes abandoned. In this specific case, because nothing else references item
, Go's GC can free the memory.
---------- ---------- -------- --------
| ccache | -> | bucket | | item | -> | DATA |
---------- ---------- -------- --------
===== can be freed ====
In YOUR code, it looks more like:
---------- ---------- -------- --------
| ccache | -> | bucket | -> | item | -> | DATA |
---------- ---------- -------- --------
^
|
-------
| var |
-------
So it doesn't matter if ccache's GC removes its reference to item
, because var
holds a reference to it. So Go's garbabe collector won't free your data until var
is out of scope.
=== cannot be freed ===
---------- ---------- -------- --------
| ccache | -> | bucket | | item | -> | DATA |
---------- ---------- -------- --------
^
|
-------
| var |
-------
Consider this pseudocode:
if cache.Get("somekey") != nil {
value = cache.Get("somekey")
}
THIS code CAN cause issues since, as you say, the GC could free the data between the two calls to Get
.
However, this code DOES NOT have the same problem:
v := cache.Get("somekey")
if v != nil {
...
}
Because once v
references the data, the GC won't free it. The cache might evict it, which means a subsequent call to Get would return nil, but that won't impact v
.
from ccache.
As for concurrency with large data. It doesn't matter if data is small or large. Either way, it's just a reference (it's unlikely that you're storing large stack-allocated values in the cache).
Go's race detector is probably the best thing to use to make sure there's no concurrency issue..Random testing isn't likely to catch issues that can happen with the very short lived locks that are used.
The one area that might be problematic is using the Fetch function (or your own). There's no built-in protection for the "thundering herd" problem. So if you have:
cache.Fetch(someKey, time.Minute * 10, func() (interface{}, error) {
// THIS CODE IS REALLY SLOW
})
and you call the above concurrently with the same someKey
, each goroutine will execute your callback function. This is up to the application to deal with, but using something like Singleflight would be reasonable: https://godoc.org/golang.org/x/sync/singleflight
from ccache.
This is a fantastic explanation. Please put into your readme main. Thanks
from ccache.
Related Issues (20)
- Fetch() is not atomic HOT 2
- ability to set an item that never expires HOT 2
- would like a version of Fetch that doesn't require a closure HOT 4
- Stop can cause race detector errors in testing HOT 14
- Bug report: item leak when c.promotables is busy HOT 1
- Bug report: TrackingGet goroutine unsafe with onDelete func HOT 1
- How to get the max performance? HOT 3
- Not Promote on Get HOT 2
- How to promote directly saved item? HOT 1
- OnDelete not called in LayeredCache.gc
- High lock contention in LayeredCache.set with few primary keys HOT 1
- memory leak HOT 3
- New release implemented via generics? HOT 1
- Bug Report: v3.0.0 gc may failed HOT 5
- Bug Report: v3.0.1 gc may failed
- When max size is 3, set() not delete superfluous data HOT 4
- Memory leak during cleanup
- Generic key type HOT 2
- ttl not working HOT 4
- Fix flaky test HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ccache.