使用dapper，因错误SQL字串拼接方式 导致的内存泄漏

作者就职的公司在19年就开始使用.net core并且部署到Linux上，这些年也遇到不少问题，有些问题都是使用土方法去解决，后面再慢慢写吧，准备将遇到的问题写成一个系列。

前情提要

本次的项目是20年上线的储值卡系统，上线后发现内存缓慢增长（半个月涨到4G多），一直没有找到原因就让运维小伙伴设置每半个月重启来解决这个问题，但是公司的发展增长的内存越来越大，不得不去学习一些知识去解决这个问题了。这就有了今天这篇博文。

让运维小伙伴帮忙拿到dump，开始分析。(如何从Linux拿到dump？参考黄老师（一线码农）的博文：Linux 上的 .NET 崩溃了怎么抓 Dump – 一线码农 – 博客园 (cnblogs.com))

分析思路：

一、先观察一下dump的摘要信息

打开WinDbg，使用 !address -summary 命令观察摘要信息

 发现 MEM_COMMIT 中占用1.501GB

二、判断是托管内存还是非托管内存泄露

1、使用 !eeheap -gc 命令观察一下

 发现 Small object heap（小对象堆）占了800多M的内存，Large object heap(大对象堆)占了90多M的内存，那还有500多M的内存在哪里呢？

2、那我们通过!sos maddress -summary 命令观察一下

发现栈（stack）和映像（Image）占了519M内存，上面缺少的500多M在这里了，这个占用是正常的，那么我们就可以确认问题出现在Small object heap（小对象堆）中了

三、看看统计下托管堆上内存所有对象和小对象堆中的内存所有对象

1、通过 !sos dumpheap -stat 命令查看托管堆上内存所有对象

 发现数量最多分别是Dapper.SqlMapper+CacheInfo和Dapper.SqlMapper+Identity和string，我们在来看看某个小对象堆中的所有对象是不是这些内容

2、通过 !dumpheap -segment XXX（小对象堆中的segment） 命令观察小对象堆上内存所有对象

发现和上面托管堆的中的对象一样，那我们接下来就去看看数量最多string中都是些什么东西吧。

四、查看string对象中的内容

1、通过 !dumpheap -mt 7f6f8b160f90 命令查看对象中的信息

 内容有点多，那我们就看看其中一个对象的内容吧

2、通过 !dumpobj /d 7f6f73ffadd8 命令查看对象中的内容

 ？？？？怎么会是sql语句呢？我再多看几个

 怎么都是sql呀？？？？？那我就看看谁在占用它吧

 3、通过 !sos gcroot 7f6f71cf4ac8 命令查看谁在占用该内存对象

居然是dapper在占用它，看上去是dapper的缓存？啊？？？dapper还把sql语句都作为缓存了？

好我们找到问题了，那就开始解决它

 解决问题：

一、要解决问题那必须先了解问题

通过查看源码，找到Dapper.SqlMapper.Identity

发现会缓存起来，为什么会缓存起来呢？原因是为了效率

（详细的大家请看：深入Dapper.NET源码 (文长) – 阿翰 – 博客园 (cnblogs.com)）

 二、解决办法

 1、规范sql，条件都必须通过参数传递，避免缓存过得造成内存泄露

 2、如果没办法规范sql怎么办呢？也有解决版本

通过阅读源码发现有两个方法 SqlMapper.GetCachedSQLCount()和SqlMapper.PurgeQueryCache()，可以通过以上两个方法解决这个问题，避免过多的缓存，如果大于阈值就清空缓存

下一篇再见了大家

原文链接：使用dapper，因错误SQL字串拼接方式 导致的内存泄漏