libevent 客户端与 bufferevent 进阶

时间：2026/05/04

关键词：bufferevent_socket_new、bufferevent_socket_connect、异步 DNS、超时、水位线、重连、背压
核心目标：掌握如何用 libevent 主动连接服务器，并把读写、超时、DNS、重连和缓冲控制放进统一事件循环。

1. 客户端和服务端的 libevent 思路差异

服务端的主线是：

1

evconnlistener -> accept -> bufferevent

客户端的主线是：

1
2
3
4
5

bufferevent_socket_new(fd = -1)
    -> bufferevent_socket_connect
    -> BEV_EVENT_CONNECTED
    -> write request
    -> read response

也就是说：

• 服务端先监听，再为每个连接创建 bufferevent
• 客户端通常直接创建一个未连接的 bufferevent
• 连接成功、失败、超时都从 event callback 里得知

2. 创建客户端 bufferevent

1
2
3
4
5
6
7

#include <event2/bufferevent.h>

struct bufferevent *bev = bufferevent_socket_new(
    base,
    -1,
    BEV_OPT_CLOSE_ON_FREE | BEV_OPT_DEFER_CALLBACKS
);

这里 fd = -1 表示：

• 让 libevent 自己创建 socket
• 后续由 bufferevent_socket_connect() 发起连接

常用选项：

3. 回调要先设置，再发起连接

推荐顺序：

1
2
3
4

bufferevent_setcb(bev, read_cb, write_cb, event_cb, ctx);
bufferevent_enable(bev, EV_READ | EV_WRITE);
bufferevent_set_timeouts(bev, &read_timeout, &write_timeout);
bufferevent_socket_connect(bev, (struct sockaddr *)&addr, sizeof(addr));

原因是：

• 连接可能很快成功或失败
• 先设置回调可以避免事件到来时没有处理逻辑
• 超时也应该在连接发起前准备好

4. 最小客户端示例：连接 IPv4 地址

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
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112

#include <event2/buffer.h>
#include <event2/bufferevent.h>
#include <event2/event.h>
#include <event2/util.h>

#include <arpa/inet.h>
#include <netinet/in.h>
#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
#include <string.h>

static void read_cb(struct bufferevent *bev, void *ctx) {
    (void)ctx;

    char buf[4096];
    size_t n = 0;

    while ((n = bufferevent_read(bev, buf, sizeof(buf))) > 0) {
        fwrite(buf, 1, n, stdout);
    }
}

static void write_cb(struct bufferevent *bev, void *ctx) {
    (void)bev;
    (void)ctx;
}

static void event_cb(struct bufferevent *bev, short events, void *ctx) {
    struct event_base *base = ctx;

    if (events & BEV_EVENT_CONNECTED) {
        const char *msg = "hello from libevent client\n";
        bufferevent_write(bev, msg, strlen(msg));
        return;
    }

    if (events & BEV_EVENT_ERROR) {
        int err = EVUTIL_SOCKET_ERROR();
        fprintf(stderr, "connect/io error: %s\n",
                evutil_socket_error_to_string(err));
    }

    if (events & BEV_EVENT_TIMEOUT) {
        fprintf(stderr, "timeout\n");
    }

    if (events & BEV_EVENT_EOF) {
        fprintf(stderr, "server closed\n");
    }

    if (events & (BEV_EVENT_EOF | BEV_EVENT_ERROR | BEV_EVENT_TIMEOUT)) {
        bufferevent_free(bev);
        event_base_loopexit(base, NULL);
    }
}

int main(int argc, char **argv) {
    const char *ip = "127.0.0.1";
    int port = 9876;

    if (argc > 1) {
        ip = argv[1];
    }
    if (argc > 2) {
        port = atoi(argv[2]);
    }

    struct event_base *base = event_base_new();
    if (!base) {
        fprintf(stderr, "could not create event_base\n");
        return 1;
    }

    struct bufferevent *bev = bufferevent_socket_new(
        base, -1, BEV_OPT_CLOSE_ON_FREE | BEV_OPT_DEFER_CALLBACKS);
    if (!bev) {
        event_base_free(base);
        return 1;
    }

    bufferevent_setcb(bev, read_cb, write_cb, event_cb, base);
    bufferevent_enable(bev, EV_READ | EV_WRITE);

    struct timeval timeout = {10, 0};
    bufferevent_set_timeouts(bev, &timeout, &timeout);

    struct sockaddr_in sin;
    memset(&sin, 0, sizeof(sin));
    sin.sin_family = AF_INET;
    sin.sin_port = htons((uint16_t)port);

    if (evutil_inet_pton(AF_INET, ip, &sin.sin_addr) <= 0) {
        fprintf(stderr, "invalid ip: %s\n", ip);
        bufferevent_free(bev);
        event_base_free(base);
        return 1;
    }

    if (bufferevent_socket_connect(
            bev, (struct sockaddr *)&sin, sizeof(sin)) < 0) {
        fprintf(stderr, "connect start failed\n");
        bufferevent_free(bev);
        event_base_free(base);
        return 1;
    }

    event_base_dispatch(base);

    event_base_free(base);
    return 0;
}

编译：

1

cc client.c -o client -levent

测试时可以先启动上一篇的 echo server：

1
2

./echo_server 9876
./client 127.0.0.1 9876

5. BEV_EVENT_CONNECTED 不等于服务端已回包

主动连接成功时，event callback 会收到：

1

BEV_EVENT_CONNECTED

这只表示 TCP 连接建立完成，之后你可以：

• 发送请求
• 启动应用层握手
• 切换连接状态

它不表示：

• 服务端已经处理业务
• 服务端一定会持续在线
• 应用协议已经完成

所以客户端通常要维护自己的状态：

1

CONNECTING -> CONNECTED -> REQUEST_SENT -> RESPONSE_READING -> DONE

6. 使用主机名连接：异步 DNS

如果直接调用阻塞式 getaddrinfo()，事件循环可能被卡住。
libevent 提供了异步 DNS：

1
2
3
4
5
6
7
8
9
10
11

#include <event2/dns.h>

struct evdns_base *dns = evdns_base_new(base, 1);

int rc = bufferevent_socket_connect_hostname(
    bev,
    dns,
    AF_UNSPEC,
    "example.com",
    80
);

参数说明：

DNS 错误可以这样拿：

1
2
3
4

int err = bufferevent_socket_get_dns_error(bev);
if (err) {
    fprintf(stderr, "dns error: %s\n", evutil_gai_strerror(err));
}

清理时：

1

evdns_base_free(dns, 0);

7. 输入缓冲解析：不要假设一次读完

客户端同样要处理半包和粘包。
如果协议是按行返回，可以用：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

static void line_read_cb(struct bufferevent *bev, void *ctx) {
    (void)ctx;

    struct evbuffer *input = bufferevent_get_input(bev);

    for (;;) {
        size_t n = 0;
        char *line = evbuffer_readln(input, &n, EVBUFFER_EOL_CRLF);
        if (!line) {
            break;
        }

        printf("line: %.*s\n", (int)n, line);
        free(line);
    }
}

如果协议是二进制长度前缀，就要像服务端一样：

• 先检查包头够不够
• 再检查包体够不够
• 一次循环内尽量把完整消息都解析掉

8. 输出缓冲与写回调

bufferevent_write() 的语义是：

把数据追加到输出缓冲，之后由 libevent 在 socket 可写时异步发送。

1

bufferevent_write(bev, data, len);

它不是阻塞式 send()。
调用成功只表示数据进入输出缓冲，不表示对端已经收到。

write callback 的触发条件是：

• 输出缓冲长度降到写低水位

这适合做发送完成后的动作：

1
2
3
4
5
6

static void write_done_cb(struct bufferevent *bev, void *ctx) {
    struct evbuffer *output = bufferevent_get_output(bev);
    if (evbuffer_get_length(output) == 0) {
        // 请求已经全部刷入内核发送路径
    }
}

注意：

• 这仍然不等于对端应用层已处理
• 如果需要确认，协议层要有 ACK 或 response

9. 水位线：控制读写压力

读水位：

1

bufferevent_setwatermark(bev, EV_READ, 1, 64 * 1024);

含义：

• 输入缓冲至少 1 字节时触发读回调
• 输入缓冲超过 64 KiB 时暂停继续读

写水位：

1

bufferevent_setwatermark(bev, EV_WRITE, 0, 0);

多数简单客户端不用特别设置写水位。
但如果客户端会持续大批量发送，就应该给业务层加队列上限，避免输出缓冲无限增长。

10. 超时：连接、读、写都要考虑

1
2
3

struct timeval rto = {10, 0};
struct timeval wto = {10, 0};
bufferevent_set_timeouts(bev, &rto, &wto);

常见理解：

• 非阻塞 connect 阶段通常靠写超时兜底
• 等响应阶段通常靠读超时兜底
• 大量数据发送阶段可能触发写超时

event callback 里处理：

1
2
3

if (events & BEV_EVENT_TIMEOUT) {
    bufferevent_free(bev);
}

不要让客户端无限等服务端响应。
超时本身就是协议状态机的一部分。

11. 重连策略

客户端常常需要重连，但不能无脑死循环重连。

推荐策略：

• 连接失败后延迟重连
• 指数退避，例如 1s、2s、4s、8s
• 设置最大退避时间
• 手动关闭和网络错误要区分
• 重连前清理旧 bufferevent

用 libevent 定时器表达重连：

1
2
3

struct event *timer = evtimer_new(base, reconnect_cb, ctx);
struct timeval delay = {2, 0};
evtimer_add(timer, &delay);

重连时再重新创建：

1

new bufferevent -> set callbacks -> enable -> connect

不要试图在已经进入错误状态的 bufferevent 上反复复用所有状态。

12. bufferevent_pair_new：进程内自通信

libevent 还可以创建一对互联的 bufferevent：

1
2

struct bufferevent *pair[2];
bufferevent_pair_new(base, BEV_OPT_CLOSE_ON_FREE, pair);

pair[0] 写入的数据会从 pair[1] 读到，反之亦然。
它常用于：

• 测试协议解析器
• 模拟连接
• 进程内组件通信

这不是网络 socket，但接口和 bufferevent 一致。

13. 客户端常见坑

13.1 connect() 前没设置回调和超时

事件可能很快到来，尤其是本机连接。

13.2 把 bufferevent_write() 当成发送完成

它只是写入输出缓冲。
应用层确认要靠协议 response。

13.3 使用阻塞 DNS

阻塞解析会卡住整个事件循环。
推荐使用 bufferevent_socket_connect_hostname()。

13.4 错误后复用旧 bev

收到 EOF/ERROR/TIMEOUT 后通常释放旧对象，重连时创建新的 bufferevent。

13.5 没有输出队列上限

如果对端慢或网络异常，输出缓冲可能持续增长。

14. 一页总结

libevent 客户端最重要的是：

1. bufferevent_socket_new(base, -1, ...) 创建未连接 I/O 对象
2. 先设置回调、启用事件和超时，再调用 connect
3. BEV_EVENT_CONNECTED 表示 TCP 连接建立完成
4. DNS 连接推荐用 bufferevent_socket_connect_hostname
5. bufferevent_write 只是写入输出缓冲，不等于对端收到
6. 读回调里仍然要做协议拆包
7. 重连要有退避，不要无限快速重试

如果只记一句：

libevent 客户端的核心是把“连接中、已连接、读响应、写请求、失败重连”全部变成事件循环里的状态机。

15. 参考资料

1. libevent book: Ref6 bufferevent
   https://libevent.org/libevent-book/Ref6_bufferevent.html

2. libevent book: Ref9 dns
   https://libevent.org/libevent-book/Ref9_dns.html

3. libevent book: Ref4 event
   https://libevent.org/libevent-book/Ref4_event.html

Socket 基础与 TCP 编程

时间：2026/05/04

关键词：socket、TCP、bind/listen/accept、connect、非阻塞、粘包、半关闭、socket options
核心目标：把 Linux TCP socket 的基本生命周期、常见错误码和工程坑点串起来，为后续 epoll、libevent 和高性能服务端打底。

1. socket 到底是什么

在 Linux 里，socket 本质上也是一种文件描述符：

1

int fd = socket(AF_INET, SOCK_STREAM, 0);

它和普通文件 fd 的相似点：

• 都可以用整数 fd 表示
• 都可以被 close()
• 都能放进 epoll

它的不同点：

• 背后连接的是协议栈，而不是磁盘文件
• 读写行为受 TCP 状态、内核缓冲区和网络影响
• 错误码比普通文件 I/O 更丰富

常见 socket 类型：

2. TCP 服务端基本流程

TCP 服务端标准流程：

1
2
3
4
5
6
7

socket
  -> setsockopt
  -> bind
  -> listen
  -> accept
  -> recv/send
  -> close

最小阻塞式 echo server：

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

#include <arpa/inet.h>
#include <netinet/in.h>
#include <sys/socket.h>
#include <unistd.h>

#include <stdio.h>
#include <string.h>

int main(void) {
    int listen_fd = socket(AF_INET, SOCK_STREAM, 0);
    if (listen_fd < 0) {
        perror("socket");
        return 1;
    }

    int yes = 1;
    setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &yes, sizeof(yes));

    struct sockaddr_in addr;
    memset(&addr, 0, sizeof(addr));
    addr.sin_family = AF_INET;
    addr.sin_addr.s_addr = htonl(INADDR_ANY);
    addr.sin_port = htons(9876);

    if (bind(listen_fd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
        perror("bind");
        close(listen_fd);
        return 1;
    }

    if (listen(listen_fd, SOMAXCONN) < 0) {
        perror("listen");
        close(listen_fd);
        return 1;
    }

    for (;;) {
        int conn_fd = accept(listen_fd, NULL, NULL);
        if (conn_fd < 0) {
            perror("accept");
            continue;
        }

        char buf[4096];
        ssize_t n = 0;
        while ((n = recv(conn_fd, buf, sizeof(buf), 0)) > 0) {
            send(conn_fd, buf, (size_t)n, 0);
        }

        close(conn_fd);
    }

    close(listen_fd);
    return 0;
}

这个版本只能用于理解流程。
真正高并发服务端通常要配合：

• 非阻塞 socket
• epoll
• 用户态输入/输出缓冲
• 协议解析状态机

3. TCP 客户端基本流程

客户端流程：

1
2
3
4

socket
  -> connect
  -> send/recv
  -> close

最小示例：

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

#include <arpa/inet.h>
#include <netinet/in.h>
#include <sys/socket.h>
#include <unistd.h>

#include <stdio.h>
#include <string.h>

int main(void) {
    int fd = socket(AF_INET, SOCK_STREAM, 0);
    if (fd < 0) {
        perror("socket");
        return 1;
    }

    struct sockaddr_in addr;
    memset(&addr, 0, sizeof(addr));
    addr.sin_family = AF_INET;
    addr.sin_port = htons(9876);
    inet_pton(AF_INET, "127.0.0.1", &addr.sin_addr);

    if (connect(fd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
        perror("connect");
        close(fd);
        return 1;
    }

    const char *msg = "hello\n";
    send(fd, msg, strlen(msg), 0);

    char buf[4096];
    ssize_t n = recv(fd, buf, sizeof(buf), 0);
    if (n > 0) {
        fwrite(buf, 1, (size_t)n, stdout);
    }

    close(fd);
    return 0;
}

4. 地址、端口和字节序

IPv4 地址结构：

1
2
3
4
5

struct sockaddr_in addr;
memset(&addr, 0, sizeof(addr));
addr.sin_family = AF_INET;
addr.sin_port = htons(9876);
addr.sin_addr.s_addr = htonl(INADDR_ANY);

注意：

• 端口要用 htons
• IPv4 地址整数要用 htonl
• 网络字节序是大端

常用转换：

1
2

inet_pton(AF_INET, "127.0.0.1", &addr.sin_addr);
inet_ntop(AF_INET, &addr.sin_addr, buf, sizeof(buf));

如果要同时支持 IPv4 / IPv6，更推荐用 getaddrinfo()：

1
2
3
4

struct addrinfo hints;
memset(&hints, 0, sizeof(hints));
hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;

这样可以避免到处手写 sockaddr_in / sockaddr_in6 分支。

5. bind()、listen()、accept() 分别做什么

5.1 bind()

把 socket 绑定到本地 IP 和端口：

1

bind(fd, (struct sockaddr *)&addr, sizeof(addr));

服务端通常需要 bind()。
客户端一般不需要手动 bind，内核会自动分配本地临时端口。

5.2 listen()

把 TCP socket 变成监听 socket：

1

listen(fd, SOMAXCONN);

它不是开始读写数据，而是让内核维护连接队列。

5.3 accept()

从已完成连接队列中取出一个连接：

1

int conn_fd = accept(listen_fd, NULL, NULL);

返回的 conn_fd 才是和客户端通信的 socket。
listen_fd 继续用于接收新连接。

6. recv() 和 send() 的真实语义

6.1 recv()

1

ssize_t n = recv(fd, buf, sizeof(buf), 0);

返回值含义：

重要点：

• n == 0 不是“现在没数据”
• TCP 上一次 recv() 不等于一条完整消息

6.2 send()

1

ssize_t n = send(fd, data, len, MSG_NOSIGNAL);

返回值可能小于 len，表示只写入了一部分。
非阻塞服务端必须保存剩余数据，下次可写时继续发送。

建议：

• Linux 下写 socket 时考虑 MSG_NOSIGNAL
• 或者全局忽略 SIGPIPE
• 不要假设一次 send() 发完全部数据

7. TCP 是字节流：粘包和半包

TCP 不保留应用层消息边界。

应用层发送：

1
2

send("hello")
send("world")

接收端可能看到：

1

"helloworld"

也可能看到：

1
2
3

"he"
"llowor"
"ld"

这不是 TCP 的 bug，而是字节流语义。

常见协议设计：

工程里最常见的是长度前缀：

1

uint32_t length(network byte order) + payload

解析时必须基于用户态输入缓冲区做状态机。

8. 设置非阻塞

1
2
3
4
5
6
7
8
9

#include <fcntl.h>

int set_nonblock(int fd) {
    int flags = fcntl(fd, F_GETFL, 0);
    if (flags < 0) {
        return -1;
    }
    return fcntl(fd, F_SETFL, flags | O_NONBLOCK);
}

非阻塞后：

• 没有新连接时 accept() 返回 EAGAIN
• 没数据可读时 recv() 返回 EAGAIN
• 暂时写不进去时 send() 返回 EAGAIN
• connect() 可能返回 EINPROGRESS

非阻塞不是“不会失败”，而是“不能立刻完成时不要睡眠”。

9. 非阻塞 connect() 怎么判断成功

客户端非阻塞连接常见流程：

1
2
3
4
5
6
7
8

int rc = connect(fd, (struct sockaddr *)&addr, sizeof(addr));
if (rc == 0) {
    // 立即成功
} else if (errno == EINPROGRESS) {
    // 正在连接，等待 fd 可写
} else {
    // 立即失败
}

等到 epoll 报可写后，必须用 SO_ERROR 确认结果：

1
2
3
4
5
6
7
8
9

int err = 0;
socklen_t len = sizeof(err);
getsockopt(fd, SOL_SOCKET, SO_ERROR, &err, &len);

if (err == 0) {
    // connect 成功
} else {
    // connect 失败，err 是真实错误码
}

不能简单认为“可写 == 连接成功”。

10. 常用 socket options

10.1 SO_REUSEADDR

服务端重启时常用：

1
2

int yes = 1;
setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &yes, sizeof(yes));

它能减少端口被 TIME_WAIT 等状态影响导致无法 bind 的情况。

10.2 SO_REUSEPORT

允许多个 socket 绑定同一个 IP/端口，常用于多进程或多线程 accept 扩展：

1

setsockopt(fd, SOL_SOCKET, SO_REUSEPORT, &yes, sizeof(yes));

注意：

• 要在 bind() 前设置
• 负载分配由内核完成
• 不同系统支持和语义可能有差异

10.3 TCP_NODELAY

关闭 Nagle 算法：

1
2
3

#include <netinet/tcp.h>

setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &yes, sizeof(yes));

适合低延迟小包交互。
但如果业务能合并小包，应用层批量发送通常更好。

10.4 SO_KEEPALIVE

启用 TCP keepalive：

1

setsockopt(fd, SOL_SOCKET, SO_KEEPALIVE, &yes, sizeof(yes));

它适合发现长时间断开的死连接，但默认探测时间通常很长。
服务端仍然应该有应用层心跳或读写超时。

10.5 SO_RCVBUF / SO_SNDBUF

调整内核收发缓冲：

1
2
3

int size = 1 << 20;
setsockopt(fd, SOL_SOCKET, SO_RCVBUF, &size, sizeof(size));
setsockopt(fd, SOL_SOCKET, SO_SNDBUF, &size, sizeof(size));

缓冲区不是越大越好。
它会影响吞吐、延迟、内存占用和背压表现。

11. 半关闭与 shutdown()

close(fd) 表示关闭整个 socket。
shutdown() 可以关闭某个方向：

1
2

shutdown(fd, SHUT_WR); // 不再发送，但仍可接收
shutdown(fd, SHUT_RD); // 不再接收

常见场景：

• 客户端发送完请求后，用 SHUT_WR 告诉服务端请求结束
• 服务端继续返回响应

但很多应用协议并不依赖 TCP 半关闭，而是在协议层定义结束标记。
在事件驱动服务端里，是否允许半关闭要和连接状态机一起设计。

12. 常见错误码速记

最重要的是：

• EAGAIN 不等于失败
• EINTR 不等于失败
• n == 0 是对端关闭，不是暂时没数据

13. backlog、连接队列和 fd 上限

listen(fd, backlog) 里的 backlog 不是“最大并发连接数”。
它更接近内核已完成连接队列的长度提示。

高并发服务端要同时关注：

• listen() backlog
• net.core.somaxconn
• ulimit -n
• 进程最大 fd 数
• accept() 是否及时

如果 accept() 不及时，即使业务线程很空，也可能表现为客户端连接超时或被拒绝。

14. Socket 编程常见坑

14.1 忘记检查返回值

系统调用失败非常正常，不检查错误码就是把 bug 延后。

14.2 TCP 当消息协议用

TCP 是字节流，必须设计应用层消息边界。

14.3 非阻塞写不处理部分发送

一次 send() 可能只发送一部分。

14.4 对 SIGPIPE 没处理

向关闭连接写数据可能让进程收到 SIGPIPE。
Linux 下可以用 MSG_NOSIGNAL 或忽略该信号。

14.5 SO_REUSEADDR 在 bind() 后才设置

很多 socket option 必须在 bind() 或 connect() 前设置才有意义。

14.6 不限制连接和缓冲区

高并发服务端必须有上限：

• 最大连接数
• 每连接输入缓冲上限
• 每连接输出缓冲上限
• 请求大小上限
• 空闲超时

15. 一页总结

Socket 基础最值得记住的是：

1. socket 是协议栈背后的 fd
2. TCP 服务端主线是 socket -> bind -> listen -> accept -> recv/send
3. TCP 客户端主线是 socket -> connect -> send/recv
4. TCP 是字节流，应用层必须处理消息边界
5. 非阻塞 I/O 的核心是正确处理 EAGAIN/EINTR/EINPROGRESS
6. send() 可能部分成功，recv()==0 表示对端关闭
7. socket options 要在正确时机设置，并理解它们解决的问题

如果只记一句：

Linux 高性能服务器的底层不是某个框架，而是把 TCP socket 的状态、错误码、缓冲区和协议边界处理正确。

16. 参考资料

1. Linux man-pages: socket
   https://man7.org/linux/man-pages/man2/socket.2.html

2. Linux man-pages: bind
   https://man7.org/linux/man-pages/man2/bind.2.html

3. Linux man-pages: listen
   https://man7.org/linux/man-pages/man2/listen.2.html

4. Linux man-pages: accept
   https://man7.org/linux/man-pages/man2/accept.2.html

5. Linux man-pages: tcp
   https://man7.org/linux/man-pages/man7/tcp.7.html

STL 容器、迭代器与算法实践

时间：2026/05/04

关键词：容器选择、迭代器失效、标准算法、比较器、查找、排序、erase-remove、复杂度
核心目标：建立工程里选择容器和使用标准算法的基本判断，不把 STL 只当成“会 push_back 的工具箱”。

1. 为什么还要单独学 STL 容器和算法

现代 C++ 里，很多代码质量问题不是语法问题，而是：

• 容器选错
• 复杂度误判
• 迭代器失效
• 手写循环替代标准算法
• 比较器写错导致排序或查找出问题

标准库容器和算法的价值不只是“少写代码”，而是：

• 让意图更明确
• 让复杂度更可预期
• 让边界条件更少出错

2. 容器选择先看访问模式

常见容器可以先这样粗略分类：

经验上：

• 默认先考虑 std::vector
• 需要按 key 查找时考虑 unordered_map / map
• 不要因为“中间插删”就马上用 list

很多时候 vector 即使中间移动元素，也可能因为缓存友好而比链表快。

3. vector 为什么经常是默认答案

vector 的优势来自连续内存：

• 遍历快
• 随机访问快
• 缓存友好
• 容易和 C API 交互

1
2
3
4
5
6
7
8

#include <vector>

std::vector<int> xs;
xs.reserve(1000);

for (int i = 0; i < 1000; ++i) {
    xs.push_back(i);
}

如果你大概知道元素数量，reserve 通常是最简单有效的优化。

需要注意：

• reserve 改 capacity，不改 size
• resize 改 size，会真的构造元素
• 扩容会让原来的指针、引用、迭代器失效

4. 迭代器失效规则要主动记

迭代器失效是 STL 里非常常见的 bug 来源。

4.1 vector

发生扩容时：

• 所有迭代器失效
• 所有指针和引用也失效

中间 insert/erase 时：

• 插入点或删除点之后的迭代器通常失效

4.2 deque

deque 的失效规则比 vector 更复杂。
如果代码依赖长期保存迭代器，要查清具体操作的规则。

4.3 map / set

节点式有序容器一般比较稳定：

• 插入通常不影响已有迭代器
• 删除某个元素只让指向该元素的迭代器失效

4.4 unordered_map / unordered_set

rehash 时：

• 迭代器会失效

但指向元素的引用和指针通常仍然有效，前提是元素没有被删除。

5. 删除元素：erase-remove 惯用法

从 vector 删除满足条件的元素，经典写法是：

1
2
3
4
5
6
7
8
9
10
11

#include <algorithm>
#include <vector>

void remove_even(std::vector<int>& xs) {
    xs.erase(
        std::remove_if(xs.begin(), xs.end(), [](int x) {
            return x % 2 == 0;
        }),
        xs.end()
    );
}

std::remove_if 不会真的缩短容器，它只是把要保留的元素前移，并返回新的逻辑尾部。
真正删除尾部多余元素的是 erase。

C++20 起可以直接用：

1
2
3
4
5

#include <vector>

std::erase_if(xs, [](int x) {
    return x % 2 == 0;
});

更短，也更不容易写错。

6. 优先使用标准算法表达意图

与其写：

1
2
3
4
5
6
7

bool found = false;
for (int x : xs) {
    if (x == target) {
        found = true;
        break;
    }
}

不如写：

1
2
3

#include <algorithm>

bool found = std::find(xs.begin(), xs.end(), target) != xs.end();

常用算法：

算法名字本身就是文档。

7. 排序和比较器

std::sort 要求比较器满足严格弱序。

正确写法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

#include <algorithm>
#include <string>
#include <vector>

struct User {
    int id;
    std::string name;
};

void sort_users(std::vector<User>& users) {
    std::sort(users.begin(), users.end(), [](const User& a, const User& b) {
        return a.id < b.id;
    });
}

危险写法：

1

return a.id <= b.id; // 错

比较器不是“是否排在前面或相等”，而是：

a 是否严格排在 b 前面。

如果比较器违反规则，排序结果可能不稳定，甚至触发未定义行为。

8. 二分查找的前提

std::lower_bound 和 std::binary_search 的前提是：

• 区间已经按同一规则有序

1
2
3
4
5
6

#include <algorithm>
#include <vector>

bool contains_sorted(const std::vector<int>& xs, int value) {
    return std::binary_search(xs.begin(), xs.end(), value);
}

如果区间没有排序，二分查找没有意义。

常见模式：

1
2
3
4

auto it = std::lower_bound(xs.begin(), xs.end(), value);
if (it != xs.end() && *it == value) {
    // found
}

9. map 和 unordered_map 怎么选

优先问几个问题：

1. 是否需要按 key 有序遍历？
2. 是否需要范围查询？
3. key 有没有稳定可靠的 hash？
4. 是否关心最坏情况复杂度？

大致规则：

• 需要顺序或范围查询：std::map
• 只需要 key 到 value 的快速查询：std::unordered_map
• 数据量很小：有时 vector<pair<K,V>> 线性查找也够用

小数据上不要盲目迷信哈希表。
哈希计算、桶、节点分配都不是免费的。

10. 不要滥用 operator[]

map / unordered_map 的 operator[] 如果 key 不存在，会插入默认值。

1
2

std::unordered_map<std::string, int> count;
int n = count["missing"]; // 插入 {"missing", 0}

如果只是查询，优先用：

1
2
3
4

auto it = count.find("missing");
if (it != count.end()) {
    // use it->second
}

C++20 可以用：

1
2
3

if (count.contains("missing")) {
    // found
}

11. emplace 不是永远比 push_back 好

emplace_back 的价值是原位构造：

1
2

std::vector<std::string> names;
names.emplace_back(10, 'x');

但如果你已经有一个对象：

1
2
3

std::string s = "hello";
names.push_back(s);
names.push_back(std::move(s));

这时 push_back 更清楚。
不要把 emplace 当成“性能更强的 push”。

12. 常见坑

12.1 遍历时删除元素写错

删除元素后，原迭代器可能失效。
需要使用 erase 返回的新迭代器，或者使用 erase_if。

12.2 对无序容器的遍历顺序有期待

unordered_map 不保证顺序。
不同平台、不同运行时、rehash 后顺序都可能变化。

12.3 保存 vector 元素地址后继续 push

后续扩容可能让地址悬空。

12.4 比较器写成 <=

排序比较器必须表达严格小于关系。

12.5 在小数据量上过度复杂化

几十个元素的查找，用简单 vector 可能已经非常好。

13. 一页总结

STL 容器和算法最值得记住的是：

1. 默认优先考虑 vector，除非访问模式明确不适合
2. 先看复杂度，再看数据布局和缓存
3. 迭代器、引用、指针失效规则必须主动记
4. 标准算法能更准确表达意图
5. 排序比较器必须满足严格弱序
6. map / unordered_map 的选择取决于是否需要有序和范围查询

如果只记一句：

容器选择不是背 API，而是把访问模式、生命周期和复杂度放在一起判断。

14. 参考资料

1. cppreference: containers
   https://en.cppreference.com/w/cpp/container

2. cppreference: algorithms
   https://en.cppreference.com/w/cpp/algorithm

3. cppreference: iterator invalidation
   https://en.cppreference.com/w/cpp/container#Iterator_invalidation

编译模型、链接与 CMake 入门

时间：2026/05/04

关键词：头文件、源文件、声明、定义、链接、ODR、静态库、动态库、CMake、target
核心目标：理解 C++ 工程从源码到可执行文件的大致流程，避免头文件乱放、重复定义和 CMake 全局变量式写法。

1. 为什么现代 C++ 也必须懂编译模型

很多 C++ 工程问题表面上是“编译报错”，本质上是：

• 声明和定义混乱
• 头文件包含关系失控
• 重复定义违反 ODR
• 链接阶段找不到符号
• CMake 里 include path 和 link library 没有按 target 管理

懂编译模型的价值是：

• 知道错误发生在预处理、编译还是链接
• 知道哪些内容该放头文件，哪些该放 .cpp
• 知道库和可执行文件怎么组织

2. 从源码到程序的几个阶段

一个 C++ 文件大致经历：

1. 预处理：展开 #include、宏、条件编译
2. 编译：把翻译单元编译成目标文件
3. 汇编：生成机器码形式的 .o / .obj
4. 链接：把多个目标文件和库合成可执行文件或库

可以粗略理解成：

1
2
3
4
5
6
7
8
9
10

main.cpp + include 的头文件
    -> 一个翻译单元
    -> main.o

foo.cpp + include 的头文件
    -> 一个翻译单元
    -> foo.o

main.o + foo.o + libraries
    -> app

头文件本身通常不会单独编译。
它是被各个 .cpp 包含后，成为不同翻译单元的一部分。

3. 声明和定义

声明告诉编译器：

有这个名字，它的类型长这样。

1

int add(int a, int b); // 函数声明

定义真正提供实体：

1
2
3

int add(int a, int b) {
    return a + b;
}

变量也一样：

1
2

extern int global_count; // 声明
int global_count = 0;    // 定义

常见组织方式：

1
2
3

include/math.hpp   -> 声明
src/math.cpp       -> 定义
src/main.cpp       -> 使用

4. 头文件里应该放什么

通常适合放头文件：

• 类声明
• 函数声明
• 模板定义
• inline 函数定义
• constexpr 小函数
• 常量声明或 inline constexpr 变量

通常不适合放头文件：

• 普通全局变量定义
• 非 inline 普通函数定义
• 大量不必要的实现细节
• 会导致编译依赖爆炸的重型 include

错误例子：

1
2

// bad.hpp
int counter = 0; // 被多个 cpp include 后会重复定义

更合适：

1
2
3
4
5

// counter.hpp
extern int counter;

// counter.cpp
int counter = 0;

C++17 起，如果确实想在头文件定义全局常量，可以用：

1

inline constexpr int max_retry = 3;

5. ODR：一个定义规则

ODR 是：

One Definition Rule

粗略说：

• 一个具有外部链接的实体，在整个程序里通常只能有一个定义
• 类、模板、inline 函数可以出现在多个翻译单元，但定义必须一致

典型 ODR 问题：

1
2
3
4

// util.hpp
int twice(int x) {
    return x * 2;
}

如果这个头文件被多个 .cpp 包含，就可能链接时报重复定义。

修正：

1
2
3
4

// util.hpp
inline int twice(int x) {
    return x * 2;
}

或者：

1
2
3
4
5
6
7

// util.hpp
int twice(int x);

// util.cpp
int twice(int x) {
    return x * 2;
}

6. 为什么模板通常写在头文件

模板不是普通函数。
编译器需要在使用点看到模板定义，才能根据具体类型实例化代码。

1
2
3
4

template <class T>
T max_value(T a, T b) {
    return a < b ? b : a;
}

如果只把模板声明放头文件、定义放 .cpp，其他翻译单元通常没法实例化它。

所以模板库常见形态是：

• 大量实现放在头文件
• 或者放在 .ipp / .inl 后再被头文件 include

7. 链接错误怎么读

常见链接错误：

7.1 undefined reference / undefined symbol

意思是：

• 编译器看到了声明
• 链接器找不到定义

常见原因：

• .cpp 没加入构建
• 忘记链接某个库
• 函数签名声明和定义不一致
• 模板定义不可见

7.2 duplicate symbol / multiple definition

意思是：

• 同一个外部符号有多个定义

常见原因：

• 普通函数定义写进头文件但没加 inline
• 全局变量定义写进头文件
• 同一个 .cpp 被错误地编进多个目标

8. 静态库和动态库

静态库：

• Linux/macOS 常见 .a
• Windows 常见 .lib
• 链接时把需要的目标代码合进最终产物

动态库：

• Linux .so
• macOS .dylib
• Windows .dll
• 程序运行时加载库代码

工程实践里要关心：

• 头文件提供编译期声明
• 库文件提供链接期或运行期实现
• ABI 边界要谨慎暴露 STL 类型、异常、内存分配策略

9. CMake 的核心是 target

现代 CMake 不建议把所有配置堆进全局变量。
更推荐围绕 target 写：

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

cmake_minimum_required(VERSION 3.20)
project(demo LANGUAGES CXX)

add_library(core
    src/math.cpp
)

target_include_directories(core
    PUBLIC
        include
)

target_compile_features(core
    PUBLIC
        cxx_std_20
)

add_executable(app
    src/main.cpp
)

target_link_libraries(app
    PRIVATE
        core
)

这里的依赖关系是：

1

app -> core

core 的 public include path 会传递给链接它的 target。

10. PUBLIC / PRIVATE / INTERFACE

这三个词是现代 CMake 的核心。

例子：

1
2
3
4

target_include_directories(core
    PUBLIC include
    PRIVATE src
)

含义：

• core 自己能 include include 和 src
• 依赖 core 的 target 只能继承 include

经验规则：

• 头文件里需要暴露给使用者的 include path：PUBLIC
• 只有 .cpp 内部使用的 include path：PRIVATE
• header-only 库：常用 INTERFACE

11. 一个常见工程结构

1
2
3
4
5
6
7
8
9
10

project/
    CMakeLists.txt
    include/
        demo/
            math.hpp
    src/
        math.cpp
        main.cpp
    tests/
        math_test.cpp

头文件：

1
2
3
4
5
6
7
8

// include/demo/math.hpp
#pragma once

namespace demo {

int add(int a, int b);

}

实现：

1
2
3
4
5
6
7
8
9
10

// src/math.cpp
#include "demo/math.hpp"

namespace demo {

int add(int a, int b) {
    return a + b;
}

}

使用：

1
2
3
4
5
6

// src/main.cpp
#include "demo/math.hpp"

int main() {
    return demo::add(1, 2);
}

12. include guard 和 #pragma once

传统 include guard：

1
2
3
4
5
6

#ifndef DEMO_MATH_HPP
#define DEMO_MATH_HPP

int add(int a, int b);

#endif

现代工程里也常用：

1

#pragma once

两者目的都是避免同一个头文件在一个翻译单元内被重复包含。
注意它们解决的是“重复包含”，不是跨多个 .cpp 的重复定义。

13. 降低编译依赖

C++ 大项目编译慢，常常是 include 依赖太重。

常见做法：

• 头文件少 include，能前向声明就前向声明
• 实现细节放 .cpp
• 大型第三方头只在 .cpp 包含
• 公共头文件保持稳定

例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// widget.hpp
#pragma once

#include <memory>

class Impl;

class Widget {
public:
    Widget();
    ~Widget();

private:
    std::unique_ptr<Impl> impl_;
};

这就是常说的 Pimpl 思路。
它能减少头文件暴露的实现细节，但会引入一次间接访问和动态分配成本。

14. 常见坑

14.1 把普通函数定义放头文件

如果没有 inline，多个翻译单元包含后可能重复定义。

14.2 .cpp 没加入 CMake target

这通常会导致 undefined symbol。

14.3 include path 靠全局变量到处扩散

现代 CMake 更推荐 target 管理依赖。

14.4 头文件包含太重

会让一点小改动触发大量重编译。

14.5 混淆编译错误和链接错误

编译错误通常发生在单个翻译单元。
链接错误通常发生在多个目标文件合并时。

15. 一页总结

这篇最值得记住的是：

1. .cpp 加上它 include 的头文件形成翻译单元
2. 声明让编译通过，定义让链接通过
3. 普通函数和全局变量定义不要随便放头文件
4. 模板通常需要在使用点可见，所以常放头文件
5. 现代 CMake 应围绕 target 管理 include、features 和 link
6. PUBLIC / PRIVATE / INTERFACE 表达依赖是否传递

如果只记一句：

C++ 工程不是把文件堆在一起编译，而是把翻译单元、符号和 target 依赖组织清楚。

16. 参考资料

1. cppreference: translation phases
   https://en.cppreference.com/w/cpp/language/translation_phases

2. cppreference: definitions and ODR
   https://en.cppreference.com/w/cpp/language/definition

3. CMake: target_include_directories
   https://cmake.org/cmake/help/latest/command/target_include_directories.html

4. CMake: target_link_libraries
   https://cmake.org/cmake/help/latest/command/target_link_libraries.html

测试、调试与 Sanitizer 工具链

时间：2026/05/04

关键词：单元测试、集成测试、断言、日志、调试器、AddressSanitizer、UBSan、TSan、CI
核心目标：把“代码看起来对”变成“有测试、有诊断、有工具能抓问题”的工程流程。

1. 为什么 C++ 更需要工具链意识

C++ 的自由度很高，也意味着很多错误不会自动变成清晰异常：

• 越界访问
• use-after-free
• 数据竞争
• 未定义行为
• 资源泄漏
• ODR 或链接问题

所以现代 C++ 实践里，测试和诊断工具不是附属品，而是基本能力。

一个比较健康的本地开发流程是：

1. 写小而明确的单元测试
2. Debug 模式开启断言和诊断
3. 定期跑 Sanitizer 版本
4. CI 固定跑核心测试集

2. 测试分层

常见测试可以粗略分三层：

不要一上来只写“大而全”的测试。
越底层的逻辑，越适合用小测试钉住行为。

3. 一个最小测试例子

即使不用测试框架，也可以先写最小可运行测试：

1
2
3
4
5
6
7
8
9
10

#include <cassert>

int add(int a, int b) {
    return a + b;
}

int main() {
    assert(add(1, 2) == 3);
    assert(add(-1, 1) == 0);
}

这种测试很朴素，但比“手动运行看一眼输出”可靠。

工程里常用测试框架：

• GoogleTest
• Catch2
• doctest

框架的价值是：

• 更好的失败信息
• 测试组织
• fixture
• 参数化测试
• 和 CI 集成更自然

4. 测试什么

优先测试这些东西：

• 边界条件
• 空输入
• 错误路径
• 所有权转移
• 异常或错误返回
• 并发关闭流程
• 之前出过 bug 的路径

例子：

1
2
3
4
5
6
7
8

#include <optional>
#include <string_view>

std::optional<int> parse_digit(std::string_view s) {
    if (s.size() != 1) return std::nullopt;
    if (s[0] < '0' || s[0] > '9') return std::nullopt;
    return s[0] - '0';
}

至少应该覆盖：

• "0"
• "9"
• ""
• "12"
• "x"

5. 断言的作用

断言适合检查：

• 前置条件
• 内部不变量
• 理论上不该发生的状态

1
2
3
4
5
6
7

#include <cassert>
#include <vector>

int get_first(const std::vector<int>& xs) {
    assert(!xs.empty());
    return xs.front();
}

断言不是错误处理。
如果空输入是正常业务失败，应该返回错误或抛异常，而不是只写 assert。

注意：

• 定义 NDEBUG 后，标准 assert 会被移除
• 不要把有副作用的表达式写进 assert

6. 日志和调试器各自解决什么

日志适合：

• 线上或长时间运行问题
• 记录关键状态转移
• 还原错误发生前后的上下文

调试器适合：

• 本地复现
• 观察变量
• 单步执行
• 查看调用栈

不要把日志当成测试，也不要用调试器代替可重复测试。
测试负责固定行为，日志和调试器负责定位问题。

7. AddressSanitizer：先抓内存错误

AddressSanitizer 常用于发现：

• 越界访问
• use-after-free
• double-free
• 部分内存泄漏问题

常见编译方式：

1
2

clang++ -std=c++20 -g -O1 -fno-omit-frame-pointer -fsanitize=address main.cpp -o app
./app

建议加上：

1

-fno-omit-frame-pointer

这样栈回溯通常更清楚。

如果需要 leak 检测：

1

ASAN_OPTIONS=detect_leaks=1 ./app

8. UndefinedBehaviorSanitizer

UBSan 常用于发现未定义行为，例如：

• 有符号整数溢出
• 非法类型转换
• 错误对齐访问
• 除零
• 某些无效 enum 值

常见编译方式：

1
2

clang++ -std=c++20 -g -O1 -fsanitize=undefined main.cpp -o app
./app

也可以和 ASan 一起用：

1

clang++ -std=c++20 -g -O1 -fno-omit-frame-pointer -fsanitize=address,undefined main.cpp -o app

很多 UB 在普通运行时看不出问题，但会让优化器基于错误假设重写代码。
所以 UBSan 对 C++ 很有价值。

9. ThreadSanitizer

TSan 用于发现数据竞争：

1
2

clang++ -std=c++20 -g -O1 -fsanitize=thread main.cpp -o app
./app

适合检查：

• 非原子共享变量并发读写
• 锁保护不一致
• 错误的对象发布

注意：

• TSan 运行开销较大
• 不建议和 ASan 在同一个构建里混用
• 对某些平台和第三方库支持有限

并发 bug 很难靠肉眼检查完整，TSan 是非常重要的辅助工具。

10. Debug / Release / RelWithDebInfo

常见构建类型：

排查性能或线上问题时，RelWithDebInfo 很有用：

• 接近真实优化路径
• 保留栈信息和符号

不要只在 Debug 下测试。
有些 UB、时序问题、未初始化问题会在 Release 下更容易暴露。

11. CMake 里加测试

一个最小结构：

1
2
3
4
5
6
7
8
9
10
11
12

enable_testing()

add_executable(math_test
    tests/math_test.cpp
)

target_link_libraries(math_test
    PRIVATE
        core
)

add_test(NAME math_test COMMAND math_test)

运行：

1

ctest --test-dir build --output-on-failure

如果使用 GoogleTest，通常还会用它提供的测试发现工具。
但底层原则不变：

• 测试本身也是一个 target
• 测试链接被测库
• ctest 统一运行测试

12. CMake 里加 Sanitizer 选项

小项目可以先写得简单：

1
2
3
4
5
6

option(ENABLE_ASAN "Enable AddressSanitizer" OFF)

if(ENABLE_ASAN)
    add_compile_options(-fsanitize=address -fno-omit-frame-pointer)
    add_link_options(-fsanitize=address)
endif()

更工程化的写法是把 Sanitizer 配置绑定到具体 target，避免污染第三方库。

例如：

1
2

target_compile_options(app PRIVATE -fsanitize=address -fno-omit-frame-pointer)
target_link_options(app PRIVATE -fsanitize=address)

不要只加编译选项，链接阶段也要加对应 sanitizer。

13. 最小 CI 检查清单

一个实用的 C++ CI 至少可以包含：

1. 普通 Debug 构建
2. 普通 Release 或 RelWithDebInfo 构建
3. 单元测试
4. ASan + UBSan 测试
5. 关键并发模块定期跑 TSan

如果项目更成熟，还可以加：

• clang-tidy
• clang-format 检查
• 覆盖率
• benchmark 回归
• 包管理和依赖版本锁定

先把最关键的测试和 sanitizer 跑起来，比一开始追求全套流程更重要。

14. 常见坑

14.1 只测正常路径

错误路径和边界条件更容易藏 bug。

14.2 把 assert 当成用户输入校验

Release 下断言可能被移除。
可恢复错误应该走错误处理流程。

14.3 只在 Debug 下运行

Release 优化可能暴露完全不同的问题。

14.4 Sanitizer 只加了编译选项

链接阶段也需要对应选项。

14.5 把 TSan 报告轻易忽略

数据竞争不是“小概率问题”，而是未定义行为。

15. 一页总结

测试和工具链最值得记住的是：

1. 单元测试负责固定小范围行为
2. 回归测试负责防止历史 bug 回来
3. 断言检查内部不变量，不替代错误处理
4. ASan 抓内存错误，UBSan 抓未定义行为，TSan 抓数据竞争
5. Debug 和 Release 都要测
6. CMake 里测试和 sanitizer 最好按 target 管理

如果只记一句：

现代 C++ 工程要靠测试、断言、日志、调试器和 Sanitizer 共同兜底，不能只靠“我看代码应该没问题”。

16. 参考资料

1. Clang AddressSanitizer
   https://clang.llvm.org/docs/AddressSanitizer.html

2. Clang UndefinedBehaviorSanitizer
   https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html

3. Clang ThreadSanitizer
   https://clang.llvm.org/docs/ThreadSanitizer.html

4. CMake: testing
   https://cmake.org/cmake/help/latest/manual/ctest.1.html

std::pmr 与内存池

时间：2026/05/04

关键词：std::pmr、内存池、memory_resource、monotonic_buffer_resource、pool_resource、分配开销、局部性
核心目标：理解如何把 STL 容器的内存来源换成更适合高性能场景的资源。

1. 为什么内存分配会影响性能

很多 C++ 程序的慢，不一定慢在计算本身，而是慢在频繁分配：

• 每次 new/delete 都可能进入通用堆分配器
• 小对象分配容易带来额外元数据和碎片
• 分配释放可能涉及锁或线程缓存
• 分散的堆对象会降低缓存命中率

例如：

1
2
3
4
5

std::vector<std::string> names;

for (int i = 0; i < n; ++i) {
    names.push_back(make_name(i));
}

这里至少可能有两类分配：

• vector 自己扩容
• string 内容超过小字符串优化时单独分配

高性能场景里常见思路是：

• 已知规模时先 reserve
• 减少对象数量和间接访问
• 把一批生命周期相同的对象放进同一个内存资源

std::pmr 就是标准库提供的这类工具。

2. 传统 allocator 的问题

普通容器的 allocator 是模板参数：

1

std::vector<int, MyAllocator<int>> v;

这意味着：

• 分配策略参与类型
• 换 allocator 后容器类型也变了
• 状态型 allocator 写起来容易复杂

比如：

1
2

std::vector<int> a;
std::vector<int, MyAllocator<int>> b;

a 和 b 是两个不同类型。
如果大量接口都暴露这种类型，工程复杂度会很快上升。

3. std::pmr 的核心想法

pmr 全称是：

polymorphic memory resource

它把“从哪里分配内存”抽象成一个运行时对象：

1

std::pmr::memory_resource*

常见组件：

所以 pmr 的重点不是“换一个容器”，而是：

容器接口基本不变，但内存来源可以由外部资源控制。

4. 第一个 pmr::vector 例子

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

#include <array>
#include <cstddef>
#include <iostream>
#include <memory_resource>
#include <vector>

int main() {
    std::array<std::byte, 1024> buffer{};
    std::pmr::monotonic_buffer_resource pool{
        buffer.data(),
        buffer.size()
    };

    std::pmr::vector<int> xs{&pool};

    for (int i = 0; i < 10; ++i) {
        xs.push_back(i);
    }

    for (int x : xs) {
        std::cout << x << '\n';
    }
}

这里的关键是：

• buffer 是一块预先准备好的内存
• pool 从这块 buffer 中切内存
• xs 的元素存储区优先来自 pool
• 如果 buffer 不够，默认会继续向上游资源申请

默认上游资源通常是：

1

std::pmr::get_default_resource()

它最终一般还是会走普通堆分配。

5. memory_resource 是真正的分配策略

memory_resource 的核心接口可以粗略理解为：

1
2
3
4
5
6

class memory_resource {
public:
    void* allocate(std::size_t bytes, std::size_t alignment);
    void deallocate(void* p, std::size_t bytes, std::size_t alignment);
    bool is_equal(const memory_resource& other) const noexcept;
};

实际标准接口底层是虚函数：

1
2
3

virtual void* do_allocate(std::size_t bytes, std::size_t alignment) = 0;
virtual void do_deallocate(void* p, std::size_t bytes, std::size_t alignment) = 0;
virtual bool do_is_equal(const memory_resource& other) const noexcept = 0;

这说明：

• pmr 本身用了运行时多态
• 容器不用知道具体资源类型
• 换资源时不必改变容器类型

这里的虚调用通常不是主要瓶颈，因为一次分配本身就比一次普通函数调用贵得多。
真正要关注的是能不能减少分配次数、改善局部性、避免堆碎片。

6. polymorphic_allocator 做了什么

std::pmr::vector<T> 大致等价于：

1

std::vector<T, std::pmr::polymorphic_allocator<T>>

polymorphic_allocator<T> 内部保存一个：

1

std::pmr::memory_resource*

当容器需要分配内存时，它会把请求转发给这个资源。

所以可以这样理解：

1
2
3
4

pmr::vector<int>
    -> polymorphic_allocator<int>
        -> memory_resource
            -> 具体内存池 / arena / 堆

这和手写 allocator 的区别是：

• allocator 类型固定
• 资源对象可在运行期替换
• 更适合在工程里传递容器和资源

7. monotonic_buffer_resource：线性增长的 arena

monotonic_buffer_resource 的行为很像 arena：

• 每次分配只向前移动当前位置
• 单个 deallocate 通常不真正回收
• 整个资源析构或 release() 时统一释放

适合：

• 一次请求中的临时对象
• 一帧游戏逻辑中的临时数据
• 一次解析、构图、搜索过程
• 生命周期高度一致的一批对象

例子：

1
2
3
4
5
6
7
8
9
10
11
12

#include <memory_resource>
#include <string>
#include <vector>

struct RequestContext {
    std::pmr::monotonic_buffer_resource scratch;
    std::pmr::vector<std::pmr::string> words;

    RequestContext()
        : scratch(4096),
          words(&scratch) {}
};

这类资源的好处是：

• 分配路径短
• 几乎没有单个对象释放成本
• 同一批数据更可能靠近

但代价也很明确：

• 单个对象释放不一定还给池
• 长生命周期资源里容易堆积无用内存
• 必须保证容器不比资源活得更久

8. pmr::string 和嵌套容器

pmr 容器最容易忽略的一点是：

外层容器用 pmr，不代表内层对象自动都用同一个资源。

例如：

1

std::pmr::vector<std::string> names{&pool};

这里：

• vector 的数组存储用 pool
• 但每个 std::string 自己的动态内存仍然用默认分配器

如果想让字符串内容也走同一个资源，应该用：

1

std::pmr::vector<std::pmr::string> names{&pool};

更完整的例子：

1
2
3
4
5
6
7
8
9
10
11

#include <memory_resource>
#include <string>
#include <vector>

int main() {
    std::pmr::monotonic_buffer_resource pool{4096};

    std::pmr::vector<std::pmr::string> names{&pool};
    names.emplace_back("alpha");
    names.emplace_back("beta");
}

这里 vector 的 allocator 会参与构造元素，所以新放入的 pmr::string 也会使用同一个资源。
如果你在外面单独创建 pmr::string，就要显式把资源传给它：

1

std::pmr::string name{"alpha", &pool};

9. pool resource：复用固定大小块

monotonic_buffer_resource 偏向“只涨不退”。
如果你的场景里有大量同尺寸或近似尺寸的小对象反复分配释放，可以考虑 pool resource。

标准库提供两类：

例子：

1
2
3
4
5
6
7
8
9
10
11

#include <memory_resource>
#include <vector>

int main() {
    std::pmr::unsynchronized_pool_resource pool;
    std::pmr::vector<int> xs{&pool};

    for (int i = 0; i < 1000; ++i) {
        xs.push_back(i);
    }
}

选择时可以粗略记：

• 批量构建、整体释放：优先 monotonic_buffer_resource
• 小对象反复分配释放：考虑 unsynchronized_pool_resource
• 多线程共享同一个资源：才考虑 synchronized_pool_resource

在高性能代码里，更常见的方式是：

• 每个线程一个无锁资源
• 避免多个线程抢同一个 pool

10. 资源生命周期是第一安全边界

pmr 容器通常只保存：

1

memory_resource*

所以资源必须比使用它的容器活得更久。

错误示意：

1
2
3
4
5
6
7
8
9

#include <memory_resource>
#include <vector>

std::pmr::vector<int> bad() {
    std::pmr::monotonic_buffer_resource pool{1024};
    std::pmr::vector<int> xs{&pool};
    xs.push_back(1);
    return xs; // 错：返回后 xs 指向已经销毁的 pool
}

更安全的做法是把资源和容器放在同一个拥有者里，并保证资源先声明：

1
2
3
4
5
6
7
8
9
10
11

#include <memory_resource>
#include <vector>

struct WorkBuffer {
    std::pmr::monotonic_buffer_resource pool;
    std::pmr::vector<int> data;

    WorkBuffer()
        : pool(4096),
          data(&pool) {}
};

成员析构顺序和声明顺序相反：

• data 先析构
• pool 后析构

这正好满足“容器先死，资源后死”。

11. 上游资源与禁止堆回退

默认情况下，monotonic_buffer_resource 初始 buffer 不够时，会向上游资源继续申请。

有时你希望测试或实时系统里明确禁止堆分配，可以用：

1

std::pmr::null_memory_resource()

例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

#include <array>
#include <cstddef>
#include <memory_resource>
#include <vector>

int main() {
    std::array<std::byte, 128> buffer{};

    std::pmr::monotonic_buffer_resource pool{
        buffer.data(),
        buffer.size(),
        std::pmr::null_memory_resource()
    };

    std::pmr::vector<int> xs{&pool};
    xs.reserve(16);
}

如果超出这块 buffer，分配会失败并抛出 std::bad_alloc。
这很适合用来发现“以为没有堆分配，实际还有”的路径。

12. 和 reserve 的关系

pmr 不是 reserve 的替代品。

即使用了内存池，vector 扩容时仍然可能：

• 分配新连续内存
• 移动旧元素
• 让旧指针、引用、迭代器失效

所以：

1
2

std::pmr::vector<int> xs{&pool};
xs.reserve(n);

依然是非常重要的优化。

可以把两者关系理解成：

• reserve 减少容器扩容次数
• pmr 降低每次分配的成本，并控制内存来源

13. 多线程使用建议

内存池和并行编程放在一起时，最容易踩的是共享资源争用。

常见策略：

1. 每个线程一个 unsynchronized_pool_resource
2. 每个任务一个 monotonic_buffer_resource
3. 合并结果时再转移到长期存储

尽量避免：

• 所有线程共享一个同步 pool
• 临时对象跨线程持有另一个线程的资源
• 在线程结束后继续使用线程局部资源里的对象

简单记忆：

pmr 优化的是分配路径，但共享同一个资源仍然可能把并行程序重新串行化。

14. 什么时候值得用 std::pmr

比较值得考虑：

• profiler 显示分配占比明显
• 临时对象数量很多
• 对象生命周期天然成批
• 需要把一组容器绑定到同一片内存
• 想限制某段代码不能偷偷走堆分配

暂时不必急着用：

• 数据量很小
• 算法复杂度才是主要瓶颈
• 容器已经提前 reserve
• 没有明确的生命周期边界

高性能优化的一般顺序仍然是：

1. 选对算法
2. 选对数据布局
3. 减少不必要的对象和拷贝
4. 再考虑 allocator / pmr 这类内存来源优化

15. 常见坑

15.1 资源比容器先析构

这是 pmr 里最危险的问题。
容器内部只是保存资源指针，不拥有资源。

15.2 外层用了 pmr，内层没用

std::pmr::vector<std::string> 只解决外层数组分配，字符串内容仍可能走默认堆。
需要时应使用 std::pmr::string。

15.3 把 monotonic_buffer_resource 当成通用释放器

它适合整体释放，不适合频繁单独归还对象。

15.4 以为内存池一定更快

不测量就下结论很危险。
如果瓶颈在算法、锁、缓存 miss 或 I/O，换 allocator 可能几乎没有收益。

15.5 多线程共享同一个 pool

共享资源可能引入锁争用。
很多并行场景中，线程本地资源更自然。

16. 一页总结

std::pmr 最值得记住的是：

1. 它把容器的内存来源抽象成运行时 memory_resource
2. pmr::vector<T> 本质上是使用 polymorphic_allocator<T> 的标准容器
3. monotonic_buffer_resource 适合批量分配、整体释放
4. pool resource 适合小对象复用，但要注意线程同步成本
5. 资源生命周期必须覆盖所有使用它的容器

如果只记一句：

std::pmr 不是魔法加速器，而是让你把“一批对象从哪里分配、什么时候一起释放”这件事说清楚。

17. 参考资料

1. cppreference: memory resource
   https://en.cppreference.com/w/cpp/memory/memory_resource

2. cppreference: polymorphic allocator
   https://en.cppreference.com/w/cpp/memory/polymorphic_allocator

3. cppreference: monotonic buffer resource
   https://en.cppreference.com/w/cpp/memory/monotonic_buffer_resource

4. cppreference: pool resources
   https://en.cppreference.com/w/cpp/memory/synchronized_pool_resource

虚函数、多态与动态派发

时间：2026/05/04

关键词：虚函数、动态多态、vptr、vtable、虚析构、对象切片、动态派发、去虚化、CRTP、std::variant
核心目标：理解虚函数的语义、底层直觉和性能代价，知道什么时候该用动态多态，什么时候该换成静态分发。

1. 虚函数解决什么问题

虚函数解决的是：

调用方只知道基类接口，但运行时对象可能是不同派生类。

例子：

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 <memory>
#include <vector>

struct Task {
    virtual ~Task() = default;
    virtual void run() = 0;
};

struct LoadTask : Task {
    void run() override {
        std::cout << "load\n";
    }
};

struct SaveTask : Task {
    void run() override {
        std::cout << "save\n";
    }
};

int main() {
    std::vector<std::unique_ptr<Task>> tasks;
    tasks.push_back(std::make_unique<LoadTask>());
    tasks.push_back(std::make_unique<SaveTask>());

    for (const auto& task : tasks) {
        task->run();
    }
}

这里调用方只面对：

1

Task

但实际执行哪个 run()，取决于对象的真实动态类型。

2. 普通函数和虚函数的区别

普通成员函数：

1
2
3

struct A {
    void f();
};

调用时，编译器通常在编译期就知道目标函数：

1
2

A a;
a.f();

虚函数：

1
2
3

struct Base {
    virtual void f();
};

通过基类指针或引用调用时：

1
2
3

void call(Base& b) {
    b.f();
}

编译器不能只看 Base& 就确定具体执行哪个版本，因为 b 可能引用任何派生类对象。

这就是动态派发：

• 编译期确定接口
• 运行期确定实现

3. 纯虚函数与抽象类

纯虚函数写法：

1
2
3
4

struct Shape {
    virtual ~Shape() = default;
    virtual double area() const = 0;
};

含有纯虚函数的类是抽象类，不能直接实例化：

1

// Shape s; // 错

派生类需要实现这个接口：

1
2
3
4
5
6
7
8
9

struct Circle : Shape {
    double r;

    explicit Circle(double radius) : r(radius) {}

    double area() const override {
        return 3.1415926 * r * r;
    }
};

这里的 override 很重要，它能让编译器检查你是否真的重写了基类虚函数。

4. override 和 final

重写虚函数时推荐总是写 override：

1
2
3
4
5
6
7

struct Base {
    virtual void update(int dt);
};

struct Derived : Base {
    void update(int dt) override;
};

如果参数写错：

1
2
3

struct Bad : Base {
    void update(double dt) override; // 编译报错
};

这能避免“以为重写了，实际新增了一个函数”的问题。

final 表示不允许继续重写：

1
2
3

struct Leaf final : Base {
    void update(int dt) override;
};

或者只禁止某个虚函数继续被重写：

1
2
3

struct Mid : Base {
    void update(int dt) final;
};

在某些情况下，final 也能帮助编译器做去虚化优化。

5. 虚析构为什么重要

如果一个类要被当作多态基类使用，析构函数通常必须是虚函数：

1
2
3
4
5
6
7
8
9

struct Base {
    virtual ~Base() = default;
};

struct Derived : Base {
    ~Derived() {
        // 释放 Derived 自己的资源
    }
};

否则这样删除会出问题：

1
2

Base* p = new Derived;
delete p; // 基类析构非 virtual 时有未定义行为风险

现代 C++ 更常写成：

1

std::unique_ptr<Base> p = std::make_unique<Derived>();

但即使用智能指针，底层仍然会通过基类析构。
所以多态基类的析构函数依然要设计清楚。

经验规则：

• 要通过基类指针删除对象：基类析构必须是 virtual
• 不允许通过基类删除：可以把基类析构设为 protected 且非虚

6. 函数和对象在内存里大概在哪里

先建立一个底层直觉：

• 函数代码通常位于程序的代码段
• 普通对象里不会保存成员函数的机器码
• 成员函数不是“每个对象各存一份”
• 对象保存的是数据成员，以及实现多态所需的额外信息

例如：

1
2
3
4

struct Counter {
    int value;
    void inc() { ++value; }
};

每个 Counter 对象通常只需要保存：

1

value

inc() 的机器码在代码段里，所有 Counter 对象共享同一份函数代码。

调用成员函数时，可以粗略理解成编译器额外传了一个隐藏参数：

1

c.inc();

近似成：

1

Counter_inc(&c);

这个隐藏的对象指针就是常说的：

1

this

7. vptr 和 vtable 的近似模型

对含虚函数的对象，主流实现通常会在对象中放一个隐藏指针：

1

vptr

它指向一张虚函数表：

1

vtable

虚函数表里保存函数地址。
可以粗略理解成：

1
2
3
4
5