Modern C++ on kenji.blog

C++ 멀티스레드 프로그래밍 입문 및 비동기 처리 (std::async)

Sat, 12 Sep 2026 08:00:00 +0900

현대의 소프트웨어 개발에 있어 멀티코어 CPU의 성능을 최대한 끌어내기 위해서는 멀티스레드 프로그래밍이 필수적입니다. C++은 C++11부터 표준 라이브러리로 멀티스레드 및 비동기 처리 API(<thread>, <mutex>, <condition_variable>, <future>)를 도입하여, 플랫폼 종속적인 코드(POSIX 스레드나 Windows API 등)를 작성하지 않고도 이식성 있고 안전한 병행 처리를 구현할 수 있게 되었습니다. 게다가 C++14, C++17, C++20으로 버전업을 거듭하며 std::scoped_lock이나 std::jthread와 같은 더 안전하고 고도화된 기능들이 추가되었습니다.

본 기사에서는 C++ 멀티스레드 프로그래밍의 기초부터 데이터 경합을 방지하기 위한 동기화 메커니즘, 그리고 현대적인 비동기 처리(std::async)와 스레드 풀의 개념까지 상세한 코드 예제와 함께 철저하게 해설합니다.

1. 병행 처리의 기초와 암달의 법칙

멀티스레딩을 수행하는 가장 큰 목적은 “성능 향상"이지만, 프로그램 전체를 병렬화할 수 있는 것은 아닙니다. 여기서 중요해지는 것이 **암달의 법칙 (Amdahl’s Law)**입니다.

암달의 법칙은 프로그램의 일부를 병렬화·고속화했을 때, 시스템 전체의 성능이 어느 정도 향상될지 예측하는 모델입니다.

$$ S(N) = \frac{1}{(1 - P) + \frac{P}{N}} $$

$S(N)$ : 이론상 최대 스피드업 비율
$P$ : 프로그램 전체 중 병렬화 가능한 부분의 비율 (0 ≤ $P$ ≤ 1)
$N$ : 프로세서(스레드)의 수

이 수식이 보여주는 중요한 사실은, “아무리 프로세서 수 $N$을 늘려도, 병렬화할 수 없는 직렬 부분 $(1 - P)$이 병목 현상을 일으켜 스피드업에 한계가 있다"는 점입니다. 예를 들어 프로그램의 $90\%$가 병렬화 가능($P = 0.9$)하더라도, 나머지 $10\%$가 직렬 처리인 이상 무한대의 프로세서를 사용해도 최대 $10$배($S(\infty) = 1 / 0.1$) 밖에 고속화되지 않습니다.

따라서 C++에서 멀티스레드 프로그래밍을 수행할 때는 단순히 스레드를 늘리는 것만이 아니라, 직렬 처리 부분(락 경합이나 동기화 오버헤드 등)을 최대한 줄이는 설계가 요구됩니다.

2. 스레드의 기본: `std::thread`와 `std::jthread` (C++20)

기존의 `std::thread` (C++11)

C++11에 도입된 std::thread는 함수나 람다식을 새로운 스레드에서 실행하기 위한 가장 기본적인 클래스입니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


#include <iostream>
#include <thread>

void workerFunction(int id) {
 std::cout << "Worker " << id << " is running on thread "
 << std::this_thread::get_id() << std::endl;
}

int main() {
 std::cout << "Main thread id: " << std::this_thread::get_id() << std::endl;

 // 스레드 생성 및 실행 시작
 std::thread t1(workerFunction, 1);

 // 람다식을 이용한 스레드 생성
 std::thread t2([](int id) {
 std::cout << "Lambda Worker " << id << " is running." << std::endl;
 }, 2);

 // 스레드 종료 대기 (join)
 t1.join();
 t2.join();

 std::cout << "All threads completed." << std::endl;
 return 0;
}

std::thread의 주의점은, 파괴되기 전에 반드시 join() 또는 detach()를 호출해야 한다는 점입니다. 만약 둘 다 호출되지 않은 채 std::thread의 소멸자가 호출되면, std::terminate()가 호출되어 프로그램이 크래시(비정상 종료)됩니다. 예외 안전성을 확보하기 위해서는 RAII 패턴을 사용한 래퍼(wrapper) 클래스를 직접 만들어야 했습니다.

현대적인 `std::jthread` (C++20)

C++20에서는 이러한 단점을 해소한 std::jthread (joining thread)가 도입되었습니다. std::jthread는 소멸자에서 자동으로 join()을 호출하므로, 예외 발생 시에도 안전하게 스레드 종료를 대기할 수 있습니다. 또한 std::stop_token을 통한 스레드의 협조적인 취소 기능도 갖추고 있습니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


#include <iostream>
#include <thread>
#include <chrono>

int main() {
 // C++20: std::jthread
 // 첫 번째 인자로 std::stop_token을 받아 취소 요청을 감지 가능
 std::jthread jt([](std::stop_token stoken) {
 while (!stoken.stop_requested()) {
 std::cout << "Working..." << std::endl;
 std::this_thread::sleep_for(std::chrono::milliseconds(500));
 }
 std::cout << "Stop requested. Exiting thread." << std::endl;
 });

 std::this_thread::sleep_for(std::chrono::seconds(2));

 // 명시적으로 취소 요청
 jt.request_stop();

 // jthread의 소멸자에서 자동으로 join되므로 수동으로 join()을 호출할 필요가 없음
 return 0;
}

3. 데이터 경합 방지와 동기화: 뮤텍스와 락

여러 스레드가 동시에 동일한 메모리 영역(변수 등)에 접근하고, 최소 하나가 쓰기를 수행할 때 **데이터 경합 (Data Race)**이 발생합니다. C++ 표준에서 데이터 경합은 미정의 동작 (Undefined Behavior)을 유발합니다. 이를 방지하기 위해서는 std::mutex를 사용한 배타적 제어가 필요합니다.

`std::mutex`와 `std::lock_guard`

순수하게 std::mutex::lock()과 unlock()을 수동으로 호출하는 것은 예외 발생 시 unlock()이 호출되지 않아 데드락을 일으킬 위험이 있으므로 권장되지 않습니다. C++에서는 RAII 패턴을 사용한 std::lock_guard (C++11)나 std::scoped_lock (C++17)을 사용합니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


#include <iostream>
#include <vector>
#include <thread>
#include <mutex>

std::mutex g_mutex;
int g_counter = 0;

void incrementCounter(int iterations) {
 for (int i = 0; i < iterations; ++i) {
 // 스코프를 벗어날 때 자동으로 unlock 됨
 std::lock_guard<std::mutex> lock(g_mutex);
 ++g_counter;
 }
}

int main() {
 std::vector<std::thread> threads;
 for (int i = 0; i < 10; ++i) {
 threads.emplace_back(incrementCounter, 10000);
 }

 for (auto& t : threads) {
 t.join();
 }

 std::cout << "Final counter value: " << g_counter << std::endl;
 // 예상대로 100000이 됨
 return 0;
}

`std::unique_lock`

std::lock_guard는 스코프 기반의 단순한 락이지만, 보다 유연한 제어(지연 락, 시간 제한이 있는 락, 도중 언락 등)가 필요할 경우에는 std::unique_lock을 사용합니다. 다음에 설명할 std::condition_variable에서는 std::unique_lock이 필수가 됩니다.

4. 스레드 간 통신: `std::condition_variable`

어떤 스레드가 특정 조건을 만족할 때까지 대기하고, 다른 스레드가 그 조건을 만족했을 때 알림을 보내는 “생산자-소비자 패턴 (Producer-Consumer Pattern)” 등을 구현하려면 std::condition_variable을 사용합니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58


#include <iostream>
#include <thread>
#include <mutex>
#include <condition_variable>
#include <queue>

std::mutex g_mtx;
std::condition_variable g_cv;
std::queue<int> g_dataQueue;
bool g_isFinished = false;

void producer() {
 for (int i = 1; i <= 5; ++i) {
 std::this_thread::sleep_for(std::chrono::milliseconds(200));
 {
 std::lock_guard<std::mutex> lock(g_mtx);
 g_dataQueue.push(i);
 std::cout << "Produced: " << i << std::endl;
 }
 g_cv.notify_one(); // 소비자에게 알림
 }

 {
 std::lock_guard<std::mutex> lock(g_mtx);
 g_isFinished = true;
 }
 g_cv.notify_one(); // 종료를 알림
}

void consumer() {
 while (true) {
 std::unique_lock<std::mutex> lock(g_mtx);
 // 조건이 만족될 때까지 (큐가 비어있지 않거나 종료 플래그가 켜질 때까지) 대기
 // 거짓 기상(Spurious Wakeup)을 방지하기 위해 람다식으로 조건을 지정
 g_cv.wait(lock, []{ return !g_dataQueue.empty() || g_isFinished; });

 while (!g_dataQueue.empty()) {
 int val = g_dataQueue.front();
 g_dataQueue.pop();
 // 언락하고 무거운 처리(여기서는 출력만)를 수행
 lock.unlock();
 std::cout << "Consumed: " << val << std::endl;
 lock.lock(); // 다시 락을 획득
 }

 if (g_isFinished && g_dataQueue.empty()) {
 break;
 }
 }
}

int main() {
 std::thread t1(producer);
 std::thread t2(consumer);
 t1.join();
 t2.join();
 return 0;
}

이 예제에서는 std::condition_variable::wait가 조건을 만족할 때까지 스레드를 슬립 상태로 만들어, CPU 리소스의 낭비(바쁜 대기, Busy Loop)를 방지하고 있습니다.

5. 추상화 수준이 높은 비동기 처리: `std::future`, `std::promise`, `std::async`

지금까지 본 std::thread나 std::mutex는 강력하지만, OS의 저수준 스레드 메커니즘을 그대로 C++로 가져온 것이라 결과를 얻거나 예외를 전파할 때는 코드가 복잡해지기 쉽습니다. 반환값이 있는 병행 처리나 더 고수준의 비동기 처리를 하고 싶다면 <future> 헤더의 기능을 사용합니다.

`std::promise`와 `std::future`

std::promise는 결과를 “설정"하는 쪽, std::future는 결과를 “받는” 쪽을 나타냅니다. 이들은 스레드 간에 결과나 예외를 주고받는 안전한 채널로 기능합니다.

`std::async`를 이용한 태스크 기반 병행 처리

C++에서 비동기 태스크를 실행할 때 가장 권장되는 방법은 std::async를 사용하는 것입니다. std::async는 태스크를 비동기적으로 실행하고, 그 결과를 가져오기 위한 std::future를 반환합니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


#include <iostream>
#include <future>
#include <chrono>

int complexCalculation(int x) {
 std::cout << "Calculation started on thread: "
 << std::this_thread::get_id() << std::endl;
 std::this_thread::sleep_for(std::chrono::seconds(2));
 if (x < 0) {
 throw std::invalid_argument("x must be positive");
 }
 return x * 42;
}

int main() {
 std::cout << "Main thread id: " << std::this_thread::get_id() << std::endl;

 // std::launch::async를 지정하여 강제로 별도의 스레드에서 실행
 std::future<int> resultFuture = std::async(std::launch::async, complexCalculation, 10);

 std::cout << "Main thread is doing other work..." << std::endl;

 try {
 // get()을 호출하면 계산이 끝날 때까지 현재 스레드를 블록하고 대기함
 int result = resultFuture.get();
 std::cout << "Result: " << result << std::endl;
 } catch (const std::exception& e) {
 std::cerr << "Exception caught: " << e.what() << std::endl;
 }

 return 0;
}

std::async의 동작을 다음 시퀀스 다이어그램에 나타냅니다.

sequenceDiagram participant Main as "메인 스레드" participant Async as "std::async 워커" Main->>Async: "std::async(std::launch::async, ...)" activate Async Note over Main: "다른 작업 수행..." Main->>Async: "future.get() (준비될 때까지 블록)" Note right of Async: "계산 중..." Async-->>Main: "결과 반환 또는 예외 발생" deactivate Async

std::async의 첫 번째 인자인 시작 정책 (Launch Policy)에는 다음 2가지가 있습니다.

std::launch::async: 반드시 새로운 스레드를 생성(또는 스레드 풀에서 할당)하여 비동기적으로 실행한다.
std::launch::deferred: 지연 평가. future.get()이나 future.wait()가 호출된 시점에 호출자 스레드에서 동기적으로 실행한다.

기본값(지정하지 않음)의 경우 구현 의존적이며, 시스템의 부하 상태에 따라 둘 중 하나가 선택됩니다. 확실하게 비동기로 실행하고 싶다면 std::launch::async를 명시합니다.

6. 스레드 풀 (Thread Pool)의 개념

std::async를 매번 호출하거나 루프 안에서 std::thread를 매번 생성하고 파괴하면, 스레드의 컨텍스트 스위칭이나 OS 리소스 확보에 따른 오버헤드를 무시할 수 없게 됩니다. 특히 많은 양의 작은 태스크 (Fine-grained tasks)를 처리할 때는 스레드 풀 (Thread Pool)의 사용이 필수적입니다.

스레드 풀은 애플리케이션 시작 시 일정 수의 워커 (Worker) 스레드를 미리 생성해 두고, 태스크를 큐 (Queue)에 쌓은 뒤 빈 워커 스레드부터 순차적으로 태스크를 처리해 나가는 아키텍처입니다.

C++ 표준 라이브러리(C++23 기준)에는 표준 스레드 풀 클래스가 존재하지 않지만, std::thread, std::mutex, std::condition_variable, std::function, std::packaged_task를 조합하면 수십 줄의 코드로 효율적인 스레드 풀을 구현할 수 있습니다. 실제 운용에서는 Boost.Asio의 비동기 I/O나 서드파티 라이브러리를 이용하는 것이 일반적입니다.

7. 성능과 확장성(Scalability)에 대한 고찰

멀티스레드 프로그래밍에서 최고의 성능을 끌어내기 위해서는 코드의 병렬화뿐만 아니라 하드웨어 아키텍처에도 주의를 기울여야 합니다.

거짓 공유 (False Sharing): 여러 스레드가 서로 다른 변수를 업데이트하고 있음에도 불구하고 그 변수들이 CPU의 같은 캐시 라인(일반적으로 64바이트)에 배치되어 있으면, 캐시 일관성 유지를 위해 불필요한 메모리 동기화가 발생하여 성능이 극적으로 저하됩니다. 이를 방지하려면 alignas 지정자를 사용하여 변수를 캐시 라인 경계에 배치하는 고민이 필요합니다.
락 프리 (Lock-Free)와 std::atomic: 뮤텍스의 락/언락 오버헤드를 피하기 위해 <atomic>을 사용한 불가분 연산(Compare-And-Swap 등)이나 락 프리 자료 구조의 도입을 검토할 수 있습니다. 다만, 메모리 오더 (std::memory_order)에 대한 정확한 이해가 필요하고 구현 난이도가 매우 높기 때문에, 보통은 신중한 성능 측정 끝에 필요하다고 판단될 때만 도입합니다.

8. 요약

C++에서의 멀티스레드와 비동기 프로그래밍에 대해 기초부터 최신 C++20 기능까지 해설했습니다. 중요한 포인트는 다음과 같습니다.

기본은 std::async를 사용할 것: 단발성 비동기 태스크나 결과를 반환하는 병행 처리에는 수동으로 스레드를 관리하는 것보다 안전한 std::async와 std::future를 활용한다.
스레드 관리에는 std::jthread: 장기적으로 백그라운드에서 동작하는 스레드에는 C++20의 std::jthread를 사용하여 안전한 종료 처리를 보장한다.
동기화에는 RAII를 활용: 데이터 경합을 방지하기 위한 뮤텍스 락은 반드시 std::lock_guard나 std::unique_lock을 통해 수행한다.
오버헤드를 의식할 것: 스레드의 과도한 생성은 피하고, 필요에 따라 스레드 풀 아키텍처를 도입한다.

병행 처리의 버그(데드락, 데이터 경합)는 재현성이 낮아 디버깅이 가장 어려운 부류에 속합니다. 스레드 안전성을 항상 의식하고, 적절한 표준 라이브러리 도구를 선택하여 모던 C++을 통한 견고하고 빠른 시스템 개발을 실현합시다.

메모리 누수를 방지하는 스마트 포인터(std::unique_ptr / shared_ptr) 활용법

Sat, 12 Sep 2026 07:00:00 +0900

C++에서의 메모리 관리는 오랜 기간 동안 개발자에게 가장 큰 과제 중 하나였습니다. 수동으로 new와 delete에 의존하는 기존의 메모리 관리 스타일은 메모리 누수, 댕글링 포인터(dangling pointer), 이중 해제(double free)와 같은 심각한 버그를 일으키는 온상이었습니다. 하지만 Modern C++(C++11 이후)의 등장으로 상황은 극적으로 변했습니다. 그 핵심을 이루는 것이 바로 ‘스마트 포인터(Smart Pointers)‘입니다.

본 기사에서는 메모리 누수를 근절하고 안전하며 효율적인 리소스 관리를 실현하기 위한 강력한 도구인 std::unique_ptr, std::shared_ptr, 그리고 std::weak_ptr의 원리와 고급 활용법에 대해, 내부 구현(컨트롤 블록과 원자적 연산), 성능에 미치는 영향, 수학적 모델을 통한 참조 카운트의 공식화를 곁들여 아주 상세히 해설합니다.

1. 도입: C++ 메모리 관리의 암흑시대와 Modern C++의 여명

과거의 C++ 개발에서는 힙(heap) 상에 할당된 메모리를 개발자 자신이 책임지고 해제해야만 했습니다.

1
2
3
4
5
6
7
8


void legacy_function() {
 int* ptr = new int(10);
 // ... 어떤 처리 ...
 if (some_condition) {
 return; // 메모리 누수 발생! delete가 호출되지 않음
 }
 delete ptr;
}

위와 같은 코드에서는 예외가 발생하거나 조기 반환(early return)이 이루어질 경우 delete가 생략되어 메모리 누수가 발생합니다. 이를 방지하기 위한 패러다임이 ‘RAII(Resource Acquisition Is Initialization)‘입니다. RAII는 리소스 할당을 객체의 초기화(생성자)에, 리소스 해제를 객체의 파괴(소멸자)에 연결하는 기법입니다. 스마트 포인터는 이 RAII 이디엄을 메모리 관리에 응용한 표준 라이브러리의 클래스 템플릿입니다.

2. `std::unique_ptr`: 제로 오버헤드의 배타적 소유권

std::unique_ptr는 동적으로 할당된 객체에 대해 ‘배타적 소유권(Exclusive Ownership)‘을 가지는 스마트 포인터입니다. 특정 리소스를 소유할 수 있는 unique_ptr는 항상 단 하나뿐입니다.

2.1 제로 오버헤드의 원칙

std::unique_ptr의 가장 큰 매력은 그 성능입니다. 커스텀 딜리터(deleter)를 가지지 않는 기본 상태에서 std::unique_ptr의 크기는 원시 포인터(Raw Pointer)와 완전히 동일합니다. 불필요한 멤버 변수는 전혀 가지지 않으며 가상 함수도 사용되지 않습니다. 컴파일러의 최적화에 의해 std::unique_ptr를 통한 접근은 원시 포인터와 동등한 어셈블리 코드로 전개됩니다.

2.2 소유권 이동과 `std::move`

배타적 소유권을 가지기 때문에 std::unique_ptr는 복사할 수 없습니다(복사 생성자와 복사 대입 연산자가 delete되어 있습니다). 소유권을 다른 unique_ptr로 옮기려면 std::move를 사용하여 이동 의미론(Move Semantics)을 활용합니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


#include <iostream>
#include <memory>

class Resource {
public:
 Resource() { std::cout << "Resource acquired\n"; }
 ~Resource() { std::cout << "Resource destroyed\n"; }
 void do_something() { std::cout << "Doing something\n"; }
};

void process_resource(std::unique_ptr<Resource> ptr) {
 ptr->do_something();
 // 스코프를 벗어나면 ptr이 파괴되고, Resource도 해제됨
}

int main() {
 std::unique_ptr<Resource> my_ptr = std::make_unique<Resource>();

 // process_resource(my_ptr); // 에러: 복사 불가
 process_resource(std::move(my_ptr)); // 소유권 이동

 if (!my_ptr) {
 std::cout << "my_ptr is now empty.\n";
 }
 return 0;
}

다음 Mermaid 다이어그램은 std::move에 의한 소유권 이동의 개념을 보여줍니다.

2.3 커스텀 딜리터 구현

C 언어의 레거시 API(예: FILE*이나 소켓 등)를 래핑할 때, 메모리 해제를 위해 delete 이외의 함수(fclose 등)를 호출해야 할 필요가 있습니다. std::unique_ptr는 두 번째 템플릿 인자로 커스텀 딜리터를 지정할 수 있습니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


#include <cstdio>
#include <memory>

// 커스텀 딜리터용 함수 객체(Functor)
struct FileDeleter {
 void operator()(FILE* fp) const {
 if (fp) {
 std::cout << "Closing file.\n";
 std::fclose(fp);
 }
 }
};

using UniqueFile = std::unique_ptr<FILE, FileDeleter>;

int main() {
 UniqueFile file(std::fopen("test.txt", "w"));
 if (file) {
 std::fputs("Hello, Smart Pointers!", file.get());
 }
 // 스코프 종료 시 FileDeleter가 호출되어 fclose 됨
 return 0;
}

커스텀 딜리터로 함수 포인터나 람다 표현식을 사용하면 unique_ptr의 크기가 증가할 가능성이 있지만, 위와 같이 상태가 없는 함수 객체(Functor)를 사용하면 C++의 EBCO(Empty Base Class Optimization) 또는 C++20의 [[no_unique_address]] 덕분에 크기가 원시 포인터에서 증가하지 않습니다(제로 오버헤드가 유지됩니다).

3. `std::shared_ptr`: 공유 소유권과 컨트롤 블록

std::shared_ptr는 여러 포인터가 동일한 객체를 공유하여 소유하기 위한 스마트 포인터입니다. 마지막 shared_ptr가 파괴될 때 관리하고 있는 객체가 해제됩니다.

3.1 내부 아키텍처: 컨트롤 블록

std::shared_ptr는 관리 대상 객체에 대한 포인터와는 별도로 **컨트롤 블록(Control Block)**이라고 불리는 메타데이터를 힙 상에 할당하여 공유합니다. 컨트롤 블록에는 다음 정보가 포함됩니다:

Strong Count (강한 참조 카운트): 객체를 소유하고 있는 shared_ptr의 수입니다. 이 값이 0이 되면 객체가 파괴됩니다.
Weak Count (약한 참조 카운트): 객체를 감시하고 있는 weak_ptr의 수입니다. Strong Count와 Weak Count가 모두 0이 되면 컨트롤 블록 자체가 해제됩니다.
커스텀 딜리터와 할당자 (지정된 경우).

이 때문에 std::shared_ptr 객체 자체의 크기는 보통 원시 포인터의 2배(객체에 대한 포인터와 컨트롤 블록에 대한 포인터)가 됩니다.

3.2 성능과 원자적 연산

컨트롤 블록 내의 참조 카운트는 멀티스레드 환경에서도 안전하게 증감할 수 있도록 **원자적 연산(Atomic Operations)**으로 구현되어 있습니다.

x86/x64 아키텍처에서는 참조 카운트의 증감에 lock xadd와 같은 원자적 명령이 사용됩니다. 이는 일반적인 정수 덧셈에 비해 수십 사이클의 오버헤드를 수반합니다. 따라서 값 전달(pass-by-value)로 shared_ptr를 함수에 전달하면, 복사할 때마다 원자적인 증가(increment)와 감소(decrement)가 발생하여 성능이 저하됩니다.

모범 사례(Best Practice): shared_ptr를 함수에 전달할 때는 소유권을 공유할 필요가 없는 한 const std::shared_ptr<T>&(const 참조)로 전달하거나, 원시 포인터/참조를 전달해야 합니다.

3.3 `std::make_shared` vs `new`

shared_ptr를 생성할 때는 가능한 한 std::make_shared를 사용해야 합니다. 여기에는 두 가지 중요한 이유가 있습니다.

메모리 할당 최적화: new를 사용하면 객체 본체의 할당과 컨트롤 블록의 할당이라는 2번의 힙 할당(heap allocation)이 발생합니다. std::make_shared를 사용하면 두 가지를 포함하는 하나의 큰 메모리 블록을 1번의 힙 할당으로 확보할 수 있어 캐시 효율도 향상됩니다.
예외 안전성: C++17 이전 규격에서는 함수 인자의 평가 순서가 미정이었기 때문에, new로 확보한 포인터를 shared_ptr의 생성자에 전달하기 전에 다른 인자를 평가하는 과정에서 예외가 발생하면 메모리 누수 위험이 있었습니다. make_shared는 이 문제를 완전히 회피합니다.

1
2
3
4
5


// 피해야 할 작성법 (2번의 메모리 할당)
std::shared_ptr<MyClass> ptr1(new MyClass());

// 권장하는 작성법 (1번의 메모리 할당)
std::shared_ptr<MyClass> ptr2 = std::make_shared<MyClass>();

4. `std::weak_ptr`: 순환 참조 해결 및 감시

공유 소유권에는 ‘순환 참조(Circular References)‘라는 치명적인 약점이 있습니다. 객체 A와 객체 B가 서로 shared_ptr로 가리키고 있는 경우, 각각의 Strong Count는 최소 1로 유지되어 프로그램이 종료될 때까지 절대 0이 되지 않으므로 메모리 누수가 발생합니다.

graph TD subgraph "순환 참조 (메모리 누수)" A["객체 A"] -->|"shared_ptr (Strong=1)"| B["객체 B"] B -->|"shared_ptr (Strong=1)"| A end

4.1 `std::weak_ptr`를 통한 순환 고리 깨기

이 문제를 해결하는 것이 바로 std::weak_ptr입니다. weak_ptr는 shared_ptr로부터 생성되어 객체를 참조하지만, Strong Count를 증가시키지 않습니다. 대신 Weak Count를 증가시킵니다. 이를 통해 소유권을 가지지 않고 객체를 ‘감시’할 수 있습니다.

graph TD subgraph "순환 참조 깨기" C["객체 A"] -->|"shared_ptr (Strong=1)"| D["객체 B"] D -.->|"weak_ptr (Weak=1)"| C end

4.2 `lock()` 메서드를 통한 안전한 접근

weak_ptr는 객체에 직접 접근하는 연산자(->나 *)를 가지고 있지 않습니다. 대상 객체가 이미 파괴되었을 가능성이 있기 때문입니다. 안전하게 접근하려면 lock() 메서드를 호출하여 일시적으로 shared_ptr를 얻어야 합니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


#include <iostream>
#include <memory>

class Node {
public:
 std::string name;
 std::shared_ptr<Node> next;
 std::weak_ptr<Node> prev; // 순환 참조를 방지하기 위해 weak_ptr 사용

 Node(const std::string& n) : name(n) { std::cout << "Created " << name << "\n"; }
 ~Node() { std::cout << "Destroyed " << name << "\n"; }
};

int main() {
 auto nodeA = std::make_shared<Node>("A");
 auto nodeB = std::make_shared<Node>("B");

 nodeA->next = nodeB;
 nodeB->prev = nodeA;

 // weak_ptr에서 shared_ptr를 얻어 접근
 if (auto locked_prev = nodeB->prev.lock()) {
 std::cout << "Node B's prev is " << locked_prev->name << "\n";
 } else {
 std::cout << "Node B's prev is already destroyed.\n";
 }

 return 0; // nodeA와 nodeB는 적절히 파괴됨
}

5. 멀티스레드 환경에서의 공유 소유권 제약

shared_ptr의 스레드 안전성(Thread Safety)에 대해서는 오해하기 쉽습니다. “컨트롤 블록 내의 참조 카운트 갱신은 스레드 안전(Thread Safe)“하지만, “shared_ptr 객체 자체의 읽고 쓰기는 스레드 안전하지 않습니다”.

안전한 조작: 여러 스레드가 각자 자신의 shared_ptr 인스턴스(단, 동일한 컨트롤 블록을 공유함)를 읽고 쓰는 것.
데이터 레이스(위험): 여러 스레드가 완전히 동일한 shared_ptr 인스턴스에 대해 동시에 읽고 쓰는 것.

동일한 인스턴스를 여러 스레드에서 공유해야 할 경우에는 std::atomic<std::shared_ptr<T>>(C++20)를 사용하거나, 뮤텍스(std::mutex)로 보호해야 합니다.

6. 참조 카운트의 수학적 공식화

컨트롤 블록에서의 라이프사이클 상태 전이를 수학적으로 표현하면 다음과 같습니다. 시간 $t$에서의 Strong Count를 $S(t)$, Weak Count를 $W(t)$라고 합니다.

초기 상태(make_shared 직후):

$$ S(0) = 1, \quad W(0) = 0 $$

복사(shared_ptr의 복제)가 이루어지면:

$$ S(t_{next}) = S(t) + 1 $$

관리 객체(Managed Object)가 파괴되는 조건:

$$ \lim_{t \to t_d} S(t) = 0 $$

컨트롤 블록(Control Block) 자체가 메모리에서 해제되는 조건:

$$ S(t) = 0 \quad \land \quad W(t) = 0 $$

즉,

$$ S(t) + W(t) = 0 $$

이 수식이 보여주듯, weak_ptr가 계속 존재하는 한($W(t) > 0$), 관리 객체가 파괴되었더라도 컨트롤 블록을 위한 작은 메모리 공간은 계속 확보되어 있습니다. 이것이 make_shared의 유일한 단점(관리 객체의 메모리와 컨트롤 블록이 일체화되어 있기 때문에, 약한 참조가 남아 있으면 관리 객체용 거대한 메모리 공간도 시스템에 반환되지 않음)이 되는 경우가 있지만, 보통은 make_shared의 성능상 이점이 압도적으로 큽니다.

7. 결론

Modern C++에서의 메모리 관리는 더 이상 수동으로 new/delete를 관리하는 시대가 아닙니다.

기본적으로는 항상 **std::unique_ptr**를 사용하고, 제로 오버헤드의 혜택을 누리면서 명확한 소유권을 설계에 포함시킵니다.
정말로 여러 소유자 간에 라이프사이클을 공유해야 할 필요가 있는 경우에만 **std::shared_ptr**를 사용하며, 생성에는 std::make_shared를 사용합니다.
공유의 고리(순환 참조)가 발생할 수 있는 데이터 구조나 옵저버 패턴(Observer Pattern)의 구현에는 **std::weak_ptr**를 활용하여 메모리 누수를 미연에 방지합니다.

스마트 포인터를 깊이 이해하고 적재적소에 활용함으로써, C++의 성능을 전혀 희생하지 않고 안전하고 견고한 소프트웨어 아키텍처를 구축할 수 있게 됩니다.

Modern C++ on kenji.blog

C++ 멀티스레드 프로그래밍 입문 및 비동기 처리 (std::async)

1. 병행 처리의 기초와 암달의 법칙

2. 스레드의 기본: std::thread와 std::jthread (C++20)

기존의 std::thread (C++11)

현대적인 std::jthread (C++20)

3. 데이터 경합 방지와 동기화: 뮤텍스와 락

std::mutex와 std::lock_guard

std::unique_lock

4. 스레드 간 통신: std::condition_variable

5. 추상화 수준이 높은 비동기 처리: std::future, std::promise, std::async

std::promise와 std::future

std::async를 이용한 태스크 기반 병행 처리