一线码农
·
记一次 .NET 某企业ECM内容管理系统 内存暴涨分析 - 一线码农
💡
原文中文，约5800字，阅读约需14分钟。
📝
内容提要
文章分析了内存暴涨的原因，确认是由于多线程操作共享的CompositeChangeToken导致的死锁。这一现象被认定为.NET 3.1.20的内部bug，建议升级到新版本以解决该问题。
🎯
关键要点
- 文章分析了内存暴涨的原因，确认是由于多线程操作共享的CompositeChangeToken导致的死锁。
- 内存暴涨的dump显示总内存为10.95G，Stack占据8.67G，线程数达到1101。
- 大量线程处于Sleep状态，主要原因是CompositeChangeToken.OnChange方法中的死锁问题。
- 死锁发生在多个线程对共享的disposables数组的操作中，导致相互等待。
- 确认死锁是由于.NET 3.1.20的内部bug，建议升级到新版本以解决该问题。
❓
延伸问答
内存暴涨的主要原因是什么？
内存暴涨主要是由于多线程操作共享的CompositeChangeToken导致的死锁。
死锁是如何发生的？
死锁发生在多个线程对共享的disposables数组的操作中，导致相互等待。
如何确认这是一个内部bug？
确认这是.NET 3.1.20的内部bug，建议升级到新版本以解决该问题。
内存dump显示了什么信息？
内存dump显示总内存为10.95G，Stack占据8.67G，线程数达到1101。
为什么线程数会如此之高？
线程数高是因为大量线程处于Sleep状态，主要是由于CompositeChangeToken.OnChange方法中的死锁问题。
如何解决这个内存暴涨的问题？
建议升级到新版本的.NET，以避免因内部bug导致的内存暴涨。
➡️
