C++——高性能组件

一、什么是高性能组件

在 C++ 编程中，“高性能组件” 通常指那些经过精心设计、能够高效处理任务的代码模块、类或库，它们在速度、内存占用、资源利用等方面表现优异，特别适合对性能要求严苛的场景（如游戏引擎、实时系统、高频交易、大规模数据处理等）。

1.1 C++ 中高性能组件的核心设计原则

1. 内存高效管理
   • 减少动态内存分配（new/delete），避免频繁的内存碎片（例如使用内存池）。
   • 合理使用栈内存（生命周期短的对象）和自定义内存分配器。
   • 示例：STL 中的std::vector比std::list在连续存储场景下性能更优，因为它的内存连续，缓存利用率更高。
2. 减少冗余计算
   • 避免重复计算（如缓存中间结果）。
   • 利用编译期优化（模板元编程）将计算逻辑转移到编译阶段。
   • 示例：用constexpr实现编译期常量计算，减少运行时开销。
3. 优化数据访问模式
   • 按 CPU 缓存行对齐数据，提升缓存命中率（例如alignas(64)关键字）。
   • 避免随机内存访问，尽量使用连续数据结构（数组、向量）。
   • 示例：遍历二维数组时按行优先（符合内存布局）而非列优先，减少缓存失效。
4. 多线程与并发效率
   • 减少锁竞争（使用细粒度锁、无锁数据结构如std::atomic）。
   • 合理利用线程池避免频繁创建 / 销毁线程。
   • 示例：用std::future和std::async实现轻量并发，比原始线程更高效。
5. 最小化抽象开销
   • 避免过度封装导致的函数调用栈过深。
   • 合理使用inline关键字消除函数调用开销。
   • 示例：性能敏感的代码（如游戏物理引擎）常使用结构体（struct）而非复杂类，减少成员函数调用成本。

1.2 常见的 C++ 高性能组件 / 库举例

1. 基础数据结构
   • absl::InlinedVector（Google Abseil 库）：小数据量时使用栈内存，避免堆分配。
   • folly::fbvector（Facebook Folly 库）：优化的动态数组，内存分配策略更高效。
2. 并发组件
   • tbb::concurrent_queue（Intel TBB 库）：线程安全的无锁队列，适合高并发场景。
   • std::atomic：C++11 起内置的原子操作类型，避免锁开销。
3. 算法与数值计算
   • Eigen库：高性能线性代数库，利用 SIMD 指令（如 AVX）加速矩阵运算。
   • Google Benchmark：用于性能测试的组件，帮助量化优化效果。
4. 内存管理
   • mimalloc/jemalloc：替代系统默认的内存分配器，减少碎片并提升分配速度。
   • 自定义内存池：例如游戏引擎中为特定对象（如粒子、实体）预分配内存块。

1.3 实现高性能组件的关键工具

• 编译器优化：启用-O3（GCC/Clang）或/O2（MSVC）等优化选项，让编译器自动进行循环展开、常量传播等优化。
• 性能分析工具：用perf（Linux）、VTune（Intel）或Visual Studio Profiler定位瓶颈。
• 汇编级优化：对核心热点代码（如 inner loop）使用内联汇编或利用编译器 intrinsic 函数（如_mm256_add_ps）调用 SIMD 指令。

总之，C++ 高性能组件的核心是 “在抽象与效率间找到平衡”—— 既利用 C++ 的封装性保证代码可维护性，又通过底层优化榨干硬件性能。

二、定时器

编程中的 “定时器”（Timer）是一种用于在指定时间后执行特定任务，或按固定时间间隔重复执行任务的工具，本质上是对时间进行监控和触发操作的机制。它广泛应用于需要时间控制的场景，比如定时刷新界面、任务调度、超时处理等。

2.1 什么是用户态定时器

用户态定时器是运行在用户空间（UserSpace）的定时器机制，由应用程序主动创建和管理，用于在指定时间点触发回调函数或执行特定任务。它区别于内核态定时器（由操作系统内核管理），完全在用户进程的上下文环境中工作，是用户态程序实现时间控制逻辑的核心工具。

核心特点：

1. 运行在用户空间
   定时器的计时逻辑、触发判断等操作都在应用程序的用户态代码中完成，不依赖内核提供的定时服务（或仅用内核提供的基础时间接口，如获取当前时间）。
2. 由应用程序自主管理
   创建、启动、停止、销毁等操作完全由应用程序控制，无需陷入内核（减少内核态与用户态的切换开销）。
3. 精度与限制
   • 精度通常受应用程序调度和系统负载影响（若进程被挂起，定时器可能延迟）。
   • 无法像内核定时器那样在进程休眠时强制唤醒进程执行任务。

适用场景：

• 轻量级定时任务：如 UI 界面的倒计时、简单的周期性日志打印。
• 低精度需求场景：允许毫秒级甚至秒级误差的任务（如每隔 10 秒刷新一次数据）。
• 避免内核开销的场景：高频次但低精度的定时（如游戏中的简单动画帧更新）。

注意事项：

• CPU 占用：若轮询间隔过短（如不sleep），会导致 CPU 占用率飙升，需合理设置等待间隔。
• 进程调度影响：若应用程序被操作系统挂起（如 CPU 资源不足），用户态定时器会延迟触发，无法保证严格准时。
• 多任务协调：在多线程环境中，需注意定时器回调的线程安全（如加锁保护共享资源）。

总之，用户态定时器是应用程序在用户空间自主实现的时间控制机制，以低开销为优势，适合对精度要求不高的轻量定时场景。

代码示例：

基础轮询式定时器：

#include <iostream>
#include <chrono>
#include <thread>
#include <functional>// 轮询式定时器：等待指定毫秒后执行任务
void polling_timer(int delay_ms, const std::function<void()>& task) {// 计算目标触发时间auto target_time = std::chrono::steady_clock::now() + std::chrono::milliseconds(delay_ms);// 循环检查是否到达目标时间while (std::chrono::steady_clock::now() < target_time) {// 短暂休眠减少CPU占用std::this_thread::sleep_for(std::chrono::microseconds(100));}// 执行任务task();
}int main() {std::cout << "程序启动，3秒后触发任务..." << std::endl;// 3秒后执行任务polling_timer(3000, [](){std::cout << "定时器触发：3秒已过！" << std::endl;});return 0;
}

线程阻塞式定时器（非阻塞主线程）：

#include <iostream>
#include <thread>
#include <chrono>
#include <functional>class ThreadTimer {
private:std::thread timer_thread;bool is_running = false;public:void start(int delay_ms, const std::function<void()>& task) {if (is_running) return;is_running = true;timer_thread = std::thread([=, this]() {// 阻塞等待指定时间std::this_thread::sleep_for(std::chrono::milliseconds(delay_ms));if (is_running) {task();}is_running = false;});timer_thread.detach();}void stop() {is_running = false;}
};int main() {ThreadTimer timer;std::cout << "程序启动，2秒后触发任务..." << std::endl;timer.start(2000, [](){std::cout << "定时器触发：2秒已过！" << std::endl;});// 主线程可以继续执行其他操作for (int i = 0; i < 5; ++i) {std::cout << "主线程运行中..." << std::endl;std::this_thread::sleep_for(std::chrono::milliseconds(500));}return 0;
}

周期性定时器：

#include <iostream>
#include <thread>
#include <chrono>
#include <functional>
#include <atomic>class PeriodicTimer {
private:std::thread timer_thread;std::atomic<bool> is_running{false};public:// 启动定时器：初始延迟后，按固定间隔执行void start(int initial_delay_ms, int interval_ms, const std::function<void()>& task) {if (is_running) return;is_running = true;timer_thread = std::thread([=, this]() {// 初始延迟std::this_thread::sleep_for(std::chrono::milliseconds(initial_delay_ms));// 周期性执行while (is_running) {task();std::this_thread::sleep_for(std::chrono::milliseconds(interval_ms));}});timer_thread.detach();}void stop() {is_running = false;}
};int main() {PeriodicTimer timer;int count = 0;std::cout << "启动周期性定时器，1秒后开始，每2秒执行一次..." << std::endl;timer.start(1000, 2000, [&count]() {count++;std::cout << "第" << count << "次执行任务" << std::endl;});// 运行10秒后停止std::this_thread::sleep_for(std::chrono::seconds(10));timer.stop();std::cout << "定时器已停止" << std::endl;return 0;
}

这些定时器都运行在用户态，通过标准 C++ 库实现，不依赖内核特定的定时器 API。它们各有特点：轮询式实现简单但会阻塞当前线程；线程式不会阻塞主线程；周期性定时器适合需要重复执行的任务。

2.2 为什么要使用用户态定时器

1）为什么要在软件中使用定时器？

• 定时触发：在预设的时间点执行特定任务（如延迟一段时间后弹出提示框、定时保存文件等）。

• 周期性执行任务：按照固定时间间隔重复执行任务（如每秒刷新一次数据、每分钟检查一次网络连接等）。

2 为什么不使用Posix 定时器，而自定义定时器？

• Posix定时器系统调用的开销大，而自定义定时器则只需要clock_gettime 一种系统调用的开销。

• 定时任务数量仅受内存限制

• 可以自定义定时任务的触发逻辑，比如任务优先级调度、复杂超时策略（如指数退避）

• 跨平台兼容性需求，比如同时支持 Linux 和 Windows 的系统。

2.3 高性能用户态定时器的实现原理

2.3.1 训练营

2.3.1.1 问题解析

用户态定时器通常基于单独线程 / 进程实现，核心逻辑包括：

1. 时间源选择：使用高精度时钟（如clock_gettime(CLOCK_MONOTONIC)或std::chrono::steady_clock）获取当前时间，避免受系统时间调整影响。

2. 任务存储结构：采用最小堆（Min-Heap）或时间轮（Time Wheel） 存储任务，确保快速定位最近到期任务（时间复杂度 O (1) 或 O (logn)）。

3. 触发机制：通过轮询（Polling）或阻塞等待（Block）检测任务到期，结合线程池处理耗时操作，避免阻塞定时器线程。

2.3.1.2 模拟问答

设计高性能定时器的核心在于时间源、数据结构和执行策略的优化：

1. 时间源选择：
   使用clock_gettime(CLOCK_MONOTONIC)获取单调递增时钟，避免系统时间调整对定时器的影响。为减少系统调用开销，可采用以下策略：

   • 缓存时间：每 10ms 更新一次时间缓存，高频查询直接使用缓存值。

2. 任务存储结构：
   采用 最小堆（优先队列）存储任务，按到期时间排序：

   • 插入 / 删除：时间复杂度 O (logn)。

   • 获取最小元素：时间复杂度 O (1)。

3. 触发机制：

   • 方案 1：阻塞等待（适合低功耗场景）：
     计算最近任务的剩余时间delta，调用nanosleep(delta)阻塞等待，避免空转。

   • 方案 2：定时轮询（适合实时响应）：
     每 10ms 唤醒一次线程，检查堆顶任务是否到期，适用于高频定时器。

4. 执行策略：

   • 轻量级任务：直接在定时器线程执行（避免线程切换开销）。

   • 耗时任务：提交到线程池执行，避免阻塞定时器线程。

5. 优化细节：

   • 批量处理：每次唤醒时，一次性执行所有已到期的任务（减少唤醒次数）。
   • 延迟删除：对取消的任务标记为无效，在执行时跳过，避免频繁调整堆结构。

2.3.2 豆包的解释

高性能用户态定时器的核心目标是：在用户态环境下，以极低的资源开销（CPU / 内存）实现高精度、高并发的定时触发能力，同时避免频繁的内核态切换（减少系统调用开销）。其实现原理围绕 “高效时间管理”“低开销触发”“大规模定时器调度” 三个核心问题展开，具体可拆解为以下关键技术点：

2.3.2.1 高精度时间源的选择

定时器的精度首先依赖于底层时间源的精度。高性能定时器必须选择单调递增、高精度的时钟，避免受系统时间调整（如 NTP 同步、用户手动修改时间）的影响。

在 C++ 中，通常使用：

• std::chrono::steady_clock：单调时钟（时间只增不减），精度通常可达微秒级（μs），是用户态定时器的首选。
• 硬件级时间源（如 CPU 的 TSC 寄存器）：通过rdtsc指令直接读取 CPU 周期数，精度可达纳秒级（ns），但需处理 CPU 频率变化（如节能模式下的频率波动）。

示例（获取高精度时间戳）：

#include <chrono>
using namespace std::chrono;// 获取当前时间（微秒级）
uint64_t now_us() {return duration_cast<microseconds>(steady_clock::now().time_since_epoch()).count();
}

2.3.2.2 高效的定时器管理数据结构

当存在大量定时器（如数万甚至数十万）时，“如何快速找到即将到期的定时器” 是性能瓶颈。普通轮询（遍历所有定时器）的复杂度为 O (n)，无法满足高性能需求。需采用以下数据结构：

1. 最小堆（Min-Heap）/ 优先队列

• 原理：按定时器的 “到期时间” 排序，堆顶元素为最近即将到期的定时器。每次只需检查堆顶是否到期，无需遍历所有定时器。
• 操作复杂度：插入（O (log n)）、删除（O (log n)）、查询最近到期（O (1)）。
• 适用场景：单次触发、非周期性定时器（如 “3 秒后执行一次”）。

#include <queue>
#include <vector>// 定时器节点：到期时间+回调函数
struct Timer {uint64_t expire_us;       // 到期时间（微秒）std::function<void()> cb; // 回调任务
};// 最小堆比较器（按到期时间升序）
struct TimerCmp {bool operator()(const Timer& a, const Timer& b) {return a.expire_us > b.expire_us; // 堆顶为最小元素}
};// 定时器堆
std::priority_queue<Timer, std::vector<Timer>, TimerCmp> timer_heap;// 检查并执行到期定时器
void check_expired() {uint64_t now = now_us();// 批量处理所有到期的定时器while (!timer_heap.empty() && timer_heap.top().expire_us <= now) {timer_heap.top().cb(); // 执行回调timer_heap.pop();      // 移除已处理的定时器}
}

2. 时间轮（Time Wheel）

• 原理：将时间划分为多个 “槽位”（如每个槽代表 10ms），形成环形结构（类似时钟的刻度）。定时器根据 “到期时间” 映射到对应的槽位，只需按固定间隔（槽位时间）检查当前槽位的所有定时器。
• 优势：插入 / 删除复杂度接近 O (1)，适合大量周期性定时器（如 “每 100ms 执行一次”）。
• 多级时间轮：单级时间轮范围有限（如 8 个槽，每个 10ms，最大覆盖 80ms），多级时间轮（类似时钟的时 / 分 / 秒）可扩展范围（如二级槽代表 800ms，三级代表 8000ms 等）。

示例（单级时间轮简化逻辑）：

#include <vector>
#include <list>const int SLOT_COUNT = 60;       // 60个槽位
const int SLOT_INTERVAL_US = 100000; // 每个槽代表100ms（100,000μs）// 时间轮结构：每个槽存储该时间点到期的定时器
std::vector<std::list<Timer>> time_wheel(SLOT_COUNT);
int current_slot = 0;            // 当前指向的槽位// 计算定时器应放入的槽位
int get_slot(uint64_t expire_us) {uint64_t now = now_us();uint64_t delay_us = expire_us - now;int slot = (current_slot + delay_us / SLOT_INTERVAL_US) % SLOT_COUNT;return slot;
}// 每100ms触发一次：切换槽位并执行当前槽的定时器
void on_tick() {current_slot = (current_slot + 1) % SLOT_COUNT;// 执行当前槽的所有定时器for (auto& timer : time_wheel[current_slot]) {timer.cb();}time_wheel[current_slot].clear(); // 清空已处理的定时器
}

2.3.2.4 低开销的触发机制

高性能定时器需避免 “频繁系统调用” 和 “无效 CPU 占用”，核心是减少用户态与内核态的切换，并精准控制等待时间。

阻塞等待 + 批量处理

• 原理：计算 “最近到期定时器的剩余时间”，通过一次系统调用（如sleep_for）阻塞等待该时间，而非轮询。等待结束后，批量处理所有到期的定时器，再计算下一次等待时间。
• 优势：将多次系统调用合并为一次，大幅降低开销。

示例（结合最小堆的阻塞等待）：

void timer_loop() {while (true) {if (timer_heap.empty()) {// 无定时器时，可阻塞等待新定时器加入（需配合条件变量）std::unique_lock<std::mutex> lock(mtx);cv.wait(lock);} else {uint64_t now = now_us();uint64_t next_expire = timer_heap.top().expire_us;if (next_expire > now) {// 阻塞等待到最近的定时器到期std::this_thread::sleep_for(microseconds(next_expire - now));}// 批量处理所有到期定时器check_expired();}}
}

避免忙等待（Busy Waiting）

• 低精度场景：使用sleep_for阻塞等待，释放 CPU 资源。
• 高精度场景（如 10μs 内）：接近到期时可短暂 “忙等待”（空循环检查时间），避免sleep_for的唤醒延迟，但需控制时长（防止 CPU 占用过高）。

void precise_wait(uint64_t target_us) {uint64_t now = now_us();// 距离目标时间较远时，阻塞等待while (target_us - now > 100) { // 大于100μs时std::this_thread::sleep_for(microseconds(10));now = now_us();}// 接近目标时间时，忙等待（确保精度）while (now < target_us) {now = now_us(); // 高频检查，但时间短}
}

2.3.2.5 线程安全与并发优化

在多线程环境下，定时器的添加 / 删除 / 触发需保证线程安全，同时避免锁竞争导致的性能损耗：

• 无锁数据结构：使用 CAS（Compare-And-Swap）操作实现无锁堆或时间轮（如folly::ConcurrentHashMap）。
• 分区锁：将定时器按哈希分片，每个分片独立加锁，减少锁冲突（如 10 个分片，并发冲突概率降为 1/10）。
• 单生产者 - 单消费者模型：主线程添加定时器，专用线程处理触发，通过无锁队列（如moodycamel::ConcurrentQueue）传递任务，避免锁开销。

2.3.2.6 关键优化技巧

1. 定时器合并：多个相同周期的定时器可合并为一个，触发时批量执行所有回调（如多个 “每 1 秒执行” 的任务，合并为一个定时器）。
2. 延迟删除：标记已取消的定时器，在触发检查时统一清理，避免频繁修改堆 / 时间轮结构。
3. 缓存友好：将定时器节点按内存地址连续存储（如用std::vector而非std::list），提升 CPU 缓存命中率。
4. 避免动态内存分配：使用内存池预分配定时器节点，减少new/delete的开销。

2.3.2.7 总结

高性能用户态定时器的核心是 “精准计时 + 高效管理 + 低开销触发”：通过高精度时间源保证精度，用最小堆 / 时间轮高效管理大量定时器，以 “阻塞等待 + 批量处理” 减少系统调用，结合无锁 / 分区锁优化并发性能。这种设计在高性能服务器（如 Nginx、Redis）、游戏引擎、高频交易系统中广泛应用，可支持每秒数十万次的定时器触发，且 CPU 占用率极低。

2.4 存储定时器任务的常用数据结构

• 红⿊树：红黑树是一种自平衡的二叉搜索树，确保插入、删除、查找操作的时间复杂度为 O(log n)。使用时会将任务按执行时间作为键值插入红黑树，树的最左节点（最小值）即为下一个要执行的任务。每次检查时只需取出最左节点，判断是否到达执行时间。优点是支持动态插入和删除，适用于任务执行时间分散且随机的场景，且支持范围查询（如查找未来 10 分钟内的所有任务）；缺点是实现复杂度较高；每次插入 / 删除需维护树的平衡，开销较大；对于频繁到期的任务，需反复删除和插入根节点，效率较低。

• 最⼩堆：最小堆是一种完全二叉树，每个节点的值都小于或等于其子节点的值。根节点（堆顶）始终是最小值。使用时将任务按执行时间作为优先级构建最小堆，堆顶元素即为下一个要执行的任务。每次检查时取出堆顶元素，判断是否到期；若到期则执行，否则重新调整堆。优点是插入和删除操作的时间复杂度为 O(log n)，获取最小值（堆顶）的时间复杂度为 O(1)，适合频繁获取最早到期任务的场景；缺点是不支持高效的范围查询（如查找未来 1 小时内的所有任务）；若任务执行时间集中在某个区间，可能导致堆的调整频繁。

• 时间轮：将时间划分为固定大小的槽（Slot），每个槽维护一个链表存储到期时间相同的任务。时间轮有一个 “指针”，按固定频率（如每秒）移动到下一个槽。任务根据执行时间被映射到对应的槽中。优点是插入和删除任务的时间复杂度为 O(1)，适合高并发场景；通过分层设计（如多级时间轮）可处理大范围的时间跨度；缺点是时间精度受槽的大小限制（如槽为 1 秒，则精度最高为 1 秒）；若某个槽中的任务过多，执行效率会下降。

2.4.1 比较

在定时器实现中，存储任务的数据结构需要高效支持插入（添加新定时任务）、删除（取消已添加的任务）、查询最早到期任务（快速找到即将触发的任务）等操作。不同场景下，常用的数据结构有以下几类，各有其适用特点：

2.4.1.1 优先队列（堆，Heap）

原理:

基于最小堆（Min-Heap）实现，堆顶元素始终是最早到期的任务（按到期时间排序）。

• 插入时，将任务放入堆尾，再上浮调整维持堆结构；
• 删除时，若删除堆顶（最早到期任务），直接取出并下沉调整；若删除任意任务，需先定位（效率较低）再调整；
• 查询最早到期任务时，直接取堆顶元素。

操作效率:

• 插入：O (log n)（堆的上浮操作）；
• 删除堆顶：O (log n)（堆的下沉操作）；
• 删除任意元素：O (n)（需遍历找到元素位置）；
• 查询最早到期：O (1)（直接访问堆顶）。

优缺点:

• 优点：实现简单，适合任务数量不多、删除操作少的场景；
• 缺点：删除非堆顶元素效率低，不适合需要频繁取消任务的场景。

适用场景:

简单定时器（如单线程定时任务调度）、任务取消操作较少的场景。

2.4.1.2 平衡二叉搜索树（如红黑树、AVL 树）

原理:

以任务的到期时间为键，将任务存储在有序的平衡二叉树中（如 C++ 的std::set基于红黑树实现）。

• 树中元素按到期时间有序排列，左子树元素到期时间小于根节点，右子树大于根节点；
• 插入、删除时通过旋转维持树的平衡，保证操作效率；
• 最早到期任务为树的最左节点（最小值）。

操作效率:

• 插入、删除、查询最早到期任务：均为 O (log n)（平衡树的特性保证）。

优缺点:

• 优点：支持高效的插入、删除（包括任意任务）和查询，操作均衡；
• 缺点：实现较复杂，内存开销略大。

适用场景:

需要频繁插入、删除任务的场景（如动态调整定时任务），例如分布式系统中的超时管理。

2.4.1.3 时间轮（Time Wheel）

原理:

一种环形数组结构，将时间划分为固定粒度的 “槽”（如每个槽代表 10ms），每个槽存储该时间间隔内到期的任务列表。

• 插入任务时，根据任务到期时间计算其所属的槽，加入槽的任务列表；
• 随着时间推移（由一个 “指针” 指示当前槽），依次处理当前槽的所有任务；
• 对于超时时间超过单轮最大时间的任务，通过 “轮次计数”（如任务需要经过 3 轮才到期）实现。

操作效率:

• 插入、删除：O (1)（定位槽后直接操作链表）；
• 查询最早到期：O (1)（当前指针指向的槽即为即将处理的任务）。

优缺点:

• 优点：性能极高，适合大量任务且超时时间分布均匀的场景；
• 缺点：时间粒度固定，若粒度太小则数组过大（内存浪费），若粒度太大则精度不足；需多级时间轮（如秒级、分钟级、小时级）解决大超时时间问题。

适用场景:

高性能网络框架（如 Netty、Libevent）中的定时器管理，需要处理海量定时任务（如 TCP 连接超时检测）。

2.4.1.4 跳表（Skip List）

原理:

一种有序链表的优化结构，通过增加多层 “索引” 实现快速查询。以任务到期时间为键，节点按时间有序排列，每层索引随机跳过部分节点。

• 插入时，先定位插入位置（通过索引快速跳过无关节点），再插入节点并随机建立索引；
• 删除时，同理定位节点后删除其所有层级的索引；
• 最早到期任务为链表的头节点。

操作效率:

• 插入、删除、查询：平均 O (log n)，最坏 O (n)（但概率极低）。

优缺点:

• 优点：实现比平衡树简单，并发场景下加锁成本低（可局部锁）；
• 缺点：索引占用额外内存，随机化特性可能导致性能不稳定。

适用场景:

需要并发操作的定时器（如 Redis 的zset可用于实现定时器，底层基于跳表）。

总结：数据结构选择依据

场景需求	推荐数据结构
简单场景，任务少、删除少	优先队列（堆）
频繁插入删除，需动态调整	平衡二叉搜索树
海量任务，高性能、低延迟	时间轮（多级）
并发场景，需高效锁机制	跳表

实际应用中，复杂定时器可能结合多种结构（如多级时间轮 + 堆），兼顾性能与灵活性。

三、线程池

3.1 什么是线程池？

线程池（Thread Pool）是一种线程管理机制，它预先创建一定数量的线程并维护在一个 “池” 中，当有任务需要处理时，直接从池中分配空闲线程执行任务，任务完成后线程不会销毁，而是返回池中等待下一个任务。这种模式避免了频繁创建和销毁线程的开销，提高了系统性能和资源利用率。

线程池是一种设计模式。

3.1.1 如果没有线程池会怎么处理任务？

在没有线程池的时代，处理并发任务通常采用 “即时创建线程”或“单线程循环处理” 的模式，这些方式在简单场景下可行，但在高并发或复杂场景中存在明显局限。以下是具体的处理方式及问题：

3.1.1.1 最直接的方式：为每个任务创建一个新线程

当有任务需要处理时（比如服务器收到一个客户端请求），立即创建一个新线程，让线程执行任务，任务完成后线程自动销毁。
示例伪代码：

// 伪代码：收到请求后创建新线程处理
while (true) {客户端请求 = 接收请求();// 为每个请求创建新线程   新线程 = 线程(处理请求函数, 客户端请求);新线程.start();
}

这种方式的问题：

1. 资源开销大：线程创建需要分配栈内存（通常几 MB）、内核数据结构（如 PCB），销毁时需要回收资源，这些操作耗时（毫秒级），如果任务数量多（比如每秒上万请求），线程创建 / 销毁的开销会严重占用 CPU 和内存。
2. 线程数量失控：系统能同时运行的线程数有限（受 CPU 核心数、内存限制），过多线程会导致：
   • 上下文切换频繁：CPU 在多个线程间切换，每次切换需要保存 / 恢复寄存器状态，耗时（微秒级），降低实际工作效率。
   • 内存耗尽：每个线程占用的栈内存累积，可能导致 OOM（内存溢出）。
3. 稳定性差：突发大量任务时，线程数量暴增，可能直接导致程序或系统崩溃。

3.1.1.2 简单优化：限制线程总数（“线程池的雏形”）

为了避免线程数量失控，手动维护一个 “线程池” 的雏形：预先创建固定数量的线程，让它们循环从任务队列中取任务执行，任务完成后不销毁线程，而是继续等待新任务。
示例伪代码：

// 伪代码：预先创建5个线程，循环处理任务队列
任务队列 = 空队列;
// 预先创建5个线程
for (int i = 0; i < 5; i++) {线程 = 线程(循环处理函数);线程.start();
}// 线程的循环处理函数
void 循环处理函数() {while (true) {任务 = 从任务队列取任务(); // 若无任务则阻塞等待执行任务(任务);}
}// 接收请求时，将任务放入队列
while (true) {客户端请求 = 接收请求();任务队列.添加(客户端请求);
}

这种方式的问题：

• 线程数量固定，无法应对 “任务量突增” 的场景（比如 5 个线程都在忙碌，新任务只能排队，响应变慢）。
• 缺乏完善的管理机制（如动态调整线程数、任务拒绝策略、线程空闲回收等），需要手动实现所有细节，容易出错。

3.1.1.3 单线程处理（非并发，但早期简单场景常用）

在任务量少、对并发无要求的场景（比如早期简单的单机程序），直接用单线程循环处理任务：一个线程依次接收任务、执行任务，完成后再处理下一个。
示例：早期的简单服务器，一次只能处理一个客户端请求，处理完才能接收下一个。

问题：

• 完全不支持并发，效率极低，无法应对多个任务同时到来的场景（比如多个客户端同时连接服务器时，后面的请求会被阻塞直到前面的完成）。

3.1.1.4 总结：没有线程池时的核心痛点

1. 效率低：线程创建 / 销毁开销大，单线程处理无法利用多核 CPU。
2. 资源失控：线程数量可能无限制增长，导致系统崩溃。
3. 扩展性差：无法动态适应任务量变化（固定线程数应对突发任务能力弱）。
4. 开发复杂：手动管理线程和任务队列需要处理同步（如锁、条件变量）、阻塞等问题，容易出现死锁、竞态条件等 bug。

正因为这些问题，线程池作为一种 “池化技术”（类似连接池、内存池）被广泛应用，通过复用资源、控制总量、动态调整，解决了早期并发处理的痛点。

3.2 为什么使用线程池？

• 减少线程创建开销：

  • 传统线程模型：每个任务创建一个线程，线程创建 / 销毁耗时约 10-100 微秒（取决于系统）。

  • 线程池模型：线程预先创建，重复使用，避免频繁系统调用。

• 控制资源消耗：

  • 无限制创建线程会导致 CPU、内存资源耗尽（如 100 万线程需约 40GB 内存）。

  • 线程池通过固定线程数量（如 CPU 核心数 ×2），防止资源过载。

• 提高响应速度：

  • 任务提交后直接由空闲线程执行，无需等待线程创建。

3.3 线程池的原理

3.3.1 概述

线程池的核心组件如下：

• 任务队列（Job Queue）：

  • 存储待执行的任务（如std::queue或std::deque），支持线程安全的入队 / 出队操作。

• 工作线程（Worker Threads）：

  • 预先创建的线程集合，不断从任务队列获取任务并执行。

• 管理器（Manager）：

  • 负责线程池的生命周期管理（初始化、销毁）、线程数量调整等。

线程池的常用工作流程如下：

1. 提交任务到任务队列

2. 通过条件变量唤醒空闲线程获取任务并执行

3. 若无空闲线程，且队列未满，任务则排队等待，否则执行拒绝策略。

线程池的关键参数：

• 核心线程数（Core Pool Size）：线程池长期保持的线程数量，即使线程空闲也不会销毁。

• 最大线程数（Maximum Pool Size）：线程池允许创建的最大线程数量，当任务队列满时会创建临时线程

• 任务队列容量：有界队列（如std::vector）可防止资源耗尽，无界队列可能导致 OOM。

• 线程存活时间：临时线程空闲时的存活时间，超时后会被销毁。

3.3.2 线程池的细节

线程池的核心原理是通过预先创建一批线程并复用它们处理多个任务，同时通过任务队列和管理机制实现对线程和任务的高效调度。其工作流程可拆解为以下几个核心环节：

3.3.2.1 核心组成与初始化

线程池在初始化时会创建并维护几个关键组件：

1. 工作线程（Worker Threads）
   预先创建的一批线程（数量由核心线程数决定），这些线程会进入一个无限循环：不断从任务队列中获取任务并执行，执行完成后不会销毁，而是继续等待下一个任务。
2. 任务队列（Task Queue）
   一个阻塞队列（如LinkedBlockingQueue），用于存放待执行的任务。当所有工作线程都在忙碌时，新提交的任务会暂时进入队列等待。
3. 线程池管理器
   负责监控线程池状态（如当前线程数、活跃线程数、任务队列长度），并根据状态动态调整线程数量（创建新线程或销毁空闲线程）。
4. 核心参数
   • 核心线程数（corePoolSize）：长期保留的最小线程数，即使空闲也不销毁（除非设置了超时参数）。
   • 最大线程数（maximumPoolSize）：允许创建的线程总数上限。
   • 空闲线程存活时间（keepAliveTime）：超出核心线程数的临时线程，空闲超时后会被销毁。
   • 拒绝策略：当任务队列满且线程数达最大值时，处理新任务的策略（如丢弃、抛异常等）。

3.3.2.2 任务处理流程（核心逻辑）

当外部提交一个任务到线程池时，线程池按以下逻辑处理：

1. 判断当前线程数是否小于核心线程数
   • 如果是：创建一个新的工作线程，直接执行该任务。
   • 如果否：进入下一步。
2. 判断任务队列是否未满
   • 如果未满：将任务放入队列等待，已有工作线程会从队列中取任务执行。
   • 如果已满：进入下一步。
3. 判断当前线程数是否小于最大线程数
   • 如果是：创建临时线程执行该任务（这些线程在空闲超时后会被销毁）。
   • 如果否：触发拒绝策略（如丢弃任务、让提交任务的线程自己执行等）。

示例：
假设核心线程数 = 3，最大线程数 = 5，任务队列容量 = 10。

• 前 3 个任务：直接创建 3 个核心线程执行。
• 第 4~13 个任务：放入队列等待（队列容量 10）。
• 第 14~15 个任务：队列已满，创建 2 个临时线程执行（总线程数达 5）。
• 第 16 个任务：队列满且线程数达最大值，触发拒绝策略。

3.3.2.3 线程的生命周期管理

1. 核心线程：默认情况下会一直存活，即使空闲（避免频繁创建）。某些线程池实现（如 Java 的ThreadPoolExecutor）可通过allowCoreThreadTimeOut(true)设置核心线程的超时销毁。
2. 临时线程：当任务队列满且核心线程忙碌时创建，任务量下降后，若临时线程空闲时间超过keepAliveTime，会被线程池主动销毁，最终线程数回落至核心线程数。

3.3.2.4 阻塞与唤醒机制

线程池通过阻塞队列和条件变量实现线程的高效等待与唤醒：

• 当任务队列为空时，工作线程会阻塞在 “获取任务” 的操作上（释放 CPU 资源）。
• 当新任务提交到队列时，阻塞队列会唤醒一个空闲线程来执行任务。
• 当任务队列满时，提交任务的线程可能被阻塞（或触发拒绝策略），直到队列有空闲位置。

3.3.2.5 总结

线程池的本质是 “线程复用 + 任务缓冲 + 动态调度”：

3.3.2.6 代码示例

#include <iostream>
#include <vector>
#include <queue>
#include <thread>
#include <mutex>
#include <condition_variable>
#include <future>
#include <functional>
#include <chrono>
#include <random>// 线程池类
class ThreadPool {
public:// 构造函数：创建指定数量的工作线程explicit ThreadPool(size_t thread_count) : stop(false) {// 创建工作线程for (size_t i = 0; i < thread_count; ++i) {workers.emplace_back([this] {// 工作线程循环：不断从任务队列获取任务并执行while (true) {std::function<void()> task;// 加锁获取任务{std::unique_lock<std::mutex> lock(this->mtx);// 等待直到有任务或线程池停止this->cv.wait(lock, [this] { return this->stop || !this->tasks.empty(); });// 如果线程池已停止且任务队列为空，则退出if (this->stop && this->tasks.empty()) {return;}// 从队列获取任务task = std::move(this->tasks.front());this->tasks.pop();}// 执行任务（此时已解锁，其他线程可以获取任务）task();}});}}// 析构函数：停止所有工作线程~ThreadPool() {{std::unique_lock<std::mutex> lock(mtx);stop = true; // 设置停止标志}cv.notify_all(); // 唤醒所有等待的线程// 等待所有工作线程完成for (std::thread& worker : workers) {worker.join();}}// 提交任务并返回future对象（支持任意参数的函数）template<class F, class... Args>auto submit(F&& f, Args&&... args) -> std::future<typename std::result_of<F(Args...)>::type> {// 确定任务返回类型using return_type = typename std::result_of<F(Args...)>::type;// 包装任务为shared_ptr，以便能拷贝到lambda中auto task = std::make_shared< std::packaged_task<return_type()> >(std::bind(std::forward<F>(f), std::forward<Args>(args)...));// 获取future对象，用于获取任务结果std::future<return_type> res = task->get_future();// 将任务加入队列{std::unique_lock<std::mutex> lock(mtx);// 如果线程池已停止，不能提交新任务if (stop) {throw std::runtime_error("submit on stopped ThreadPool");}tasks.emplace([task]() { (*task)(); });}cv.notify_one(); // 唤醒一个等待的工作线程return res;}private:std::vector<std::thread> workers;      // 工作线程容器std::queue<std::function<void()>> tasks; // 任务队列std::mutex mtx;                        // 保护任务队列的互斥锁std::condition_variable cv;            // 用于线程同步的条件变量bool stop;                             // 线程池停止标志
};// 示例任务1：无返回值
void print_task(int id) {std::this_thread::sleep_for(std::chrono::milliseconds(100)); // 模拟耗时操作std::cout << "Task " << id << " executed by thread " << std::this_thread::get_id() << std::endl;
}// 示例任务2：有返回值
int sum_task(int a, int b) {std::this_thread::sleep_for(std::chrono::milliseconds(50));return a + b;
}int main() {// 创建线程池，使用4个工作线程ThreadPool pool(4);std::cout << "ThreadPool created with 4 threads" << std::endl;// 提交一批无返回值的任务for (int i = 0; i < 8; ++i) {pool.submit(print_task, i);}// 提交一批有返回值的任务std::vector<std::future<int>> results;for (int i = 0; i < 5; ++i) {results.emplace_back(pool.submit(sum_task, i, i * 2));}// 获取并打印有返回值任务的结果for (auto& fut : results) {std::cout << "Sum result: " << fut.get() << std::endl;}// 线程池会在析构时自动停止return 0;
}

四、连接池

4.1 什么是连接池

连接池（Connection Pool）是一种预创建并复用资源连接的设计模式，主要用于优化数据库、网络通信等场景中 “连接建立 / 销毁” 的高昂开销，广泛用于服务器程序中。

其主要工作方式是，预先创建好和数据库等资源的连接，当有应用需要连接数据库时，从连接池中直接获取已有的连接，使用完毕后再将其归还给连接池，避免了和数据库等资源频繁创建销毁连接的资源消耗。

4.2 为什么要使用连接池

传统 “即用即创建” 的连接模式存在明显缺陷：

• 开销大：建立数据库连接需经过 TCP 握手、用户认证、权限校验等步骤，单次耗时可达10~100 毫秒，高频操作下性能损耗显著。

• 资源有限：数据库通常限制最大连接数（如 MySQL 默认 151 个），无限制创建连接会导致 “连接耗尽” 错误。

• 稳定性差：频繁创建 / 销毁连接可能引发服务端内存碎片、句柄泄露等问题。

连接池通过预创建 + 复用连接，将单次连接的 “高成本” 分摊到多个任务中，同时控制总连接数，解决上述问题。

4.3 连接池的工作原理

连接池的核心组件如下:

• 连接池容器：存储可用连接的队列（如BlockingQueue），支持线程安全的获取和归还。

• 连接工厂：负责创建新连接（如DriverManager.getConnection()），包含连接参数（URL、用户名、密码等）。

• 连接管理器：监控连接状态（空闲 / 占用）、回收超时连接、检测连接健康度（如心跳检测）。

• 配置参数：核心连接数、最大连接数、空闲超时时间、等待超时时间等。

工作流程如下：

初始化阶段 ──> 创建核心数量的连接，放入连接池│
任务请求 ──> 获取连接 ─┬─> 有空闲连接：直接分配│                 ├─> 无空闲连接且未达最大连接数：创建新连接│                 └─> 无空闲连接且达最大连接数：等待超时（或执行拒绝策略）│
任务执行 ──> 使用连接处理业务（如SQL查询）│
任务完成 ──> 归还连接到池（而非关闭），标记为“空闲”│
维护阶段 ──> 定期回收超时空闲连接、检测连接有效性

4.4 代码示例

#include <iostream>
#include <vector>
#include <queue>
#include <mutex>
#include <condition_variable>
#include <chrono>
#include <memory>
#include <stdexcept>// 模拟数据库连接类
class Connection {
private:int connId; // 连接IDbool isUsed; // 是否正在使用public:// 构造函数Connection(int id) : connId(id), isUsed(false) {// 模拟创建连接的耗时操作std::this_thread::sleep_for(std::chrono::milliseconds(100));std::cout << "创建连接 " << connId << std::endl;}// 析构函数~Connection() {std::cout << "关闭连接 " << connId << std::endl;}// 模拟执行SQL查询void executeQuery(const std::string& sql) {if (!isUsed) {throw std::runtime_error("连接未被正确获取，无法执行查询");}// 模拟执行SQL的耗时std::this_thread::sleep_for(std::chrono::milliseconds(50));std::cout << "连接 " << connId << " 执行: " << sql << std::endl;}// 标记连接状态void setUsed(bool used) { isUsed = used; }bool getUsed() const { return isUsed; }int getId() const { return connId; }
};// 连接池类
class ConnectionPool {
private:std::queue<std::shared_ptr<Connection>> idleConnections; // 空闲连接队列std::vector<std::shared_ptr<Connection>> allConnections; // 所有连接（包括正在使用的）std::mutex mtx; // 互斥锁std::condition_variable cv; // 条件变量int maxConnections; // 最大连接数bool isRunning; // 连接池是否运行public:// 构造函数：初始化连接池ConnectionPool(int maxConn) : maxConnections(maxConn), isRunning(true) {if (maxConnections <= 0) {throw std::invalid_argument("最大连接数必须大于0");}// 预先创建指定数量的连接for (int i = 0; i < maxConnections; ++i) {auto conn = std::make_shared<Connection>(i);idleConnections.push(conn);allConnections.push_back(conn);}std::cout << "连接池初始化完成，最大连接数: " << maxConnections << std::endl;}// 析构函数：关闭所有连接~ConnectionPool() {{std::unique_lock<std::mutex> lock(mtx);isRunning = false;}cv.notify_all(); // 唤醒所有等待连接的线程std::cout << "连接池开始关闭..." << std::endl;// 清空连接队列（实际应用中可能需要等待所有连接归还）while (!idleConnections.empty()) {idleConnections.pop();}allConnections.clear();std::cout << "连接池已关闭" << std::endl;}// 获取连接（超时时间单位：毫秒）std::shared_ptr<Connection> getConnection(int timeoutMs = 3000) {std::unique_lock<std::mutex> lock(mtx);// 等待空闲连接或连接池关闭，最多等待timeoutMs毫秒bool hasConnection = cv.wait_for(lock, std::chrono::milliseconds(timeoutMs), [this]() { return !isRunning || !idleConnections.empty(); });// 如果连接池已关闭或超时未获取到连接if (!hasConnection || !isRunning) {throw std::runtime_error("获取连接超时或连接池已关闭");}// 获取一个空闲连接auto conn = idleConnections.front();idleConnections.pop();conn->setUsed(true);std::cout << "获取连接 " << conn->getId() << "，当前空闲连接数: " << idleConnections.size() << std::endl;return conn;}// 归还连接void releaseConnection(std::shared_ptr<Connection> conn) {if (!conn) {return;}std::unique_lock<std::mutex> lock(mtx);// 验证连接是否属于当前连接池bool isPoolConnection = false;for (const auto& c : allConnections) {if (c->getId() == conn->getId()) {isPoolConnection = true;break;}}if (!isPoolConnection) {throw std::invalid_argument("归还的连接不属于此连接池");}// 标记为空闲并放回队列conn->setUsed(false);idleConnections.push(conn);std::cout << "归还连接 " << conn->getId() << "，当前空闲连接数: " << idleConnections.size() << std::endl;cv.notify_one(); // 唤醒一个等待连接的线程}// 获取当前空闲连接数int getIdleCount() {std::lock_guard<std::mutex> lock(mtx);return idleConnections.size();}
};// 测试函数：模拟多线程使用连接池
void testConnectionPool(ConnectionPool& pool, int threadId) {try {// 获取连接auto conn = pool.getConnection();// 模拟使用连接执行查询std::string sql = "SELECT * FROM test_table WHERE thread_id = " + std::to_string(threadId);conn->executeQuery(sql);// 模拟业务处理耗时std::this_thread::sleep_for(std::chrono::milliseconds(100 + threadId * 20));// 归还连接pool.releaseConnection(conn);}catch (const std::exception& e) {std::cerr << "线程 " << threadId << " 出错: " << e.what() << std::endl;}
}int main() {try {// 创建连接池，最大连接数为3ConnectionPool pool(3);// 创建5个线程模拟并发访问std::vector<std::thread> threads;for (int i = 0; i < 5; ++i) {threads.emplace_back(testConnectionPool, std::ref(pool), i);}// 等待所有线程完成for (auto& t : threads) {t.join();}std::cout << "所有线程执行完毕，当前空闲连接数: " << pool.getIdleCount() << std::endl;}catch (const std::exception& e) {std::cerr << "错误: " << e.what() << std::endl;return 1;}return 0;
}

五、内存池

5.1 什么是内存池

内存池（Memory Pool）是一种预分配、复用内存的内存管理技术，其核心思想是提前向操作系统申请一块或多块连续的内存区域，在程序运行过程中，直接从这些预分配的内存中分配 / 释放内存，而非频繁向操作系统申请 / 归还内存。

5.2 为什么要使用内存池

传统的内存分配（如 C 语言的malloc/free、C++ 的new/delete）直接向操作系统申请内存，存在以下明显缺陷：

1. 系统调用开销大：malloc/free本质是系统调用，需要切换用户态和内核态，频繁调用会显著增加性能开销（尤其在高频内存操作场景中）；而使用内存池，只需要在开始时一次性申请大片内存，后续从这些预分配的内存中获取释放内存则不需要系统调用。

2. 内存碎片严重：频繁分配 / 释放不同大小的内存块，会导致内存空间被分割成大量不连续的 “碎片”，即使总空闲内存足够，也可能因碎片无法分配连续内存块；内存池则可以根据系统使用内存的方式，自定义合适的内存分配和回收算法。

3. 线程安全问题：多线程环境下，malloc/free通常需要加锁保证线程安全，锁竞争会进一步降低效率；内存池则可以设计为线程安全。

4. 缺乏监控与控制：无法灵活限制内存使用量，也难以追踪内存泄漏或过度分配问题；内存池则可以精确控制和追踪堆内存的操作。

5.3 内存池的工作原理

内存池的核心流程可分为初始化、分配、释放、销毁四个阶段：

1. 初始化：程序启动时，内存池根据预设策略（如预估所需内存大小、块数量）向操作系统申请一块或多块.0刚好连续内存（称为 “内存池主体”），并将其分割为若干个 “内存块”（可固定大小或动态调整），同时维护一个 “空闲块列表” 记录未使用的内存块。

2. 分配内存：当程序需要内存时，内存池从 “空闲块列表” 中查找合适的内存块（如大小匹配的块），标记为 “已使用” 并返回给程序，无需向操作系统申请新内存。

3. 释放内存：当程序释放内存时，内存池将该内存块标记为 “空闲”，重新加入 “空闲块列表”（而非直接归还给操作系统），供后续分配复用。

4. 销毁：程序结束或内存池不再使用时，将预分配的内存整体归还给操作系统。

5.4 内存池常用的分配回收算法

固定大小内存池（Fixed-Size Memory Pool）

• 特点：内存池内的所有内存块大小相同（如每次分配 128 字节的块）。

• 工作方式：初始化时按固定大小分割内存，分配时直接返回一个块，释放时放回空闲列表。

• 优势：分配 / 释放效率极高（无需计算大小，直接取块），几乎无碎片。

• 适用场景：需要频繁创建 / 销毁同类型对象（如链表节点、网络数据包）。

可变大小内存池（Variable-Size Memory Pool）

• 特点：支持分配不同大小的内存块（如 16 字节、32 字节、64 字节等，通常按 2 的幂划分）。

• 工作方式：内存池包含多个 “子池”，每个子池管理一种固定大小的内存块（如子池 1 管理 16 字节块，子池 2 管理 32 字节块）。分配时根据所需大小匹配对应子池，从子池中取块。

• 优势：兼顾灵活性和效率，既能支持不同大小的内存需求，又避免了直接调用malloc的开销。

• 适用场景：内存需求大小不固定，但范围有限的场景（如字符串处理、结构体分配）。

对象池（Object Pool）

• 特点：专为某一特定类型的对象设计（如Socket对象、数据库连接对象），本质是固定大小内存池的 “对象化” 封装。
• 工作方式：预先创建一定数量的对象实例，存储在池中；需要时从池内获取对象（而非重新new），使用完毕后放回池内（而非delete）。
• 优势：避免频繁构造 / 析构对象的开销（尤其对象构造 / 析构复杂时），且可限制对象最大数量（防止资源耗尽）。
• 适用场景：对象创建成本高、生命周期短且频繁复用的场景（如 Web 服务器的HTTP连接对象）。

5.5 代码示例

#include <iostream>
#include <cstdlib>
#include <mutex>
#include <vector>// 内存池类：管理固定大小的内存块
template <typename T, size_t BlockSize = 1024>
class MemoryPool {
private:// 内存块节点结构（用于链接空闲内存块）struct Block {Block* next; // 指向链表中的下一个空闲块};public:// 构造函数MemoryPool() : free_blocks(nullptr) {// 预先分配一块内存（包含BlockSize个T类型大小的块）allocateBlock();}// 析构函数：释放所有分配的内存块~MemoryPool() {// 遍历所有内存块并释放for (void* block : all_blocks) {std::free(block);}}// 禁用拷贝构造和赋值操作（避免内存管理问题）MemoryPool(const MemoryPool&) = delete;MemoryPool& operator=(const MemoryPool&) = delete;// 分配一个T类型大小的内存块void* allocate() {std::lock_guard<std::mutex> lock(mtx); // 线程安全// 如果没有空闲块，分配新的内存块if (!free_blocks) {allocateBlock();}// 从空闲链表中取出一个块Block* block = free_blocks;free_blocks = block->next;return block;}// 释放一个内存块（将其放回空闲链表）void deallocate(void* ptr) {if (!ptr) return;std::lock_guard<std::mutex> lock(mtx); // 线程安全// 将释放的块插入空闲链表头部Block* block = static_cast<Block*>(ptr);block->next = free_blocks;free_blocks = block;}// 为T类型对象构造实例（结合placement new）template <typename... Args>T* construct(Args&&... args) {void* mem = allocate();return new (mem) T(std::forward<Args>(args)...); //  placement new}// 销毁T类型对象（手动调用析构函数）void destroy(T* ptr) {if (ptr) {ptr->~T(); // 调用析构函数deallocate(ptr); // 释放内存块}}private:// 分配一个新的内存块（包含BlockSize个T大小的单元）void allocateBlock() {// 计算单个内存块的大小（至少要能容纳Block结构）size_t block_size = std::max(sizeof(T), sizeof(Block));// 分配一整块内存，可容纳BlockSize个块void* block = std::malloc(block_size * BlockSize);if (!block) {throw std::bad_alloc(); // 内存分配失败}// 将新分配的内存块加入总块列表all_blocks.push_back(block);// 将新内存块分割成多个小单元，链接成空闲链表Block* first = static_cast<Block*>(block);Block* current = first;for (size_t i = 1; i < BlockSize; ++i) {current->next = static_cast<Block*>(static_cast<char*>(block) + i * block_size);current = current->next;}current->next = nullptr; // 链表末尾// 将新的空闲链表连接到现有链表free_blocks = first;}Block* free_blocks;       // 空闲内存块链表std::vector<void*> all_blocks; // 所有分配的内存块（用于析构时释放）std::mutex mtx;           // 互斥锁，保证线程安全
};// 测试用的类
class TestObject {
private:int id;
public:TestObject(int id) : id(id) {std::cout << "创建TestObject " << id << std::endl;}~TestObject() {std::cout << "销毁TestObject " << id << std::endl;}int get_id() const { return id; }
};int main() {try {// 创建内存池，每个块大小为1024，存储TestObjectMemoryPool<TestObject> pool;// 从内存池分配对象TestObject* obj1 = pool.construct(1);TestObject* obj2 = pool.construct(2);TestObject* obj3 = pool.construct(3);std::cout << "obj1 id: " << obj1->get_id() << std::endl;std::cout << "obj2 id: " << obj2->get_id() << std::endl;std::cout << "obj3 id: " << obj3->get_id() << std::endl;// 释放对象pool.destroy(obj1);pool.destroy(obj2);// 再次分配（会复用之前释放的内存）TestObject* obj4 = pool.construct(4);std::cout << "obj4 id: " << obj4->get_id() << std::endl;pool.destroy(obj3);pool.destroy(obj4);}catch (const std::exception& e) {std::cerr << "错误: " << e.what() << std::endl;return 1;}return 0;
}