제목 그대로 WeakReference 라는 클래스가 궁금하네요. 개발을 하다보면 .NET 소스 코드에 자주 등장하는데 굳이 사용하는 이유를 모르겠네요. 언제 GC 당할지 모르는 참조를 사용하면 성능이 향상되니까 사용하는 것 같아보이는데, 구체적으로 어떤 원리로 성능을 향상시키는 건지 알고 싶습니다.
위 .NET 코드처럼 주로 특정 클래스에 UI 작업을 할 때 많이 등장하는데, WeakReference 가 아니라 실제 참조를 가지고 있으면 UI 객체가 GC 가 되지 않으니, UI 객체가 GC 될 수 있도록 WeakReference 를 사용하는게 아닐까 추측하고 있습니다.
이외에도 사용하는 부분들이 보이는데 어떤 목적과 이점이 있어서 사용하는건지 알고 싶습니다.
제가 알기로 WeakReference는 주소 캐싱용도로 사용한다고 알고 있습니다.
아시다시피 C#에서 객체를 참조하면 레퍼런스 카운트가 올라가는데, WeakReference는 레퍼런스 카운트를 올리지 않고 객체를 참조 할 수 있어서, 이 객체가 GC에 의해 제거된건지 파악하는 용도로 사용한다고 알고 있습니다.
WeakReference의 IsAlive 속성을 통해 수집되었는지 여부를 체크하는 용도라고 기억하고 있습니다.
책에 써있는 문구를 그대로 쓰자면, (써도 되는지는 모르겠지만…문제가 있다면 삭제하겠습니다.)
약한 참조는 가비지 수집기에서 개체를 정리할 수 있게 해주는 개체에 대한 참조다. 반대는 (그 개체에 대해) 수집을 방지하는 강한 참조다. 약한 참조는 유지하고 싶은 비용이 높은 개체를 캐시하는데 주로 유용하지만, 충분한 메모리 압력이 있다면 참조를 풀어주려 한다.
WeakReference는 IsAlive 속성을 갖지만, 해당 개체가 살아 있는 경우가 아니라 죽은 경우인지 결정하는 데만 유용하다. IsAlive를 검사했는데 값이 true라면, IsAlive 속성을 검사한 후 해당 개체를 수집할 수 있는 가비지 수집기와 경쟁에 있는 것이다. 개체 참조를 소유한 강한 참조로 복사하고 거기서 확인하자.
WeakReference를 사용하는 아주 좋은 방법은 개체가 강한 참조에 잡혀 시작할 수 있는 캐시 부분이다. 이는 사용되지 않은 충분한 시간이 지난 후 개체가 강등되어 궁극적으로 사라질 수 있는 약한 참조가 될 수 있다.
제가 이해한 것은 조금 다릅니다. 그런데 이게 맞는지는 아직 잘 모르겠어요.
아래 내용은 제가 이해한 내용으로 정확하지 않은 부분이 있을 수 있으니 참고 부탁합니다.
(저도 실제 사용해본 적이 없었기 때문에 이번 기회로 알게된/이해한 내용을 업무에 천천히 적용해볼까 합니다)
일단 GC의 가비지 수집을 막기 위한 캐싱은 적절하지 않은 것 같아요.
제가 이해한 WeakReference의 사용시점은 주로 UI 객체를 다룰때로, WPF 기준으로 설명드리자면 하나의 ViewModel이 있는 Control에서 다른 UI 객체에 접근할 때 필요할 것 같아요.
같은 View/ViewModel은 생명주기를 같이하기 때문에 문제없어 보이지만, 다른 UI 객체는 생명주기가 다를 확률이 높기 때문입니다.
예를들면 어떤 페이지(Some)의 View/ViewModel이 있고 그 ViewModel이 다른 페이지(Other)의 View를 참고해야 하는 상황이면 보통 아래와 같이 작성할 것 같은데요.
public class SomeViewModel
{
protected OtherView OtherView { get; set; }
}
이 과정에서 OtherView는 SomeViewModel에서 참조를 하나 하고 있기 때문에 정상적으로 소멸해야 할 시점에 소멸할 수 없게 됩니다.
그래서 OtherView의 참조 카운트가 오르지 않으면서 해당 객체를 사용할 수 있는 방법이 WeakReference 같아요.
public class SomeViewModel
{
protected WeakReference<OtherView> OtherView { get; set; }
}
이렇게 사용할 경우 OtherView의 생명주기에 영향을 주지 않으면서 해당 객체를 활용할 수 있습니다
(단, WeakReference의 Target을 보관하고 있으면 안됩니다! 사용 시점에만 호출해서 사용해야 합니다).
그리고 이벤트 쪽도 사용할 때 주의가 필요하며 이를 활용할 수 있습니다.
마지막으로 맨 위에 언급한 캐싱 목적은 아래 페이지에도 언급이 되어 있듯이 단순 “메모리 관리 문제에 대한 자동 솔루션으로 Weak References를 사용하지 않습니다. 대신, 애플리케이션의 개체를 처리하기 위한 효과적인 캐싱 정책을 개발합니다.” 처럼 큰 메모리를 다루는 것은 별도 관리할 수 있는 유틸리티를 만드는 것이 좋을 것 같습니다.
이번에 검색하다가 지나가다 본 글로 IDisposable를 이용해서 만드는 것을 권장하는 걸 본 것 같아요.
일단 제가 말씀드린 부분 중 오해를 수정드리자면, WeakReference를 적용한다고 해서 GC가 제거하지 못하는 것이 아닙니다. 말씀하신대로 레퍼런스 카운트가 증가되지 않기 때문에(저도 위에 댓글에서 레퍼런스 카운트가 올라가지 않는다고 언급했습니다.) 어차피 마크-스윕의 대상이 되는거고, 캐싱이라는 단어때문에 오해가 발생한 듯 한데, GC에서 제거 되었는지 확인만 하는 의도로서 참조 캐싱이라 말씀드린 것입니다. 책에도 그렇게 적혀있어서 고대로 썼더니 오해가 생겼네요…ㅎㅎ
제가 책에서 그대로 인용한 문구에도 보시면 해당 개체가 살아 있는 경우가 아니라 죽은 경우인지 결정하는데만 유용하다. 라고 써놨습니다. 따라서 GC가 되지 않는 것은 아닙니다.
따라서 말씀하신 부분과 제가 말하는 의도는 일치한다고 봅니다. 객체가 사라졌는지 확인한다는 의미에서요.
@level120 저도 정확하게 설명하지 않아서 오해가 발생한거 같네요. 정확하게는 객체를 GC 가 컬랙트하지 못하도록 붙잡는다는 뜻은 아닙니다. 그럴 용도라면 약한 참조 자체를 사용할 필요가 없으니까요. 다만 약한 참조를 사용하게 된다면 그 의도가 GC 에게 수집되는 조건을 만족한 객체를 다시 강한 참조로 붙잡을 수 있도록 참조를 캐싱해놓는 용도가 아닐까하는 의미입니다. 메모리 관리보다는 객체가 생명을 다하기 전에 다시 한번 살아날 기회를 만드는 용도가 아닐까요?
첨부해주신 '약한 이벤트 패턴’은 현재 진행하는 프로젝트에 유용하게 사용할 수 있을거 같습니다. 감사합니다. ㅎㅎ
https://www.sysnet.pe.kr/2/0/1740
참고하시면 좋을 것 같습니다.
C++의 week_ptr과 같은 이유로 만들어진 것 같아서 찾아보니
거의 같은 것 같습니다. 순환참조 해결이 주된 사용처이고 그 외에는
메인 타스크에서 값이 사라질 때 까지만 사용을 하는 가벼운 용도 정도 될 것 같네요.