MemoryStream.Close () 또는 MemoryStream.Dispose ()
누구에게 전화해야합니까?
둘 다 전화해야합니까?
이미 그들 중 하나를 호출 한 경우 다른 하나가 예외를 throw합니까?
Close()및 Dispose()에서 호출되면 MemoryStream두 가지 작업 만 수행합니다.
- 나중에 실수로 개체를 사용하면 예외가 발생하도록 개체를 삭제 한 것으로 표시합니다.
- 아마도 1 GC의 구현에 따라 조금 더 쉽게 GC의 작업을 할 수 있습니다 관리되는 개체에 릴리스 참조. (오늘날의 GC 알고리즘에서는 실질적인 차이가 없으므로 이것은 학문적 토론의 요점이며 실제 세계에 큰 영향을 미치지 않습니다.)
MemoryStream처리 할 관리되지 않는 리소스가 없으므로 기술적으로 처리 할 필요가 없습니다. a를 처리하지 않는 효과는 MemoryStreama에 대한 참조를 삭제하는 것과 거의 동일 byte[]합니다. GC는 둘 다 같은 방식으로 정리합니다.
누구에게 전화해야합니까? 둘 다 전화해야합니까?
Dispose()스트림 의 메서드는 메서드 2에 직접 위임Close() 되므로 둘 다 정확히 동일한 작업을 수행합니다.
이미 그들 중 하나를 호출 한 경우 다른 하나가 예외를 throw합니까?
에 대한 설명서에는IDisposable.Dispose()Dispose() 모든 객체 3 에서 여러 번 호출하는 것이 안전하다고 명시되어 있습니다. (특정 클래스에 해당하지 않는 경우 해당 클래스 IDisposable는 계약을 위반하는 방식으로 인터페이스를 구현 하며 이는 버그입니다.)
즉, 처분 여부에 관계없이 실제로 큰 차이를 만들지 MemoryStream않습니다. Close/ Dispose메서드가 있는 유일한 이유 는에서 상속하기 때문 Stream입니다. 계약의 일부로 해당 메서드 가 관리되지 않는 리소스 (예 : 파일 또는 소켓 설명자) 가 있는 스트림을 지원 해야 합니다.
1 Mono의 구현 은 byte[]참조를 해제하지 않습니다 . Microsoft 구현이 있는지 모르겠습니다.
2 "이 메서드는 Close를 호출 한 다음 Stream.Dispose (Boolean)를 호출합니다."
3 "개체의 Dispose 메서드가 두 번 이상 호출되면 개체는 첫 번째 호출 이후의 모든 호출을 무시해야합니다."
이를 위해 using블록을 사용할 수 있습니다 . Dispose범위를 벗어나면 자동으로 호출 됩니다.
예:
using (MemoryStream ms = new MemoryStream())
{
// Do something with ms..
}
// ms is disposed here
이것이 도움이 되었기를 바랍니다.
인터페이스를 using구현하는 경우 개체가 삭제되도록 블록을 사용하십시오.IDisposable
다음 코드는 Stream.Dispose from reflector입니다. 처리하면 닫을 필요가 없습니다 (사용시 암시적임).
public void Dispose()
{
this.Close();
}
누구에게 전화해야합니까?
그들 중 하나.
둘 다 전화해야합니까?
아니, 둘 다 충분합니다.
이미 그들 중 하나를 호출 한 경우 다른 하나가 예외를 throw합니까?
아니요, 일회용 패턴은 Dispose에 대한 후속 호출이 부정적인 영향을 미치지 않는다고 선언합니다.
위의 어느 것도 없습니다. 당신도 호출 할 필요는 없습니다 Close나 Dispose.
MemoryStream관리되지 않는 리소스를 보유하지 않으므로 회수 할 유일한 리소스는 메모리입니다. MemoryStream코드가 더 이상 .NET Framework를 참조하지 않으면 나머지 개체 와 함께 가비지 수집 중에 메모리가 회수됩니다 MemoryStream.
에 대한 오래 지속되는 참조가있는 MemoryStream경우 해당 참조를 null로 설정 MemoryStream하여을 가비지 수집 할 수 있습니다. Close및 Dispose무료 증기 버퍼도 나 MemoryStream적절한 객체입니다.
어느 쪽도 이후 Stream도하는 MemoryStream파이널 라이저가없는, 호출 할 필요가 없다 Close또는 Dispose원인 GC.SuppressFinalize최적화 가비지 컬렉션에 호출 할 수는. 억제 할 종료자가 없습니다.
MemoryStream 에 대한 문서 는 다음과 같이 설명합니다.
이 유형은
IDisposable인터페이스를 구현 하지만 실제로 처리 할 리소스가 없습니다. 즉, 직접 호출Dispose()하거나using(C #에서) 또는Using(Visual Basic에서 ) 와 같은 언어 구조를 사용하여 삭제할 필요가 없습니다.
Close ()를 호출하면 내부적으로 Dispose ()를 호출하여 리소스를 해제합니다.
자세한 내용은 다음 링크를 참조하십시오. msdn
전화 만하면 Dispose()트릭 =)
In .NET 3.5 (haven't checked other versions), methods are called in the following order when disposing a MemoryStream:
- Stream.Dispose()
- simply calls Close
- Stream.Close()
- calls Dispose(true), then GC.SuppressFinalize(this)
- MemoryStream.Dispose(true)
- sets _isOpen , _writable, and _expandable flags to false
- Stream.Dispose(true)
- closes async event if active
As a first solution, it's recommended to use using statements wherever possible. This is described here: http://msdn.microsoft.com/en-us/library/yh598w02.aspx
When the lifetime of an IDisposable object is limited to a single method, you should declare and instantiate it in the using statement. The using statement calls the Dispose method on the object in the correct way, and (when you use it as shown earlier) it also causes the object itself to go out of scope as soon as Dispose is called. Within the using block, the object is read-only and cannot be modified or reassigned.
Coming to the question now, as others suggested in most .NET framework classes, there is no difference between Close() and Dispose() and it doesn't matter which of the two methods you call. You should call one but not both. However, there are exceptions.
There are exceptions; for example, System.Windows.Forms.Form and System.Data.SqlClient.SqlConnection have different behavior for Close() and Dispose().
For complete details, you can check here: https://blogs.msdn.microsoft.com/kimhamil/2008/03/15/the-often-non-difference-between-close-and-dispose/
참고URL : https://stackoverflow.com/questions/4274590/memorystream-close-or-memorystream-dispose
'IT TIP' 카테고리의 다른 글
| csv 데이터를 django 모델로 가져 오는 방법 (0) | 2020.12.10 |
|---|---|
| IE 8에서 JSON.stringify ()를 지원합니까? (0) | 2020.12.10 |
| 복합 디자인 패턴은 언제 사용해야합니까? (0) | 2020.12.10 |
| 문제 : 치명적 오류 : [] 연산자가 문자열에 지원되지 않음 (0) | 2020.12.10 |
| Gunicorn Nginx 시간 초과 문제 (0) | 2020.12.10 |