본문으로 건너뛰기
Folly Code Review · 55/89

folly::Singleton try_get·try_get_fast — TLS-cached 접근

· Hawk · 5분 읽기

#한 줄 요약

try_get은 매번 vault lookup + shared_ptr 복사가 발생한다. 핫패스에서 부담이다. try_get_fastthread-local cache로 그 비용을 nanosecond 단위로 떨어뜨린다. shared_ptr 대신 raw pointer를 돌려주므로 lifetime 책임이 호출자에게 일부 이동한다.

#동기 — try_get은 생각보다 비싸다

auto p = folly::Singleton<Service>::try_get();

이 한 줄에서 일어나는 일.

  1. vault에서 type → holder lookup (F14Map find).
  2. holder의 state check (Quiescing 등).
  3. holder가 보관한 shared_ptr 복사 (atomic refcount inc).
  4. 결과 shared_ptr 반환 (또 atomic refcount inc).
  5. 호출자 끝나면 ~shared_ptr (atomic refcount dec).

전체 50~100ns. 한 번이면 무시할 만하지만 RPC 핸들러 안에서 매 request마다 호출되면 영향이 누적된다.

#try_get_fast

auto* p = folly::Singleton<Service>::try_get_fast(); // Service*, nullable
if (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_gettry_get_fast
반환std::shared_ptr<T>T* (nullable)
평균 비용50~100ns3~5ns
lifetime 책임shared_ptr가 자동호출자가 vault destroy 인지
thread-safeyesyes (TLS)
nullptrshutdown 후shutdown 후, version 체크
권장 위치cold path, inithot path, RPC handler

#사용 예 — RPC handler

// 회피 — 핫패스마다 shared_ptr copy
folly::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_fast
class 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~100nsshared_ptr, race-free
folly::Singleton<T>::try_get_fast()3~5nsraw ptr, vault state 의존

Meyers와 absl::NoDestructor는 빠르지만 destruction order 보장이 없다. Folly의 try_get_fast는 그 보장을 유지하면서 hot-path 비용을 비슷한 수준으로 끌어내린다.

#코드 리뷰 포인트

#1. 어디서 try_get_fast를 쓸지 명확히

// 명시적 주석
// HOT PATH — try_get_fast로 ns 단위 access
auto* 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 직후 crash

try_get_fast도 nullable. shutdown 경계나 fork 직후 nullptr 가능.

#3. shared_ptr이 정말 필요한 경우

// async에 stash
auto svc = folly::Singleton<Service>::try_get(); // shared_ptr
folly::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 capture
folly::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을 안전하게 옮기는 패턴.

#관련 항목

Folly Code Review · 56 of 89

  1. 1 Folly Code Review — Meta의 production-grade C++ 라이브러리 코드 분석
  2. 2 Folly 개요 — Meta가 production에서 검증한 utility 모음 분석
  3. 3 Folly vs Abseil 철학 비교 — performance-first vs std-compatible
  4. 4 Folly 빌드와 fbcode 환경 — monorepo의 그림자
  5. 5 Folly API stability 정책 — 어떤 보장도 없다는 솔직함
  6. 6 Folly production validation 문화 — peta-scale에서 단련된 코드
  7. 7 folly::Future 분석 — std::future의 한계를 넘는 composable async
  8. 8 folly::Promise·makeFuture — Future를 만드는 두 길
  9. 9 folly::SemiFuture vs Future — executor binding의 명시화
  10. 10 folly::Future thenValue·thenError·thenTry — continuation 체인 분석
  11. 11 folly::collect·collectAll·collectAny — fan-in 패턴 분석
  12. 12 folly::Future retry·window·via — 제어 흐름 조합자
  13. 13 folly::fibers 분석 — M:N stackful coroutine
  14. 14 folly::InlineExecutor — 호출자 thread에서 즉시 실행
  15. 15 folly::CPUThreadPoolExecutor — CPU-bound 작업의 표준 thread pool
  16. 16 folly::IOThreadPoolExecutor — libevent 기반 I/O pool
  17. 17 folly::ManualExecutor — 결정적 테스트를 위한 수동 진행
  18. 18 folly::EventBase 분석 — libevent 이벤트 루프의 핵심
  19. 19 folly::IOBuf 분석 — zero-copy buffer chain의 기본 단위
  20. 20 folly::IOBufQueue — chain의 push/pull 추상화
  21. 21 folly::io::Cursor·RWCursor — chain 위의 stream
  22. 22 folly Zero-copy 패턴 — IOBuf로 ScatterGather I/O 표현
  23. 23 folly::IOBuf shared semantics — clone·unshare·takeOwnership
  24. 24 folly::FBString 분석 — SSO + COW 구현
  25. 25 folly의 fmt::format 통합 — 모던 포맷팅 채택
  26. 26 folly::StringPiece — string_view 호환 분석
  27. 27 folly Join·Split utilities — 문자열 분해와 결합
  28. 28 folly::to·tryTo — text↔num 변환 분석
  29. 29 folly Conv Customization — 사용자 타입 지원
  30. 30 folly Conv 성능 비교 — sprintf·stringstream 대비
  31. 31 folly::F14ValueMap vs std::unordered_map
  32. 32 folly::F14NodeMap — stable pointer가 필요할 때
  33. 33 folly::F14VectorMap — cache-friendly iteration
  34. 34 folly::F14FastMap — auto-select 동작
  35. 35 folly F14 internals — SIMD probing 메커니즘
  36. 36 folly::small_vector — inline storage 분석
  37. 37 folly::FixedString — compile-time string
  38. 38 folly::AtomicHashMap — lock-free read 분석
  39. 39 folly::ConcurrentHashMap — sharded 동시 해시 맵
  40. 40 folly::EvictingCacheMap — LRU 구현 분석
  41. 41 folly::Synchronized — lock wrapper 패턴
  42. 42 folly::SharedMutex 분석
  43. 43 folly::Baton — one-shot wait 동기화
  44. 44 folly::RWSpinLock 분석
  45. 45 folly::PicoSpinLock — 1-byte spinlock
  46. 46 folly::ProducerConsumerQueue — SPSC 큐 분석
  47. 47 folly::MPMCQueue — multi-producer multi-consumer
  48. 48 folly::UnboundedQueue — 동적 크기 lock-free
  49. 49 folly::fibers::Channel — Go-like channel
  50. 50 folly::dynamic — JSON-like dynamic type 분석
  51. 51 folly JSON conversion — toJson·parseJson
  52. 52 folly dynamic ↔ struct — manual marshaling
  53. 53 folly dynamic Visitor pattern — type별 분기
  54. 54 folly::Singleton vs Meyers/static — 왜 Folly의 Singleton인가
  55. 55 folly::SingletonVault 분석 — 등록·소멸·의존성
  56. 56 folly::Singleton try_get·try_get_fast — TLS-cached 접근
  57. 57 folly::ExceptionWrapper — type-erased exception holder
  58. 58 folly::ScopeGuard·SCOPE_EXIT — RAII cleanup
  59. 59 folly::Optional vs std::optional
  60. 60 folly::Function vs std::function
  61. 61 folly::Lazy — 지연 초기화 wrapper
  62. 62 folly Meta 스타일 code review 패턴
  63. 63 folly anti-patterns — 잘못 쓰면 std보다 느림
  64. 64 folly vs std 선택 기준 분석
  65. 65 folly::coro 개요 — production C++20 코루틴 어댑터
  66. 66 folly::coro::Task — lazy single-shot 코루틴
  67. 67 folly::coro::AsyncGenerator — 비동기 스트림
  68. 68 folly coro blockingWait·collectAll — 동기 경계와 fan-in
  69. 69 folly::coro::Baton·Mutex — 코루틴-aware 동기화
  70. 70 folly::Expected — 결과 또는 오류
  71. 71 folly::Try — Future 결과 wrapper
  72. 72 folly::Try vs Expected 선택 기준
  73. 73 folly::Range — 일반 iterator pair
  74. 74 folly::Uri — URL 파서
  75. 75 folly Fingerprint64·128 — 분산 hash
  76. 76 folly SpookyHashV2 — fast non-crypto hash
  77. 77 folly::Init — main() 부트스트랩
  78. 78 folly::Indestructible — global lifetime 패턴
  79. 79 folly::MicroLock — 1-byte 락
  80. 80 folly::MicroSpinLock — 가장 좁은 spin lock
  81. 81 folly::format — legacy formatter 분석
  82. 82 folly::demangle — typeid 디망글링
  83. 83 folly::DynamicConverter — dynamic ↔ struct
  84. 84 folly::RecordIO — append-only 로그 파일 포맷
  85. 85 folly::io::Compression — zstd·lz4·snappy wrapper
  86. 86 folly::AsyncIO — io_uring·Linux AIO
  87. 87 folly::CancellationToken — 코루틴·Future 취소 전파
  88. 88 folly::observer — hot config의 atomic refresh
  89. 89 fbcode 패턴 모음 — folly 사용의 실전