记一次 .NET 某企业ECM内容管理系统 内存暴涨分析
💡
原文中文，约6400字，阅读约需16分钟。
📝
内容提要
文章分析了内存暴涨问题，确认死锁是由于多线程操作共享的CompositeChangeToken引起，并与.NET 3.1.20版本的bug有关，建议升级到新版本以避免此问题。
🎯
关键要点
- 文章分析了内存暴涨问题，确认死锁是由于多线程操作共享的CompositeChangeToken引起。
- 内存暴涨的原因是Stack占用了8.67G，线程数达到1101，表明存在严重问题。
- 大量线程处于Sleep状态，主要原因是CompositeChangeToken.OnChange方法中的死锁。
- 死锁发生在多个线程对共享的disposables数组的操作中，导致相互等待。
- 确认死锁是由于.NET 3.1.20版本的bug，建议升级到新版本以避免此问题。
❓
延伸问答
内存暴涨的主要原因是什么？
内存暴涨主要是由于Stack占用了8.67G，线程数达到1101，表明存在严重问题。
死锁是如何发生的？
死锁发生在多个线程对共享的disposables数组的操作中，导致相互等待。
.NET 3.1.20版本的bug与内存暴涨有什么关系？
.NET 3.1.20版本的bug导致了对CompositeChangeToken的错误处理，从而引发了死锁和内存暴涨。
如何解决内存暴涨和死锁问题？
建议升级到新版本的.NET，以避免因旧版本bug引发的内存暴涨和死锁问题。
在分析内存暴涨时使用了哪些工具？
使用了命令!maddress -summary和~*e !clrstack来观察进程的内存布局和线程状态。
多线程操作如何影响CompositeChangeToken？
多线程操作导致对CompositeChangeToken的共享访问，进而引发死锁和内存暴涨问题。
➡️
