3 ms·
also no one GCs sync.Pool. After a spike in utilization, live with increased memory usage until program restart.
by nopurpose 2y ago
also no one GCs sync.Pool. After a spike in utilization, live with increased memory usage until program restart.
- ncruces 2y agoThat's just not true. Pool contents are GCed after two cycles if unused.
- nopurpose 2y agoWhat do you mean? Pool content can't be GCed , because there are references to it: pool itself. What people do is what this article suggested, pool.Get/pool.Put, which makes it only grow in size even if load profile changes. App literally accumulated now unwanted garbage in pool and no app I have seen made and attempt to GC it.
- ashf023 2y agosync.Pool uses weak references for this purpose. The pool does delay GC, and if your pooled objects have pointers, those are real and can be a problem. If your app never decreases the pool size, you've probably reached a stable equilibrium with usage, or your usage fits a pattern that GC has trouble with. If Go truly cannot GC your pooled objects, you probably have a memory leak. E.g. if you have Nodes in a graph with pointers to each other in the pool, and some root pointer to anything in the pool, that's a memory leak
- deleted 2y ago[deleted]
- ahmedtd 2y agoFrom the sync.Pool documentation: > If the Pool holds the only reference when this happens, the item might be deallocated. Conceptually, the pool is holding a weak pointer to the items inside it. The GC is free to clean them up if it wants to, when it gets triggered.
- andrewf 2y agohttps://github.com/golang/go/blob/master/src/sync/pool.go#L297 https://github.com/golang/go/blob/master/src/sync/pool.go#L2... The GC calls out to sync.Pool's cleanup.