Tôi đã chạy thử nghiệm tải đối với một ứng dụng web ASP.NET sản xuất và thấy một số lượng lớn các System.WeakReferences được tạo trên heap. Trong khoảng 15 phút dưới bộ nhớ heap được quản lý tải đã tăng lên khoảng 3GB và tôi có khoảng 5.000.000 tham chiếu đến System.WeakReference. Thực hiện một bộ sưu tập rác cưỡng bức của tất cả các thế hệ không phát hành các tài liệu tham khảo.Điều gì có thể giải thích hơn 5.000.000 phiên bản System.WeakReference trên heap được quản lý?
Tôi đã thấy các bài viết về lớp trợ giúp __ENCLIST mà nếu các assembly được biên dịch trong debug có thể tạo WeakReferences cho tất cả các đối tượng được tạo, lúc đầu tôi nghĩ đây là vấn đề, nhưng đã xác minh tất cả các assembly được triển khai.
tôi đã được sử dụng WinDBG để gỡ rối quá trình này, đây là vài dòng cuối cùng của !dumpheap -stat
000007fef788e0c0 39253 18510000 System.Collections.Hashtable+bucket[] 00000000021bf120 94336 151023192 Free 000007fef7887e98 5959 189838752 System.Char[] 000007fef7874390 517429 589750224 System.Object[] 000007fef78865a0 1531190 1230824112 System.String 000007fef787dab8 51723338 1655146816 System.WeakReference
Như bạn có thể thấy khoảng 1.5GB bộ nhớ đã được tiêu thụ bởi những System.WeakReferences.
Có ai có bất kỳ ý tưởng nào có thể tạo ra tất cả những yếu kém này không?
Các bạn đã thử profiling ứng dụng - một số profilers sẽ cho bạn biết phương pháp phân bổ vv .. Ngoài ra WeakReferences phải được tổ chức ở đâu đó làm như vậy một gcroot! có thể làm sáng tỏ. –
an toàn về số lượng? –
Cảm ơn Michael, tôi đã chạy gcroot và đầu ra như sau DOMAIN (000000000213D530): HANDLE (Pinned): 19813f0: Root: 000000017f4cf0e0 (System.Object []) -> 000000013f512608 (System.Collections.Generic .List'1 [[System.WeakReference, mscorlib]]) -> 000000018f932060 (System.Object []) -> 00000000ffe1b1a0 (System.WeakReference) Tất cả các trường hợp dẫn trở lại một Pinned System.Object [ ], đối tượng này [] chứa một lượng lớn dữ liệu khác, bất kỳ ý tưởng nào? – nickc