Background
Recently in the use of Dotnetty to implement a file upload download synchronization service.
Where: Client download server file, client multiple requests, from the server to download the file shard, append to the local disk.
-Very simple code, all written dozens of times, at ease.
Here's the problem.
However: in the stress test, I download a Win10 ISO image, 4 G.
I found: client memory keeps growing until memory overflows-I wipe.
VS2015 Memory Diagnostics
Memory diagnostics, we found that many 16M (16777228 bytes) of byte[] occupy memory.
And I'm requesting the server file shard only 64K
-And I'm sure: these 16M byte[] must have been created by Dotnetty.
Debug code
By debugging the code, you do discover where these 16M bytes are located:
((DotNetty.Buffers.PooledByteBufferAllocator) ((DotNetty.Transport.Channels.AbstractChannelHandlerContext)context) .Allocator) .directArenas
Shorthand is:
context.Allocator.directArenas
Knowing where the data for the memory leak exists, the rest is to delete the data.
Because Allocator
and directArenas
both are inaccessible (private type)
I guess: According to the Microsoft Framework's custom, there must be properties or methods to set this thing.
--I think too much, I have been looking for a long time can not find the relevant method.
Universal Solution: Anti-compilation
There must be a way to fix this data until the data is there.
Reflection is omnipotent--but I don't want to use it.
Then, start the decompile: see directArenas
where the field is assigned, and where to add the data.
Problem solving
Run the program again, the memory is stable in the 30m--memory leak problem is resolved.
This time, the most useless change bug, Dotnetty no Microsoft style.
The Microsoft framework basically has a style: the bottom layer must provide a variety of functions, properties-Default will give you a most stable default value.
This is Java urine sex: All kinds of parameters are strange, not enough parameters can not run-give me a default parameter is so difficult ~
"God pit" Dotnetty memory leak resolution