Theo kinh nghiệm của tôi, có vẻ như hầu hết mọi người sẽ nói với bạn rằng ép thu gom rác là không khôn ngoan nhưng trong một số trường hợp bạn đang làm việc với các đối tượng lớn không phải lúc nào cũng được thu thập ở thế hệ 0 nhưng bộ nhớ là một vấn đề, nó ok để buộc thu thập? Có phương pháp nào tốt nhất để làm như vậy không?
Câu trả lời:
Cách tốt nhất là không ép thu gom rác.
Theo MSDN:
"Có thể buộc thu gom rác bằng cách gọi Collect, nhưng hầu hết thời gian, điều này nên tránh vì nó có thể tạo ra các vấn đề về hiệu suất."
Tuy nhiên, nếu bạn có thể kiểm tra đáng tin cậy mã của mình để xác nhận rằng việc gọi Collect () sẽ không có tác động tiêu cực thì hãy tiếp tục ...
Chỉ cần cố gắng đảm bảo các đồ vật được dọn dẹp khi bạn không cần nữa. Nếu bạn có các đối tượng tùy chỉnh, hãy xem bằng cách sử dụng câu lệnh "using" và giao diện IDisposable.
Liên kết này có một số lời khuyên thực tế tốt liên quan đến việc giải phóng bộ nhớ / thu gom rác, v.v.:
TargetOfInvocationNullException.
Hãy xem xét nó theo cách này - sẽ hiệu quả hơn khi vứt rác nhà bếp khi thùng rác ở mức 10% hay để nó đầy trước khi lấy ra?
Bằng cách không để nó đầy, bạn đang lãng phí thời gian đi bộ đến và đi từ thùng rác bên ngoài. Điều này tương tự như những gì xảy ra khi luồng GC chạy - tất cả các luồng được quản lý đều bị treo trong khi nó đang chạy. Và nếu tôi không nhầm, luồng GC có thể được chia sẻ giữa nhiều AppDomains, vì vậy việc thu gom rác ảnh hưởng đến tất cả chúng.
Tất nhiên, bạn có thể gặp phải một tình huống mà bạn sẽ không sớm thêm bất cứ thứ gì vào thùng rác - giả sử, nếu bạn sắp đi nghỉ. Sau đó, sẽ là một ý kiến hay nếu bạn vứt rác vào thùng rác trước khi ra ngoài.
Điều này ĐÚNG là một lần buộc GC có thể giúp ích - nếu chương trình của bạn chạy không tải, bộ nhớ đang sử dụng sẽ không được thu gom vì không có phân bổ.
Cách tốt nhất là không ép thu gom rác trong hầu hết các trường hợp. (Mọi hệ thống tôi đã từng làm việc đều buộc phải thu gom rác, đều có những vấn đề cơ bản mà nếu được giải quyết sẽ giúp loại bỏ nhu cầu buộc thu gom rác và tăng tốc hệ thống lên rất nhiều.)
Có một vài trường hợp khi bạn biết thêm về cách sử dụng bộ nhớ thì bộ thu dọn rác sẽ làm. Điều này khó có thể đúng trong một ứng dụng nhiều người dùng hoặc một dịch vụ đang phản hồi nhiều hơn một yêu cầu tại một thời điểm.
Tuy nhiên, trong một số xử lý kiểu hàng loạt, bạn biết nhiều hơn GC. Ví dụ: xem xét một ứng dụng đó.
Bạn có thể đưa ra một trường hợp (sau khi kiểm tra cẩn thận) rằng bạn nên buộc thu thập rác đầy đủ sau khi bạn xử lý từng tệp.
Một trường hợp khác là một dịch vụ thức dậy sau vài phút để xử lý một số mặt hàng và không giữ trạng thái nào khi nó đang ngủ . Sau đó, buộc một bộ sưu tập đầy đủ ngay trước khi đi ngủ có thể đáng giá.
Lần duy nhất tôi muốn xem xét việc buộc một bộ sưu tập là khi tôi biết rằng rất nhiều đối tượng đã được tạo gần đây và rất ít đối tượng hiện được tham chiếu.
Tôi thà có một API thu gom rác khi tôi có thể cho nó gợi ý về loại thứ này mà không cần phải ép buộc GC của chính tôi.
Xem thêm " Rico Mariani's Performance Tidbits "
Tôi nghĩ ví dụ do Rico Mariani đưa ra là tốt: có thể thích hợp để kích hoạt GC nếu có sự thay đổi đáng kể trong trạng thái của ứng dụng. Ví dụ: trong trình chỉnh sửa tài liệu, có thể kích hoạt GC khi đóng tài liệu.
Có một số hướng dẫn chung trong lập trình là tuyệt đối. Một nửa thời gian, khi ai đó nói 'bạn đang làm sai', họ chỉ đang nói ra một lượng giáo điều nhất định. Trong C, nó từng sợ những thứ như mã hoặc luồng tự sửa đổi, trong các ngôn ngữ GC, nó đang buộc GC hoặc cách khác là ngăn GC chạy.
Như trường hợp của hầu hết các hướng dẫn và quy tắc chung (và thực hành thiết kế tốt), hiếm khi có ý nghĩa khi làm việc theo quy chuẩn đã được thiết lập. Bạn phải chắc chắn rằng bạn hiểu trường hợp này, trường hợp của bạn thực sự cần phải loại bỏ thông lệ và bạn hiểu những rủi ro và tác dụng phụ mà bạn có thể gây ra. Nhưng có những trường hợp như vậy.
Các bài toán lập trình rất đa dạng và đòi hỏi một cách tiếp cận linh hoạt. Tôi đã thấy các trường hợp có ý nghĩa khi chặn GC bằng các ngôn ngữ được thu thập rác và những nơi có ý nghĩa để kích hoạt nó hơn là đợi nó xảy ra một cách tự nhiên. 95% thời gian, một trong hai điều này sẽ là dấu hiệu cho thấy bạn chưa tiếp cận đúng vấn đề. Nhưng 1 lần trong năm 20, có lẽ có một trường hợp hợp lệ được thực hiện cho nó.
Tôi đã học được cách không cố gắng vượt qua việc thu gom rác. Như đã nói, tôi chỉ cần sử dụng usingtừ khóa khi xử lý các tài nguyên không được quản lý như tệp I / O hoặc kết nối cơ sở dữ liệu.
Không chắc đó có phải là phương pháp hay nhất hay không, nhưng khi làm việc với số lượng lớn hình ảnh trong một vòng lặp (tức là tạo và loại bỏ nhiều đối tượng Đồ họa / Hình ảnh / Bitmap), tôi thường xuyên để GC.Collect.
Tôi nghĩ rằng tôi đã đọc ở đâu đó rằng GC chỉ chạy khi chương trình (hầu hết) không hoạt động và không ở giữa vòng lặp chuyên sâu, vì vậy điều đó có thể giống như một lĩnh vực mà GC thủ công có thể có ý nghĩa.
Một trường hợp gần đây tôi gặp phải yêu cầu các lệnh gọi thủ công GC.Collect()là khi làm việc với các đối tượng C ++ lớn được bao bọc trong các đối tượng C ++ được quản lý nhỏ, đến lượt chúng được truy cập từ C #.
Bộ thu gom rác không bao giờ được gọi vì lượng bộ nhớ được quản lý được sử dụng không đáng kể, nhưng lượng bộ nhớ không được quản lý được sử dụng là rất lớn. Việc gọi Dispose()các đối tượng theo cách thủ công sẽ yêu cầu tôi phải tự theo dõi khi nào các đối tượng không còn cần thiết nữa, trong khi việc gọi GC.Collect()sẽ dọn dẹp bất kỳ đối tượng nào không còn được giới thiệu .....
GC.AddMemoryPressure (ApproximateSizeOfUnmanagedResource)hàm tạo và sau đó GC.RemoveMemoryPressure(addedSize)trong trình hoàn thiện. Bằng cách này, bộ thu gom rác sẽ tự động chạy, có tính đến kích thước của các cấu trúc không được quản lý có thể được thu gom. stackoverflow.com/questions/1149181/…
Tôi nghĩ rằng bạn đã liệt kê các phương pháp hay nhất và đó là KHÔNG sử dụng nó trừ khi THỰC SỰ cần thiết. Tôi thực sự khuyên bạn nên xem mã của bạn chi tiết hơn, sử dụng các công cụ lập hồ sơ nếu cần để trả lời những câu hỏi này trước tiên.
Giả sử chương trình của bạn không bị rò rỉ bộ nhớ, các đối tượng tích lũy và không thể được GC-ed trong Gen 0 vì: 1) Chúng được tham chiếu trong một thời gian dài, vì vậy hãy vào Gen1 & Gen2; 2) Chúng là những vật thể lớn (> 80K) nên được đưa vào LOH (Large Object Heap). Và LOH không thực hiện việc thu gọn như trong Gen0, Gen1 & Gen2.
Kiểm tra bộ đếm hiệu suất của "Bộ nhớ .NET" bạn có thể thấy rằng vấn đề 1) thực sự không phải là vấn đề. Nói chung, cứ 10 GC Gen0 sẽ kích hoạt 1 GC Gen1 và cứ 10 GC Gen1 sẽ kích hoạt 1 Gen2 GC. Về mặt lý thuyết, GC1 & GC2 không bao giờ có thể là GC-ed nếu không có áp lực lên GC0 (nếu việc sử dụng bộ nhớ chương trình thực sự có dây). Nó không bao giờ xảy ra với tôi.
Đối với vấn đề 2), bạn có thể kiểm tra bộ đếm hiệu suất "Bộ nhớ .NET" để xác minh xem LOH có bị phình ra hay không. Nếu nó thực sự là một vấn đề với vấn đề của bạn, có lẽ bạn có thể tạo một nhóm đối tượng lớn như blog này gợi ý http://blogs.msdn.com/yunjin/archive/2004/01/27/63642.aspx .
Các đối tượng lớn được phân bổ trên LOH (đống đối tượng lớn), không phải trên gen 0. Nếu bạn đang nói rằng chúng không được thu gom rác với gen 0, bạn đã đúng. Tôi tin rằng chúng chỉ được thu thập khi chu kỳ GC đầy đủ (thế hệ 0, 1 và 2) xảy ra.
Nói như vậy, tôi tin rằng ở phía bên kia, GC sẽ điều chỉnh và thu thập bộ nhớ mạnh mẽ hơn khi bạn làm việc với các vật thể lớn và áp lực bộ nhớ đang tăng lên.
Thật khó để nói có nên thu hay không và trong hoàn cảnh nào. Tôi đã từng làm GC.Collect () sau khi loại bỏ các cửa sổ hộp thoại / biểu mẫu với nhiều điều khiển, v.v. (vì vào thời điểm biểu mẫu và các điều khiển của nó kết thúc ở thế hệ 2 do tạo nhiều phiên bản đối tượng nghiệp vụ / tải nhiều dữ liệu - không các đối tượng lớn rõ ràng), nhưng thực sự không nhận thấy bất kỳ tác động tích cực hay tiêu cực nào về lâu dài bằng cách làm như vậy.
Tôi muốn nói thêm rằng: Gọi GC.Collect () (+ WaitForPendingFinalizers ()) là một phần của câu chuyện. Như những người khác đã đề cập đúng đến, GC.COllect () là tập hợp không xác định và được để theo quyết định của chính GC (CLR). Ngay cả khi bạn thêm lệnh gọi vào WaitForPendingFinalizers, nó có thể không xác định được. Lấy mã từ liên kết msdn này và chạy mã với phép lặp vòng lặp đối tượng là 1 hoặc 2. Bạn sẽ tìm thấy ý nghĩa không xác định (đặt điểm ngắt trong bộ hủy của đối tượng). Chính xác, hàm hủy không được gọi khi chỉ có 1 (hoặc 2) đối tượng còn sót lại bởi Wait .. (). [Citation reqd.]
Nếu mã của bạn đang xử lý tài nguyên không được quản lý (ví dụ: xử lý tệp bên ngoài), bạn phải triển khai trình hủy (hoặc trình hoàn thiện).
Đây là một ví dụ thú vị:
Lưu ý : Nếu bạn đã thử ví dụ trên từ MSDN, đoạn mã sau sẽ xóa không khí.
class Program
{
static void Main(string[] args)
{
SomePublisher publisher = new SomePublisher();
for (int i = 0; i < 10; i++)
{
SomeSubscriber subscriber = new SomeSubscriber(publisher);
subscriber = null;
}
GC.Collect();
GC.WaitForPendingFinalizers();
Console.WriteLine(SomeSubscriber.Count.ToString());
Console.ReadLine();
}
}
public class SomePublisher
{
public event EventHandler SomeEvent;
}
public class SomeSubscriber
{
public static int Count;
public SomeSubscriber(SomePublisher publisher)
{
publisher.SomeEvent += new EventHandler(publisher_SomeEvent);
}
~SomeSubscriber()
{
SomeSubscriber.Count++;
}
private void publisher_SomeEvent(object sender, EventArgs e)
{
// TODO: something
string stub = "";
}
}Tôi đề nghị, trước tiên hãy phân tích đầu ra có thể là gì, sau đó chạy và sau đó đọc lý do bên dưới:
{Hàm hủy chỉ được gọi ngầm sau khi chương trình kết thúc. } Để làm sạch đối tượng một cách xác định, người ta phải triển khai IDisposable và thực hiện một lệnh gọi rõ ràng tới Dispose (). Đó là bản chất! :)
Một điều nữa, việc kích hoạt GC Collect một cách rõ ràng KHÔNG thể cải thiện hiệu suất chương trình của bạn. Nó hoàn toàn có thể làm cho nó tồi tệ hơn.
.NET GC được thiết kế tốt và điều chỉnh để thích ứng, có nghĩa là nó có thể điều chỉnh ngưỡng GC0 / 1/2 theo "thói quen" sử dụng bộ nhớ chương trình của bạn. Vì vậy, nó sẽ được điều chỉnh cho phù hợp với chương trình của bạn sau một thời gian chạy. Khi bạn gọi GC.Collect một cách rõ ràng, các ngưỡng sẽ được đặt lại! Và .NET lại phải dành thời gian để thích nghi với "thói quen" chương trình của bạn.
Đề xuất của tôi là luôn tin tưởng .NET GC. Bất kỳ vấn đề bộ nhớ nào xuất hiện, hãy kiểm tra bộ đếm hiệu suất "Bộ nhớ .NET" và chẩn đoán mã của riêng tôi.
Không chắc liệu đó có phải là phương pháp hay nhất ...
Đề xuất: không thực hiện điều này hoặc bất cứ điều gì khi không chắc chắn. Đánh giá lại khi biết được sự thật, sau đó thực hiện các bài kiểm tra hiệu suất trước / sau để xác minh.
Tuy nhiên, nếu bạn có thể kiểm tra đáng tin cậy mã của mình để xác nhận rằng việc gọi Collect () sẽ không có tác động tiêu cực thì hãy tiếp tục ...
IMHO, điều này tương tự như câu nói "Nếu bạn có thể chứng minh rằng chương trình của bạn sẽ không bao giờ có bất kỳ lỗi nào trong tương lai, thì hãy tiếp tục ..."
Nhìn chung, việc ép buộc GC rất hữu ích cho mục đích gỡ lỗi / kiểm tra. Nếu bạn cảm thấy cần phải làm điều đó vào bất kỳ thời điểm nào khác, thì có thể là bạn đã nhầm hoặc chương trình của bạn đã được xây dựng sai. Dù bằng cách nào, giải pháp không buộc GC ...