内存泄漏各种问题详细分析之非托管的资源泄漏

在某次巡查生产环境监控数据的时候，发现某个程序的内存占用偏高（大于500M）。对于这个程序的作用需要简单交代一下，这个程序是用做通讯服务程序，通过Socket与IOT设备进行通讯。因为了解这个程序的使用场景，所以对于该程序的内存占用偏高产生了怀疑。该程序服务的设备并不多，但是占用了几百兆的内存，很明显是存在问题的。

对于该进程随后进行的分析也验证了这个想法，由于这个问题相对来说比较典型，因此比较具有分享价值，通过对于该案例的分享希望可以让更多人了解和掌握内存泄漏问题分析的一般方法。

内存泄漏问题分析的基本步骤
内存泄漏问题的分析可以分为三大部分：

确认问题
定位问题
解决问题
确认问题即确认内存确实存在泄漏问题，这个步骤不是光看看就可以，还需要尽量的保留问题发生的现场。不管是什么样的内存泄漏问题，最好能够保留内存镜像用于分析（dump文件），因为内存泄漏问题有时候是瞬间的，如果不及时保留现场，等到有时间看的时候，可能程序已经恢复正常。保存内存镜像文件的时候最好可以间隔一段时间保留多个镜像文件用于对比分析，可以更好的定位问题。

从windbg的角度分析问题
通过windbg扩展项sos，分析dump文件中的句柄和内存里面的对象类型。sos随着.net framework一起安装，可以适用于大多数情况下的调试。

首先检查内存中的对象统计信息，输入!dumpheap -stat：

0:000> !dumpheap -stat
Statistics:
MT Count TotalSize Class Name
……
6c3ab8d4 806 38688 System.RuntimeMethodInfoStub
6c363e90 2592 39424 System.RuntimeType[]
6b68105c 2265 45300 System.Net.SafeCloseSocket+InnerSafeCloseSocket
6b680f2c 2265 45300 System.Net.SafeNativeOverlapped
6c36d120 476 45696 System.Reflection.Emit.DynamicILGenerator
08eb8b40 334 49432 Newtonsoft.Json.Serialization.JsonProperty
6b671564 2264 54336 System.Net.Sockets.OverlappedCache
6c3a1dd8 1284 87312 System.Reflection.RuntimeParameterInfo
6c3a1d90 2092 92048 System.Signature
……
6c3a17a8 7179 114864 System.Int64
00d8a37c 10717 900228 ********.NetCommunicator.SocketConnectionInfo
6b674f28 10741 988172 System.Net.Sockets.Socket
6c35da78 88000 1056000 System.Object
08eb08c0 17403 1113792 Newtonsoft.Json.Linq.JProperty
082188ac 10717 1457512 System.Collections.Concurrent.ConcurrentDictionary`2+Node[[System.String, mscorlib],[*******.RoadGate.API.Entity.MessagePacketModel, ***.RoadGate.API.Entity]][]
6c35e0e4 472 68400932 System.Char[]
6c35d6d8 126896 198551106 System.String
00af6ca0 34283 464007622 Free
6c361d04 25662 1037503288 Syst