记一次 .NET 某珠宝公司内部管理系统 内存暴涨分析 - 一线码农
内容提要
一位朋友的Linux .NET程序内存暴涨，用!maddress发现非托管内存占用高。经!dumpheap和!gcroot分析，发现SqlClient的SNIMarsConnection对象多达3765个，被SNIMarsManager持有。原因是连接字符串启用了MultipleActiveResultSets=True，且连接未及时释放。快速修复是去掉该选项，根治需优化代码或升级SQLClient版本。
延伸解读
MARS 连接泄漏的典型特征
文章通过 !dumpheap 发现 SNIMarsConnection 对象多达 3765 个，且被 SNIMarsManager 静态持有，这是 MARS 连接泄漏的典型表现。每个连接都会占用非托管资源，导致 PAGE_READWRITE 内存高达 1GB 以上。若你的 .NET 程序在 Linux 上出现非托管内存持续增长，可优先检查 SqlClient 相关对象数量。
快速修复与根治方案的权衡
去掉连接字符串中的 MultipleActiveResultSets=True 能立即缓解内存暴涨，但可能影响依赖 MARS 的多结果集读取逻辑。根治需确保 Connection、DataReader 等对象及时 Dispose/Close，或升级 SQLClient 版本。文章提到微软官方 issue 表明新版可能内置了连接回收机制，但升级前需测试兼容性。
诊断工具与安全提醒
在 Linux 上分析 .NET 内存 dump 时，!maddress 比 !address 更适用，能区分 GCHeap 与非托管内存。文章还提醒，将连接字符串等敏感信息交给大模型分析可能存在数据出境风险。日常开发中应养成使用 using 或 try-finally 释放数据库资源的习惯，避免依赖 MARS 特性。
Q&A
Linux 上的 .NET 程序内存暴涨，用什么命令查看非托管内存占用？
在 Linux 上应使用 !maddress -summary 命令，而不是传统的 !address -summary。
!dumpheap -stat 显示 SNIMarsConnection 对象数量异常多，这通常意味着什么？
SNIMarsConnection 数量过多（如 3765 个）意味着底层打开了大量数据库连接，每个连接都会占用非托管资源，导致非托管内存上涨。
SNIMarsConnection 对象被谁持有？如何用 !gcroot 确认？
SNIMarsConnection 被 SNIMarsManager 持有。通过 !gcroot 命令可以找到根对象，最终指向 SNIMarsManager 的静态字段 SingletonInstance。
MultipleActiveResultSets=True 为什么会导致内存暴涨？
启用 MultipleActiveResultSets=True 后，如果连接使用后未及时 dispose/close，会导致 MARS 连接泄漏，SNIMarsConnection 对象不断累积，从而占用大量非托管内存。
如何快速修复因 MultipleActiveResultSets=True 引起的内存暴涨？
快速修复方法是去掉连接字符串中的 MultipleActiveResultSets=True 选项。
除了快速修复，根治 MARS 连接泄漏问题有哪些方法？
根治需要优化代码，确保连接及时释放；或者升级 SQLClient 版本，因为微软官方库的 bug 也可能导致此问题。
