folly::Singleton try_get·try_get_fast — TLS-cached 접근
#한 줄 요약
try_get은 매번 vault lookup + shared_ptr 복사가 발생한다. 핫패스에서 부담이다. try_get_fast는 thread-local cache로 그 비용을 nanosecond 단위로 떨어뜨린다. shared_ptr 대신 raw pointer를 돌려주므로 lifetime 책임이 호출자에게 일부 이동한다.
#동기 — try_get은 생각보다 비싸다
auto p = folly::Singleton<Service>::try_get();이 한 줄에서 일어나는 일.
- vault에서 type → holder lookup (F14Map find).
- holder의 state check (Quiescing 등).
- holder가 보관한 shared_ptr 복사 (atomic refcount inc).
- 결과 shared_ptr 반환 (또 atomic refcount inc).
- 호출자 끝나면 ~shared_ptr (atomic refcount dec).
전체 50~100ns. 한 번이면 무시할 만하지만 RPC 핸들러 안에서 매 request마다 호출되면 영향이 누적된다.
#try_get_fast
auto* p = folly::Singleton<Service>::try_get_fast(); // Service*, nullableif (p) { p->doWork();}내부는 thread_local로 캐시된 pointer다.
template <typename T>class Singleton { static T* try_get_fast() noexcept { thread_local T* cached = nullptr; if (FOLLY_LIKELY(cached != nullptr)) { return cached; } // slow path auto sp = try_get(); cached = sp.get(); return cached; }};첫 호출은 slow path(try_get). 이후는 TLS load 한 번. amortized 비용 ~3ns.
#TLS 캐시의 문제 — 언제 무효화하나
cached pointer가 dangling일 수 있다.
- vault가 destroyInstance 호출 후엔 그 pointer 무효.
- 새 thread가 cached==nullptr이면 다시 slow path.
Folly의 해법: TLS 캐시는 vault의 lifecycle version에 묶여 있다. version이 바뀌면 캐시 무효 처리. 매 access마다 version check가 한 번 더 있지만 매우 가볍다.
#try_get vs try_get_fast 비교
| try_get | try_get_fast | |
|---|---|---|
| 반환 | std::shared_ptr<T> | T* (nullable) |
| 평균 비용 | 50~100ns | 3~5ns |
| lifetime 책임 | shared_ptr가 자동 | 호출자가 vault destroy 인지 |
| thread-safe | yes | yes (TLS) |
| nullptr | shutdown 후 | shutdown 후, version 체크 |
| 권장 위치 | cold path, init | hot path, RPC handler |
#사용 예 — RPC handler
// 회피 — 핫패스마다 shared_ptr copyfolly::Future<Response> handle(Request req) { auto cache = folly::Singleton<Cache>::try_get(); if (!cache) return errorResponse(); return cache->lookup(req.key);}
// Good — TLS 캐시folly::Future<Response> handle(Request req) { auto* cache = folly::Singleton<Cache>::try_get_fast(); if (!cache) return errorResponse(); return cache->lookup(req.key);}QPS 100k라면 throughput 차이가 측정 가능하다.
#안전성 — 언제 try_get_fast가 위험한가
raw pointer를 반환하므로 호출자가 다음을 확인해야 한다.
#1. 호출자가 pointer를 보관하지 않는다
// 회피class Worker { Cache* cache_ = folly::Singleton<Cache>::try_get_fast(); // ↑ vault destroy 후엔 dangling};
// Good — 매번 try_get_fastclass Worker { void doWork() { auto* cache = folly::Singleton<Cache>::try_get_fast(); if (!cache) return; cache->lookup(...); }};매번 호출해도 TLS 캐시라 거의 무비용. 멤버에 보관하는 게 오히려 위험.
#2. shutdown path에서 try_get_fast
// 회피~Worker() { folly::Singleton<Logger>::try_get_fast()->log("bye"); // shutdown 중이면 nullptr (체크 안 함)}
// Good — try_get 또는 null check~Worker() { if (auto* logger = folly::Singleton<Logger>::try_get_fast()) { logger->log("bye"); }}null check 필수.
#std / abseil 비교
| 접근 방식 | 비용 | 안전성 |
|---|---|---|
Meyers static T s; return s; | ~1ns (이후), thread-safe init 비용 첫 호출 | dangling 없음 (전 lifetime) |
absl::NoDestructor<T>::get() | ~1ns | 누수 — destroy 안 함 |
folly::Singleton<T>::try_get() | 50~100ns | shared_ptr, race-free |
folly::Singleton<T>::try_get_fast() | 3~5ns | raw ptr, vault state 의존 |
Meyers와 absl::NoDestructor는 빠르지만 destruction order 보장이 없다. Folly의 try_get_fast는 그 보장을 유지하면서 hot-path 비용을 비슷한 수준으로 끌어내린다.
#코드 리뷰 포인트
#1. 어디서 try_get_fast를 쓸지 명확히
// 명시적 주석// HOT PATH — try_get_fast로 ns 단위 accessauto* svc = folly::Singleton<Service>::try_get_fast();
// COLD PATH — init 단계, shared_ptr 안전auto svc = folly::Singleton<Service>::try_get();PR 리뷰에서 어떤 path인지 확인.
#2. nullptr 체크 빠짐
// 회피folly::Singleton<X>::try_get_fast()->method(); // shutdown 직후 crashtry_get_fast도 nullable. shutdown 경계나 fork 직후 nullptr 가능.
#3. shared_ptr이 정말 필요한 경우
// async에 stashauto svc = folly::Singleton<Service>::try_get(); // shared_ptrfolly::makeFuture().thenValue([svc](auto) { svc->doWork(); // future 끝날 때까지 svc 유효});async 콜백처럼 lifetime이 호출 스택을 넘는 경우엔 shared_ptr이 필요. raw로 캡처하면 dangling 위험.
#4. benchmark로 차이 확인
BENCHMARK(try_get) { auto sp = folly::Singleton<Foo>::try_get(); doNotOptimizeAway(sp);}
BENCHMARK(try_get_fast) { auto* p = folly::Singleton<Foo>::try_get_fast(); doNotOptimizeAway(p);}대략 10-30x 차이. 핫패스라면 측정해 보고 결정.
#안티패턴
#1. 모든 try_get을 try_get_fast로 mass-replace
// 회피 — async 콜백 안에서 raw ptr capturefolly::makeFuture().thenValue([cache = folly::Singleton<Cache>::try_get_fast()](auto) { cache->lookup(...); // future 실행 시점에 cache가 살아있는지?});async 콜백은 capture 시점과 실행 시점이 다르다. shared_ptr이 옳다.
#2. try_get_fast 결과를 멤버에 보관
// 회피class Handler { Cache* cache_ = folly::Singleton<Cache>::try_get_fast(); // 한 번만 호출};vault가 destroyInstance를 호출하면 cache_가 dangling. 멤버 대신 매 method에서 호출.
#3. const 호출에서 mutable 메서드
// 회피void readOnly() const { auto* c = folly::Singleton<Cache>::try_get_fast(); c->mutate(); // 의도와 다른 mutation}singleton 자체는 mutable이지만, const 함수가 mutable 메서드를 호출하면 설계 의도가 흐려진다.
#정리
- try_get: shared_ptr, 50~100ns, 가장 안전.
- try_get_fast: raw ptr (TLS-cached), 3~5ns, hot path용.
- TLS 캐시는 vault lifecycle version에 묶여 자동 무효화.
- async/콜백에 캡처는 shared_ptr (try_get).
- raw ptr을 멤버로 보관 금지, 매 호출마다 try_get_fast가 안전.
- nullptr 체크 빠뜨리면 shutdown 경계에서 crash.
#다음 편
Part 13-01 ExceptionWrapper — Part 13 시작. 비동기 컨텍스트로 exception을 안전하게 옮기는 패턴.
#관련 항목
- Part 12-01 Singleton vs Meyers — 왜 vault가 필요한가
- Part 12-02 SingletonVault — vault 라이프사이클
- Part 2-03 SemiFuture vs Future — async 캡처 패턴
Folly Code Review · 56 of 89
- 1 Folly Code Review — Meta의 production-grade C++ 라이브러리 코드 분석
- 2 Folly 개요 — Meta가 production에서 검증한 utility 모음 분석
- 3 Folly vs Abseil 철학 비교 — performance-first vs std-compatible
- 4 Folly 빌드와 fbcode 환경 — monorepo의 그림자
- 5 Folly API stability 정책 — 어떤 보장도 없다는 솔직함
- 6 Folly production validation 문화 — peta-scale에서 단련된 코드
- 7 folly::Future 분석 — std::future의 한계를 넘는 composable async
- 8 folly::Promise·makeFuture — Future를 만드는 두 길
- 9 folly::SemiFuture vs Future — executor binding의 명시화
- 10 folly::Future thenValue·thenError·thenTry — continuation 체인 분석
- 11 folly::collect·collectAll·collectAny — fan-in 패턴 분석
- 12 folly::Future retry·window·via — 제어 흐름 조합자
- 13 folly::fibers 분석 — M:N stackful coroutine
- 14 folly::InlineExecutor — 호출자 thread에서 즉시 실행
- 15 folly::CPUThreadPoolExecutor — CPU-bound 작업의 표준 thread pool
- 16 folly::IOThreadPoolExecutor — libevent 기반 I/O pool
- 17 folly::ManualExecutor — 결정적 테스트를 위한 수동 진행
- 18 folly::EventBase 분석 — libevent 이벤트 루프의 핵심
- 19 folly::IOBuf 분석 — zero-copy buffer chain의 기본 단위
- 20 folly::IOBufQueue — chain의 push/pull 추상화
- 21 folly::io::Cursor·RWCursor — chain 위의 stream
- 22 folly Zero-copy 패턴 — IOBuf로 ScatterGather I/O 표현
- 23 folly::IOBuf shared semantics — clone·unshare·takeOwnership
- 24 folly::FBString 분석 — SSO + COW 구현
- 25 folly의 fmt::format 통합 — 모던 포맷팅 채택
- 26 folly::StringPiece — string_view 호환 분석
- 27 folly Join·Split utilities — 문자열 분해와 결합
- 28 folly::to·tryTo — text↔num 변환 분석
- 29 folly Conv Customization — 사용자 타입 지원
- 30 folly Conv 성능 비교 — sprintf·stringstream 대비
- 31 folly::F14ValueMap vs std::unordered_map
- 32 folly::F14NodeMap — stable pointer가 필요할 때
- 33 folly::F14VectorMap — cache-friendly iteration
- 34 folly::F14FastMap — auto-select 동작
- 35 folly F14 internals — SIMD probing 메커니즘
- 36 folly::small_vector — inline storage 분석
- 37 folly::FixedString — compile-time string
- 38 folly::AtomicHashMap — lock-free read 분석
- 39 folly::ConcurrentHashMap — sharded 동시 해시 맵
- 40 folly::EvictingCacheMap — LRU 구현 분석
- 41 folly::Synchronized — lock wrapper 패턴
- 42 folly::SharedMutex 분석
- 43 folly::Baton — one-shot wait 동기화
- 44 folly::RWSpinLock 분석
- 45 folly::PicoSpinLock — 1-byte spinlock
- 46 folly::ProducerConsumerQueue — SPSC 큐 분석
- 47 folly::MPMCQueue — multi-producer multi-consumer
- 48 folly::UnboundedQueue — 동적 크기 lock-free
- 49 folly::fibers::Channel — Go-like channel
- 50 folly::dynamic — JSON-like dynamic type 분석
- 51 folly JSON conversion — toJson·parseJson
- 52 folly dynamic ↔ struct — manual marshaling
- 53 folly dynamic Visitor pattern — type별 분기
- 54 folly::Singleton vs Meyers/static — 왜 Folly의 Singleton인가
- 55 folly::SingletonVault 분석 — 등록·소멸·의존성
- 56 folly::Singleton try_get·try_get_fast — TLS-cached 접근
- 57 folly::ExceptionWrapper — type-erased exception holder
- 58 folly::ScopeGuard·SCOPE_EXIT — RAII cleanup
- 59 folly::Optional vs std::optional
- 60 folly::Function vs std::function
- 61 folly::Lazy — 지연 초기화 wrapper
- 62 folly Meta 스타일 code review 패턴
- 63 folly anti-patterns — 잘못 쓰면 std보다 느림
- 64 folly vs std 선택 기준 분석
- 65 folly::coro 개요 — production C++20 코루틴 어댑터
- 66 folly::coro::Task — lazy single-shot 코루틴
- 67 folly::coro::AsyncGenerator — 비동기 스트림
- 68 folly coro blockingWait·collectAll — 동기 경계와 fan-in
- 69 folly::coro::Baton·Mutex — 코루틴-aware 동기화
- 70 folly::Expected — 결과 또는 오류
- 71 folly::Try — Future 결과 wrapper
- 72 folly::Try vs Expected 선택 기준
- 73 folly::Range — 일반 iterator pair
- 74 folly::Uri — URL 파서
- 75 folly Fingerprint64·128 — 분산 hash
- 76 folly SpookyHashV2 — fast non-crypto hash
- 77 folly::Init — main() 부트스트랩
- 78 folly::Indestructible — global lifetime 패턴
- 79 folly::MicroLock — 1-byte 락
- 80 folly::MicroSpinLock — 가장 좁은 spin lock
- 81 folly::format — legacy formatter 분석
- 82 folly::demangle — typeid 디망글링
- 83 folly::DynamicConverter — dynamic ↔ struct
- 84 folly::RecordIO — append-only 로그 파일 포맷
- 85 folly::io::Compression — zstd·lz4·snappy wrapper
- 86 folly::AsyncIO — io_uring·Linux AIO
- 87 folly::CancellationToken — 코루틴·Future 취소 전파
- 88 folly::observer — hot config의 atomic refresh
- 89 fbcode 패턴 모음 — folly 사용의 실전
관련 글
folly::Indestructible — global lifetime 패턴
Indestructible<T>의 동기 — Meyers singleton의 static deinitialization 함정과 그 회피.
같은 시리즈에서 이어 읽기
folly anti-patterns — 잘못 쓰면 std보다 느림
Part 14-02: Folly 오용 패턴 정리 — SemiFuture without via, fbstring small case, F14 잘못된 default, 등.
같은 시리즈에서 이어 읽기
folly Meta 스타일 code review 패턴
Part 14-01: Meta(Facebook) 사내 code review 문화 — performance-first lens.
같은 시리즈에서 이어 읽기