记一次 .NET某游戏币自助机后端 内存暴涨分析 - 一线码农
内容提要
最近一位朋友遇到程序内存暴涨的问题，分析发现是非托管内存导致的。使用Windbg工具分析Linux上的dump，发现程序总内存占用3.65G，主要由线程栈占据。建议将线程栈大小从8M调整为1.5M，并检查Kafka相关线程，可能是线程过多或业务执行时间长导致的线程饥饿。
延伸解读
Linux 线程栈的“实占”特性
与 Windows 不同，Linux 上线程栈的默认大小（如 CentOS 7 的 8MB）是实实在在预占的物理内存，而非仅保留地址空间。文章中的 dump 显示 423 个线程栈共占用 3.29GB，且内存内容全为 0，说明这些栈空间被白白浪费。在内存受限的环境中，这种预占会迅速耗尽资源，因此调整栈大小是缓解内存暴涨的直接手段。
跨平台诊断工具 maddress 的价值
在 Linux dump 上，传统的 !address -summary 命令输出大量 <unknown> 区域，参考价值有限。CoreCLR 团队提供的 !sos maddress 命令能跨平台枚举内存类型，清晰展示 Stack、GCHeap 等分类的占用情况。本文正是借助该命令定位到线程栈是内存消耗的主因，这提醒 .NET 开发者在 Linux 调试时应优先使用 SOS 扩展命令。
线程数异常的排查方向
文章发现程序中有 423 个线程，且大量线程卡在 Kafka 相关库的调用上。通过 ~*e !clrstack 查看线程栈，可见许多线程停留在 Confluent.Kafka 和 DotNetCore.CAP 的 P/Invoke 调用中。这暗示可能是订阅线程过多或业务处理缓慢导致线程饥饿，从而不断创建新线程。优化 Kafka 消费逻辑或限制并发线程数，可能比单纯调整栈大小更治本。
调整栈大小的两种途径
在 Linux 上修改 .NET 线程栈大小有两种方式：一是通过 ulimit -s 命令调整系统级默认值（如从 8192KB 改为 2048KB），二是设置环境变量 DOTNET_DefaultStackSize（如 180000 字节）。文章建议参考 Windows 上 .NET Core 默认的 1.5MB 栈空间，因为 8MB 对多数业务线程而言过大。但需注意，不同发行版的默认值可能不同，调整前应确认当前系统配置。
Q&A
程序内存暴涨的主要原因是什么？
程序内存暴涨主要是由于非托管内存导致的。
如何使用Windbg分析Linux上的内存问题？
可以使用Windbg工具分析Linux上的dump，使用maddress命令来查看内存使用情况。
建议将线程栈大小调整到多少？
建议将线程栈大小从8M调整为1.5M。
Kafka相关线程可能导致什么问题？
Kafka相关线程可能导致线程过多或业务执行时间长，从而引发线程饥饿。
如何检查当前Linux发行版的栈空间配置？
可以通过搜索操作系统名称的关键字来检查当前Linux发行版的栈空间配置。
在Linux上如何修改栈空间大小？
在Linux上可以使用ulimit命令来修改栈空间大小，例如使用'ulimit -s 2048'来设置为2048KB。
