[Go] Concurrency: sync.Pool

#Go

sync.Pool은 동기화 패키지에 있지만, 실질적인 사용처는 사실 동기화보단 GC 튜닝에 있다.
sync 패키지 기능들이 대부분 그렇지만, 멀티 고루틴에서 사용해도 thread-safe한 기능 단위다.

Go에서 항상 최적화의 쟁점이 되는 것이 GC다. 그리고 잦고 무거운 할당은 더 느린 GC의 원인이 된다.
sync.Pool은 반복적이고 무거운 초기화 작업이 반복될 때, 할당 최소화에 유용한 기능이다.

대략적인 사용법은 이렇다.
풀에서 초기값을 설정할 New 함수를 오버라이딩해서 정의, 공유가 가능한 위치에 변수로 깔아둔다.

Pool에서 객체를 가져올 때는 Get 함수로 가져온다. 이때 풀에 가용 객체가 없다면 정의한 New 함수로 객체를 초기화해서 반환해준다.
그리고 객체를 다 썼다면 다시 Pool에 반납해준다.

기본적인 사용 원리는 이정도다.
근데 이걸 쓰면 대체 뭐가 좋은걸까?

이건 사실 가벼운 단일 태스크의 작업에서는 큰 효용을 보이지는 못한다.
이게 장점을 드러내는 환경은 고루틴이 동시에 돌면서 같은 pool에서 비슷한 객체를 꺼내쓸때다.
코드로 간결하게 표현한다면 이런 느낌이다.

위와 같이 풀을 통해 꺼내쓰면 모든 고루틴마다 각각의 객체를 전부 생성할 필요가 없다.
풀에 사용할 수 있는 객체가 있다면 바로 꺼내쓸 수 있기 때문이다. 일종의 캐시의 개념이라 보면 된다.

그래서 각각의 초기화 작업이 꽤 무겁다면 꽤 괜찮은 성능 개선점이 될 수 있다.

Pool의 구조와 원리

pool을 잘 활용하려면 GC와의 관계성에 대해서도 어느정도 이해를 갖고 있어야 한다. 그냥 쓴다고 무조건 빨라지는게 아니기 때문이다.

Pool 구조체를 까보면 이런 구조를 갖고 있다.

Pool은 크게 2개의 영역으로 구성된다.
하나는 local 풀, 하나는 victim 풀이다.

일반적으로 오브젝트를 생성해서 초기화할때, 오브젝트들은 로컬 풀에 적재된다. 여기까지는 문제가 없다.

golang 런타임은 sync.Pool에 대해 아래 알고리즘을 통해 지속적으로 자원을 통제한다.

GC 타임이 돌면 go 런타임은 내부적으로 local 풀을 victim 풀로 이동시킨다. (이때 기존 victim 풀은 제거된다.)
GC 타임이 한번 더 돌면 local 풀을 또 victim 풀로 밀어내고, 기존 victim 풀을 제거하는 것을 반복한다.
출처 https://www.sobyte.net/post/2022-03/think-in-sync-pool/
어차피 sync.Pool은 오브젝트가 없으면 새로 생성을 해서 주기 때문에 이 때문에 발생하는 기능적인 결함은 별로 없다. 성능적인 사이드이펙트만을 발생시킬 뿐이다.

근데 왜 굳이 지우는걸까? 이유는 간단하다.
초기화만 무한정 하다보면 오브젝트가 끝없이 적재되고 메모리가 미친듯이 쌓일 수 있기 때문이다. 그래서 GC를 자체적으로 적용하는 것이다.

아무튼 여기서 중요한 점은, GC 타임이 두면 돌면 기존에 할당된 오브젝트들은 증발한다는 점이다.
그래서 실제로 성능이 향상되는 정도는 그 빈도에 얼마나 영향을 받는지에 따라 다르다.

이 기법은 CPU 캐시 구조에서 곧잘 사용하는 Victim cache 알고리즘에서 유래했다.