Gỡ lỗi rò rỉ bộ nhớ .NET - làm thế nào để biết những gì đang nắm giữ một tham chiếu đến những gì?

Question

Tôi đang làm việc trên ứng dụng .NET có vẻ như bị rò rỉ bộ nhớ. Tôi biết câu trả lời trong sách giáo khoa, các sự kiện đó phải được hủy đăng ký, các đối tượng dùng một lần nên được xử lý ...

Tôi có một dây nịt thử nghiệm có thể tái tạo lỗi. Trong finalizer của một lớp nào đó tôi viết để an ủi

public class Foo 
{ 
    // Ctor 
    public Foo() 
    { 
    } 

    ~public Foo() 
    { 
     Console.WriteLine("Foo Finalized"); 
    } 
} 

trong khai thác thử nghiệm, tôi đang tạo ra một trường hợp duy nhất của Foo (mà lần lượt tạo ra và tương tác với hàng trăm loại khác) sau đó loại bỏ nó và viện dẫn Thu gom rác.

Tôi tìm thấy Trình gỡ lỗi Foo không bao giờ được gọi. Tôi có một lớp học tương tự với thiết lập này được hoàn thành như một bài kiểm tra kiểm soát.

Vì vậy, câu hỏi của tôi là thế này:

Làm thế nào tôi có thể xác định bằng các công cụ mã nguồn thương mại hoặc mở chính xác những gì đang nắm giữ một tham chiếu đến Foo?

Tôi có giấy phép chuyên nghiệp cho trình thu thập thông tin bộ nhớ dotTrace nhưng không thể tìm ra từ các tệp trợ giúp về cách sử dụng nó.

Cập nhật: Tôi hiện đang sử dụng dotMemory 4.0, là bộ kế thừa cho bộ nhớ dotTrace (tốt, nhưng không thể sử dụng) 3.5.

Answer 1

Các finalizer không deterministically gọi, vì vậy hãy cẩn thận khi sử dụng nó để theo dõi mọi thứ theo một cách đáng tin cậy. Nếu bạn loại bỏ finalizer và thay vì sử dụng một WeakReference<Foo> bạn sẽ có thể xác định xem đối tượng đã được thu thập.

Tất cả các trình thu thập bộ nhớ sẽ có thể tìm thấy vấn đề như vậy, nhưng với mức độ khó khác nhau. Cá nhân tôi đã sử dụng ANTS rất dễ sử dụng, nhưng không miễn phí. Nó sẽ giúp bạn hiển thị một sơ đồ tham chiếu đến cá thể Foo, tất cả các cách từ đối tượng gốc GC. Thấy sơ đồ này, người ta thường dễ dàng nhận ra ai đang giữ tham chiếu.

Answer 2

Bạn có thể sử dụng trình thu thập bộ nhớ để xác định rò rỉ bộ nhớ. Dưới đây là một số người,

MemProfiler

ANTS Profiler

Answer 3

Có một số look tại số máy lẻ SOS debugger (miễn phí, có thể được sử dụng trong Visual Studio).

Bạn có thể tìm thấy this và this hữu ích để bắt đầu.

Nếu bạn đã succefully lập SOS (điều này có thể được khôn lanh đôi khi), biết những gì giữ một tham chiếu đến những gì là dễ dàng như

// load sos 
.load sos 
// list of all instances of YourTypeName in memory with their method tables 
!DumpHeap -type YourTypeName 
// put here the method table displayed by the previous command 
// it will show you the memory address of the object 
!DumpHeap -mt 07f66b44    
// displays information about references the object at the specified address 
!GCRoot 02d6ec94 

Answer 4

Trước hết bạn không nên sử dụng một finalizer, bởi vì:

hoạt động Finalize có những hạn chế sau:

• thời gian chính xác khi finalizer thực hiện trong thùng rác bộ sưu tập không xác định. Tài nguyên không được đảm bảo sẽ được phát hành tại bất kỳ thời điểm cụ thể nào trừ khi gọi phương thức Đóng hoặc phương thức Vứt bỏ.

• Các finalizers của hai đối tượng không được đảm bảo để chạy trong bất kỳ thứ tự cụ thể nào, ngay cả khi một đối tượng đề cập đến một đối tượng khác. Tức là, nếu Đối tượng A có tham chiếu đến Object B và cả hai đều có finalizers, Object B có thể đã hoàn thành khi finalizer của Object A bắt đầu.

• Chủ đề mà trình chạy finalizer được chạy không được chỉ định.

Trích dẫn từ: http://msdn.microsoft.com/en-us/library/system.object.finalize.aspx
tôi sẽ đề nghị sử dụng phương thức Dispose để thay thế.

Thứ hai, bất kỳ trình thu thập bộ nhớ nào cũng có thể tìm thấy những gì chứa các tham chiếu đó. Cá nhân tôi đã sử dụng ANTS Profiler, nó là một công cụ rất đẹp và có tài liệu khá phong phú. Bạn có thể thử đọc tài liệu này: http://downloads.red-gate.com/HelpPDF/ANTS_Memory_Profiler/InstanceCategorizer.pdf Trình phân loại thể hiện hiển thị chuỗi tham chiếu từ bộ đối tượng đến gốc GC.

Answer 5

Gỡ lỗi rò rỉ bộ nhớ có thể là quá trình tham gia khá và đòi hỏi sự hiểu biết thấu đáo về logic chương trình của bạn và ít nhất một số nội bộ .Net (đặc biệt là hành vi thu gom rác).

Để biết thêm thông tin xem các liên kết sau đây:

Tốt giới thiệu

• http://msdn.microsoft.com/en-us/library/ee658248.aspx

Hands-on khóa học:

• http://www.dotnetfunda.com/articles/article508.aspx
• http://www.dotnetfunda.com/articles/article524.aspx

GC và.internals Net

• http://blogs.msdn.com/b/tess/archive/2008/04/17/how-does-the-gc-work-and-what-are-the-sizes-of-the-different-generations.aspx
• http://msdn.microsoft.com/en-us/magazine/cc163491.aspx
• http://blogs.msdn.com/b/maoni/archive/2004/06/03/148029.aspx

WinDbg với phần mở rộng SOS

• http://www.codeproject.com/Articles/19490/Memory-Leak-Detection-in-NET
• http://www.simple-talk.com/dotnet/.net-framework/investigating-.net-memory-management-and-garbage-collection/

Chúc may mắn!