[iOS] NSCache의 캐시 정책 뜯어보기

NSCache 

오늘은 가벼운 이미지 캐시에 자주 사용했지만, 무심코 사용해오기만 했던 NSCache가 내부적으로 어떤 정책을 두고 있는지 확인해보려고 합니다.

공식문서에는 NSCache가 다양한 자동 제거 정책(auto-eviction policy)을 사용해서 메모리를 관리한다고 소개하고 있는데요, 어떤 정책을 사용하는지 알려주고 있지는 않아요. 

그래서 Foundation에 들어가는 Objective-C 라이브러리인 libs-base에서 NSCache의 소스코드를 찾을 수 있었고, 이 소스코드를 뜯어보려고 합니다..! 제거 Objc는 리딩을 완벽하게 못해서 틀린 정보가 있을 수도 있어요..! 헷갈리는 부분은 잘 모르겠다고 남겨둘게요!

코드는 여기에서 확인할 수 있어요! 그럼 시작하겠습니다!

GitHub - gnustep/libs-base: The GNUstep Base Library is a library of general-purpose, non-graphical Objective C objects.

 

NSCache 컨테이너

NSCache 내부에는 _accesses와 NSMapTable이 눈에 띄는데요, access는 캐시할 객체들을 저장하는 자료구조로 보이고 NSMapTable은 확실하지는 않지만 캐싱된 객체를 key를 통해 빠르게 찾을 수 있게 하기 위해서 사용하는 것 같아요.

 

캐시 객체 컨테이너

먼저 NSCache 내부에서 데이터를 관리할 때 사용하는 것으로 보이는 객체의 인터페이스를 볼게요. object라는 범용 타입의 데이터를 저장할 수 있고, NSString 타입의 키 값이 있어요. 

그리고 accessCount 라는 변수가 있는데요, 교체 정책에서 해당 데이터가 몇 번 참조되었는지를 사용하는 것 같습니다.

cost는 NSCache의 api 중에 데이터를 저장하면서 cost를 저장할 수 있는데, 이 cost가 그대로 저장되는 것 같아요. 일반적으로 이 cost는 용량을 저장해줍니다. 

마지막으로 isEvictable은 해당 객체가 교체 대상인지 확인하는 용도로 쓰이겠네요.

 

데이터 추가

새로운 key-value를 추가하는 setObject 메서드는 두 종류가 있는데요, cost를 주지 않는 경우는 그냥 cost가 0이 되어서 cost를 인자로 받는 메서드를 부르고 있었어요. 그래서 cost가 포함된 위쪽 setObject만 확인해보면 될 것 같아요.

먼저 oldObject, newObject를 준비하고 만약 주어진 key에 대한 객체가 이미 존재한다면 해당 객체를 삭제해줍니다.

이제 _evitObjectsToMakeSpaceForObjectWithCost 라는 메서드를 호출하게 되는데요, 인자로는 NSCache에 값을 추가할 때 전달받은 cost가 그대로 전달됩니다. 실제로 캐시 정책이 수행되는 부분이 이곳일 텐데 남은 코드를 마저 보고 확인해볼게요!

그 이후에 새로운 CachedObject 객체를 만들어서 키와 값을 모두 RETAIN 합니다. NSCache의 key와 value에 값 타입이 허용되지 않는 이유가 여기에 있었네요..! 

그리고 discardableContent를 채택한다면 isEvictable을 마킹해둡니다. 

마지막으로 newObject를 캐시에 저장하고 전체 cost도 업데이트하면 새로운 키-값 쌍을 NSCache에 추가하는 것이 완료됩니다. 

 

데이터 읽기

데이터를 읽을 때는 key에 대한 객체가 있는지 확인합니다. 그리고 만약 있다면 반환하기 전에 accessCount를 증가시키고, totalAccesses를 증가시켜서 해당 객체에 대한 참조 횟수와 전체 참조 횟수를 업데이트해주고 있습니다.

그리고 객체를 리스트의 가장 마지막으로 옮겨서 가장 최근에 사용한 객체가 캐시 자료구조의 가장 마지막에 위치할 수 있도록 하고 있어요.

 

데이터 삭제

이제 실제로 캐시 정책이 어떻게 수행되는지, 아까 지나쳤던 _evitObjectsToMakeSpaceForObjectWithCost 메서드를 확인해보겠습니다!

먼저 주석이 있어서 해석해보고 지나갈게요. 여기에 구현된 정책은 간단한 LRU, LFU의 혼합형이라고 합니다. LRU는 가장 오래전에 참조한 객체를 선택하는 교체 정책이고, LFU는 가장 참조된 횟수가 적인 객체를 선택하는 교체 정책이에요. NSCache는 이 둘을 적절히 섞어 사용하는 것 같습니다.

NSCache 문서에서 애플이 정책이 바뀔 수 있다고 말하고 있다고 해요. 그런 내용이 있었나 싶어서 확인해봤더니,

나와있긴 하네요..ㅎㅎ 그래서 이후에는 추가적인 정책을 가진 class가 다른 메커니즘이나 캐시에 대해 생길 수도 있다고 합니다. 

이건 크게 중요한 내용은 아닌 것 같고, LRU + LFU가 어떻게 하이브리드 되고 있는지를 주의 깊게 봐야 할 것 같아요. 함수 바디가 좀 길어서 조금씩 끊어서 확인해볼게요.

먼저 spaceNeeded와 count 변수가 있습니다. 얼마나 많은 공간이 필요한지 계산해 저장하는 변수와 현재 캐시에 저장된 객체의 개수를 저장하는 변수로 보입니다. 

아래에 있는 조건문의 조건은 costLimit이 0보다 크고, totalCost에 주어진 cost를 더했을 때 costLimit보다 큰지 확인하는 조건인데요, 결국 cost 제한이 있는 상황에서 현재 새로 추가하려는 객체의 cost를 더했을 때 제한을 넘어선다면 얼마만큼의 용량을 확보해야 하는지 계산하는 조건문입니다.

그 아래에 있는 조건문에서는 기존에 있는 개체들을 삭제해야 하는 상황인 제한을 넘어선 경우를 확인하고 캐시 정책을 수행하고 있습니다.

기존 객체를 하나 지우고, 새로운 객체를 추가해야 한다면, 위 코드를 수행합니다. 먼저 현재 캐시에 있는 객체들이 가진 참조 횟수의 평균을 구하게 됩니다. 0.2를 곱하고 1을 더하는 건 왜 하는지 확실하지 않지만, 하이퍼 파라미터처럼 튜닝된 게 아닐까 싶어요.. 

evictsObjectsWithDiscardedContent는 문서에서 확인할 수 있었어요.

Bool값을 반환하고 현재 캐시가 이미 콘텐츠가 버려진 객체를 자동으로 삭제하는지 확인하고 있습니다. 만약 그렇다면 evictedKeys에 배열을 만들어서 저장하고 있어요.

다음 라인부터는 긴 while문이 진행되는데요, 반복의 조건은 확인할 다음 객체가 없을 때입니다.  obj 변수에 객체를 하나씩 가져오고 있어요. 객체를 꺼내오는 리스트는 가장 참조한 지 오래된 객체가 가장 앞에 있고, 가장 최근에 참조된 객체가 가장 뒤에 있겠죠? 그래서 자연스럽게 LRU가 수행되고 있는 것을 알 수 있습니다.

만약 이 객체의 참조 횟수가 평균 참조 횟수보다 작고, 제거가 가능하다면, 해당 객체의 cost를 0으로 만들고, isEvictable을 NO로 만들어서 삭제할 타깃으로 설정되지 않도록 처리하고 있습니다. LFU는 여기서 사용되네요.

그리고 discardContentIfPossible 메서드를 부르고 있습니다. 여기서 객체를 삭제하는 것 같으니 코드를 확인해보죠.

지금 보고 있는 파일 안에서는 확인할 수 없었고 문서에 내용이 있었는데요, 이 메서드가 호출되면 accessed counter가 0일 때 객체의 콘텐츠를 삭제하게 됩니다. accessed counter는 NSDiscountableContent 문서에 정리되어 있어요.

NSDiscardableContent 객체는 삭제될 수 있는 객체이고, 이 객체가 저장된 메모리에 읽기 연산이 일어나거나 사용 줄일 때 카운터가 1 이상이 되고, 사용 중이지 않거나 삭제가 가능할 때는 0이 된다고 합니다. 

만약 카운터가 0이 되면 메모리 관리가 필요할 때 객체를 삭제해줄 수 있는데, 이때 discardedContentIfPossible을 호출하면 카운터의 값이 0인 객체를 삭제해준다고 합니다.

그래서 지금 선택된 객체가 사용 중이 아니라면 해당 객체를 제거하고 새로운 객체를 캐시에 추가하기 위해서 discardedContentIfPossible을 호출해주는 것이죠.

삭제가 되었다면, isContentDiscarded를 통해 조건문 블록 안으로 진행하게 됩니다.

먼저 삭제할 객체의 cost를 저장해 두고 객체의 cost를 0으로 만든 뒤에, isEvictable을 NO로 만들어서 이 객체가 다시 선택되지 않도록 합니다.

그리고 객체의 콘텐츠를 삭제한 후에 그 키 값을 evictedKeys에 저장합니다. 

그 이후에 전체 cost에서 cost를 빼주고 방금 제거한 객체의 cost가 위에서 계산했던 costNeeded보다 크다면 반복을 중단하고, 작다면 아직 필요한 만큼 공간이 확보되지 않았기 때문에  같은 작업을 다음 객체에 대해 반복하게 됩니다. 

이렇게 하면 evicted에 콘텐츠가 삭제된 객체들의 키 값들이 모이겠죠?

그래서 마지막에는 evictedKeys에 저장된 키 값들을 모두 꺼내서 캐시에 저장되어 있는 해당 키에 대한 객체를 모두 제거합니다. 

 

마무리

이렇게 해서 NSCache의 내부를 확인해봤는데요, 정리하자면 NSCache는 LRU와 LFU를 혼합해서 정책을 사용하고 있었습니다. 가장 오래전에 참조된 객체를 우선적으로 확인해보지만, 만약 그 객체가 참조된 횟수가 캐시가 가진 평균 참조 횟수보다 높다면 꽤 많이 참조된 객체라는 것이겠죠? 그래서 다시 또 참조될 가능성이 있다고 판단해서 삭제 대상으로 정하지 않는 것이죠. 

한마디로 말해보면 NSCache의 정책은 "참조한 지 가장 오래된 객체 중에서 참조 횟수가 평균 참조 횟수보다 적은 객체"라고 할 수 있겠네요.

프로젝트를 하면서 NSCache를 사용하는 일이 꽤 있었는데, 이렇게 내부적으로 어떤 정책을 채택하고 있는지 알게 되어서 꽤 의미 있는 시간이었습니다! 혹시 잘못된 정보가 있거나 이상한 내용이 있다면 알려주세요! 저도 다시 고민해보겠습니다.

읽어주셔서 감사합니다!