Isn't this because of the GC tracking these and treating then as
effectively weak references to borrow a Java term?
If they are not pointers they are not tracked by the GC and I guess they
could all be removed at every scan?
Just guessing though, I haven't in any way checked it.
On Thu, Mar 26,
On 26 Mar 2020, at 09:51, Tamás Gulácsi
mailto:tgulacs...@gmail.com>> wrote:
sync.Pool MUST use pointers (*[]byte)
I've seen this a lot but I confess I don't understand it. A []byte is
essentially a fat pointer, what does it matter if we put that or a *[]byte into
the pool? I understand that
2020. március 26., csütörtök 7:58:59 UTC+1 időpontban steve tang a
következőt írta:
>
> Thanks, I used sync.Pool to allocate a byte.Buffer, and response.Body
> isn't constant size in program, I find golang will grow the byte.Buffer
> space against to initial space. I changed code as
Thanks, I used sync.Pool to allocate a byte.Buffer, and response.Body
isn't constant size in program, I find golang will grow the byte.Buffer
space against to initial space. I changed code as follows:
type SyncPool struct{ Pool sync.Pool }
func (s *SyncPool) Get(n int) []byte {
If the pool is a sync.Pool:
Any item stored in the Pool may be removed automatically at any time without
18 // notification. If the Pool holds the only reference when this
happens, the
19 // item might be deallocated.
So placing an object in the pool does not guarantee it won’t be
chunkCrc32Hash := crc32.NewIEEE()
chunkBuf := bufferpool.GetInstance().Get()
//回收buffer
defer bufferpool.GetInstance().Put(chunkBuf)
writer := io.MultiWriter(chunkBuf, chunkCrc32Hash)
_, copyErr := io.Copy(writer, chunkResp.RawResponse.Body)
if copyErr != nil && copyErr != io.EOF {
