Rò rỉ bộ nhớ có được tạo ra nếu một dòng MemoryStream trong .NET không được đóng không?

Tôi có mã sau:

MemoryStream foo(){
    MemoryStream ms = new MemoryStream();
    // write stuff to ms
    return ms;
}

void bar(){
    MemoryStream ms2 = foo();
    // do stuff with ms2
    return;
}

Có khả năng nào mà MemoryStream mà tôi đã cấp phát bằng cách nào đó sẽ không được xử lý sau này không?

Tôi đã nhận được một đánh giá ngang hàng yêu cầu tôi đóng nó theo cách thủ công và tôi không thể tìm thấy thông tin để biết liệu anh ta có điểm hợp lệ hay không.

Nếu thứ gì đó dùng một lần, bạn luôn nên vứt bỏ nó. Bạn nên sử dụng một usingcâu lệnh trong bar()phương thức của mình để đảm bảo ms2được Xử lý.

Cuối cùng nó sẽ được dọn dẹp bởi bộ thu gom rác, nhưng cách gọi là Vứt bỏ luôn luôn là một thông lệ tốt. Nếu bạn chạy FxCop trên mã của mình, nó sẽ gắn cờ nó như một cảnh báo.

Bạn sẽ không bị rò rỉ bất cứ thứ gì - ít nhất là trong quá trình triển khai hiện tại.

Gọi Dispose sẽ không làm sạch bộ nhớ được sử dụng bởi MemoryStream nhanh hơn. Nó sẽ ngăn luồng của bạn khả thi cho các cuộc gọi Đọc / Viết sau cuộc gọi, điều này có thể hữu ích hoặc không hữu ích cho bạn.

Nếu bạn hoàn toàn chắc chắn rằng bạn không bao giờ muốn chuyển từ MemoryStream sang một loại luồng khác, việc không gọi Dispose sẽ không gây hại gì cho bạn. Tuy nhiên, đó là thực tế chung là tốt một phần là bởi vì nếu bạn đã bao giờ làm thay đổi sử dụng một Stream khác nhau, bạn không muốn bị cắn bởi một lỗi khó tìm vì bạn đã chọn một cách dễ dàng ra về sớm. (Mặt khác, có đối số YAGNI ...)

Lý do khác để làm điều đó dù sao đi nữa là một triển khai mới có thể giới thiệu các tài nguyên sẽ được giải phóng trên Dispose.

Có, có một rò rỉ , tùy thuộc vào cách bạn định nghĩa LEAK và mức độ LATER mà bạn muốn nói ...

Nếu do rò rỉ, bạn có nghĩa là "bộ nhớ vẫn được cấp phát, không có sẵn để sử dụng, mặc dù bạn đã sử dụng xong" và ý bạn là bất cứ lúc nào sau khi gọi vứt bỏ, thì có thể có một rò rỉ, mặc dù nó không vĩnh viễn (tức là thời gian chạy ứng dụng của bạn).

Để giải phóng bộ nhớ được quản lý được sử dụng bởi MemoryStream, bạn cần loại bỏ nó , bằng cách vô hiệu hóa tham chiếu của bạn đến nó, để nó đủ điều kiện để thu gom rác ngay lập tức. Nếu bạn không làm được điều này, thì bạn sẽ tạo ra một rò rỉ tạm thời kể từ khi bạn sử dụng xong nó, cho đến khi tham chiếu của bạn vượt ra ngoài phạm vi, vì trong thời gian này, bộ nhớ sẽ không có sẵn để cấp phát.

Lợi ích của câu lệnh using (chỉ đơn giản là gọi vứt bỏ) là bạn có thể KHAI BÁO tham chiếu của mình trong câu lệnh using. Khi câu lệnh using kết thúc, không chỉ được gọi, mà tham chiếu của bạn sẽ vượt ra ngoài phạm vi, vô hiệu hóa tham chiếu một cách hiệu quả và làm cho đối tượng của bạn đủ điều kiện để thu gom rác ngay lập tức mà không yêu cầu bạn phải nhớ viết mã "reference = null".

Mặc dù việc không can thiệp vào điều gì đó ngay lập tức không phải là lỗi rò rỉ bộ nhớ "vĩnh viễn" cổ điển, nhưng nó chắc chắn có tác dụng tương tự. Ví dụ: nếu bạn giữ tham chiếu của mình tới Dòng bộ nhớ (ngay cả sau khi gọi lệnh hủy), và xa hơn một chút trong phương thức của mình, bạn cố gắng cấp thêm bộ nhớ ... bộ nhớ đang được sử dụng bởi dòng bộ nhớ vẫn tham chiếu của bạn sẽ không có sẵn cho bạn cho đến khi bạn vô hiệu hóa tham chiếu hoặc nó vượt ra khỏi phạm vi, mặc dù bạn đã gọi là vứt bỏ và đã sử dụng xong.

Không cần gọi .Dispose()(hoặc gói bằng Using).

Lý do bạn gọi .Dispose()là để giải phóng tài nguyên càng sớm càng tốt .

Hãy nghĩ về máy chủ Stack Overflow, nơi chúng tôi có một bộ nhớ giới hạn và hàng nghìn yêu cầu đến. Chúng tôi không muốn chờ đợi cho quá trình thu gom rác theo lịch trình, chúng tôi muốn giải phóng bộ nhớ đó càng sớm càng tốt để nó có sẵn cho các yêu cầu mới đến.

Điều này đã được trả lời, nhưng tôi sẽ chỉ nói thêm rằng nguyên tắc ẩn thông tin cổ điển có nghĩa là bạn có thể muốn tái cấu trúc lại:

MemoryStream foo()
{    
    MemoryStream ms = new MemoryStream();    
    // write stuff to ms    
    return ms;
}

đến:

Stream foo()
{    
   ...
}

Điều này nhấn mạnh rằng người gọi không nên quan tâm đến loại Luồng nào đang được trả về và có thể thay đổi việc triển khai nội bộ (ví dụ: khi chế nhạo để thử nghiệm đơn vị).

Sau đó, bạn sẽ gặp rắc rối nếu bạn chưa sử dụng Dispose trong triển khai thanh của mình:

void bar()
{    
    using (Stream s = foo())
    {
        // do stuff with s
        return;
    }
}

Tất cả các luồng đều triển khai IDisposable. Kết hợp dòng Bộ nhớ của bạn trong một câu lệnh sử dụng và bạn sẽ ổn và đẹp đẽ. Việc sử dụng chặn sẽ đảm bảo luồng của bạn bị đóng và bị xử lý bất kể điều gì.

bất cứ nơi nào bạn gọi Foo, bạn có thể thực hiện bằng cách sử dụng (MemoryStream ms = foo ()) và tôi nghĩ bạn vẫn sẽ ổn.

Bạn sẽ không bị rò rỉ bộ nhớ, nhưng người đánh giá mã của bạn đã chính xác để chỉ ra rằng bạn nên đóng luồng của mình. Thật lịch sự khi làm như vậy.

Tình huống duy nhất mà bạn có thể bị rò rỉ bộ nhớ là khi bạn vô tình để lại một tham chiếu đến luồng và không bao giờ đóng nó. Bạn vẫn không thực sự rò rỉ bộ nhớ, nhưng bạn đang không cần thiết mở rộng số lượng thời gian mà bạn yêu cầu bồi thường được sử dụng nó.

Tôi khuyên bạn nên gói MemoryStream bar()trong một usingcâu lệnh chủ yếu để có tính nhất quán:

• Hiện tại MemoryStream không giải phóng bộ nhớ .Dispose(), nhưng có thể vào một thời điểm nào đó trong tương lai, hoặc bạn (hoặc người khác ở công ty của bạn) có thể thay thế nó bằng MemoryStream tùy chỉnh của riêng bạn, v.v.
• Nó giúp thiết lập một mô hình trong dự án của bạn để đảm bảo tất cả các Luồng đều được xử lý - dòng này được vẽ chắc chắn hơn bằng cách nói "tất cả các Luồng phải được xử lý" thay vì "một số Luồng phải được xử lý, nhưng một số Luồng nhất định không cần phải xử lý" ...
• Nếu bạn từng thay đổi mã để cho phép trả lại các loại Luồng khác, bạn vẫn cần phải thay đổi mã đó để loại bỏ.

Một điều khác mà tôi thường làm trong các trường hợp như foo()khi tạo và trả lại IDisposable là đảm bảo rằng bất kỳ lỗi nào giữa việc xây dựng đối tượng và đối tượng returnđều bị bắt bởi một ngoại lệ, loại bỏ đối tượng và ném lại ngoại lệ:

MemoryStream x = new MemoryStream();
try
{
    // ... other code goes here ...
    return x;
}
catch
{
    // "other code" failed, dispose the stream before throwing out the Exception
    x.Dispose();
    throw;
}

Nếu một đối tượng triển khai IDisposable, bạn phải gọi phương thức .Dispose khi hoàn tất.

Trong một số đối tượng, Dispose có nghĩa giống như Close và ngược lại, trong trường hợp đó, cũng tốt.

Bây giờ, đối với câu hỏi cụ thể của bạn, không, bạn sẽ không bị rò rỉ bộ nhớ.

Tôi không phải là chuyên gia .net, nhưng có lẽ vấn đề ở đây là tài nguyên, cụ thể là trình xử lý tệp, chứ không phải bộ nhớ. Tôi đoán rằng trình thu gom rác cuối cùng sẽ giải phóng luồng và đóng tay cầm, nhưng tôi nghĩ rằng cách tốt nhất là đóng nó một cách rõ ràng, để đảm bảo bạn xả hết nội dung vào đĩa.

Việc thải bỏ các tài nguyên không được quản lý là không thể xác định trong các ngôn ngữ thu gom rác. Ngay cả khi bạn gọi Dispose một cách rõ ràng, bạn hoàn toàn không kiểm soát được thời điểm bộ nhớ sao lưu thực sự được giải phóng. Dispose được gọi một cách ngầm định khi một đối tượng vượt ra khỏi phạm vi, cho dù đó là bằng cách thoát khỏi câu lệnh using hoặc bật lên callstack từ một phương thức cấp dưới. Tất cả điều này đang được nói, đôi khi đối tượng thực sự có thể là một trình bao bọc cho một tài nguyên được quản lý (ví dụ: tệp). Đây là lý do tại sao bạn nên đóng một cách rõ ràng trong các câu lệnh cuối cùng hoặc sử dụng câu lệnh using. Chúc mừng

MemorySteram không là gì ngoài mảng byte, là đối tượng được quản lý. Quên vứt bỏ hoặc đóng cửa này không có tác dụng phụ nào khác ngoài việc vượt qua giai đoạn hoàn thiện đầu.
Chỉ cần kiểm tra hằng số hoặc phương thức tuôn ra của MemoryStream trong bộ phản xạ và sẽ rõ tại sao bạn không cần phải lo lắng về việc đóng hoặc loại bỏ nó ngoài vấn đề thực hành tốt.