# 对象池模式

为什么需要对象池？

在实际开发中，我们经常会遇到这样的场景：

-  **数据库连接**：创建和销毁连接的开销很大
-  **线程管理**：频繁创建和销毁线程影响性能
-  **大对象分配**：某些对象初始化成本高昂
-  **内存碎片**：频繁的内存分配导致内存碎片

对象池模式（Object Pool Pattern）通过**预先创建并复用对象**，避免了频繁的创建和销毁操作，显著提升系统性能。

### 对象池的核心思想

对象池就像一个"对象仓库"：

1. **预创建**：提前创建一批对象放入池中
2. **借用**：需要时从池中取出对象使用
3. **归还**：使用完毕后归还到池中，而不是销毁
4. **复用**：下次需要时继续使用同一个对象

## 对象池模式的基本实现

### 核心设计思路

对象池的实现需要考虑以下关键要素：

1. **对象存储**：使用容器（如 `std::vector`）存储预创建的对象
2. **状态标记**：每个对象需要标记是否正在使用
3. **获取机制**：找到第一个可用对象并标记为"使用中"
4. **归还机制**：重置对象状态并标记为"可用"

### 最简单的对象池

基础实现包含三个核心操作：

```cpp
template<typename T>
class SimpleObjectPool {
public:
    SimpleObjectPool(size_t size) {
        // 预创建指定数量的对象
        for (size_t i = 0; i < size; ++i) {
            pool_.push_back(std::make_unique<T>(i));
        }
    }

    // 获取对象：遍历查找可用对象
    T* acquire() {
        for (auto& obj : pool_) {
            if (!obj->isInUse()) {
                obj->setInUse(true);
                return obj.get();
            }
        }
        throw std::runtime_error("对象池已满");
    }

    // 归还对象：重置状态并标记为可用
    void release(T* obj) {
        if (obj) {
            obj->reset();      // 清理对象状态
            obj->setInUse(false);
        }
    }

private:
    std::vector<std::unique_ptr<T>> pool_;
};
```

**设计说明**：

-  **预创建策略**：在构造函数中一次性创建所有对象，避免运行时创建开销
-  **线性查找**：`acquire()` 使用简单的线性查找，对于小规模池（< 100 个对象）性能足够
-  **裸指针返回**：返回裸指针简单直接，但需要用户记得归还（这是主要缺陷）

**基础版本的三大问题**：

1. ❌ **不是线程安全的**：多线程环境下 `isInUse()` 检查和 `setInUse()` 设置之间存在竞态窗口
2. ❌ **容易忘记归还**：手动调用 `release()` 容易遗漏，尤其在异常路径中
3. ❌ **没有自动扩容**：池满时直接抛异常，缺乏灵活性

### 为什么需要改进？

在生产环境中，基础版本的问题会导致：

-  **资源泄漏**：忘记归还导致对象永久占用
-  **并发错误**：多线程竞争同一对象导致数据损坏
-  **服务降级**：池满时无法动态调整导致请求失败

接下来我们将通过 RAII 和线程安全设计来解决这些问题

## RAII 风格的对象池

### RAII 原则在对象池中的应用

**RAII（Resource Acquisition Is Initialization）** 是 C++ 中最重要的资源管理原则：资源的生命周期与对象的生命周期绑定。在对象池场景中，我们希望：

1. **获取即绑定**：从池中取出对象时，自动绑定到一个 RAII 包装器
2. **离开即归还**：包装器销毁时，自动将对象归还给池
3. **异常安全**：无论正常返回还是异常退出，都能正确归还

### 核心设计：自定义删除器

关键思想是利用 `std::unique_ptr` 的**自定义删除器**功能：

```cpp
// 返回带自定义删除器的智能指针
auto acquire() {
    // 找到可用对象
    T* obj = findAvailableObject();

    // 创建归还逻辑的删除器
    auto deleter = [this](T* ptr) {
        this->release(ptr);  // 归还而非删除
    };

    // 返回智能指针（删除时会调用 deleter）
    return std::unique_ptr<T, decltype(deleter)>(obj, deleter);
}
```

**工作原理**：

1. `acquire()` 返回一个智能指针
2. 智能指针存储了一个自定义删除器（lambda 函数）
3. 当智能指针销毁时，调用删除器而非 `delete`
4. 删除器将对象归还到池中

### 简化的实现示例

```cpp
template<typename T>
class ObjectPool {
public:
    // 返回 RAII 包装的对象
    std::unique_ptr<T, std::function<void(T*)>> acquire() {
        T* obj = findAvailableObject();

        // 自定义删除器：归还对象而非销毁
        auto deleter = [this](T* ptr) {
            ptr->reset();           // 清理状态
            ptr->setInUse(false);   // 标记可用
        };

        return {obj, deleter};
    }
};
```

**使用方式**：

```cpp
{
    auto conn = pool.acquire();     // 获取对象
    conn->query("SELECT ...");      // 使用对象
}   // 离开作用域，自动归还
```

### RAII 的三大优势

**1. 异常安全保证**

无论函数如何退出（正常返回或异常），对象都能正确归还：

```cpp
void processData() {
    auto conn = pool.acquire();
    conn->execute("BEGIN");

    if (someError) {
        throw std::runtime_error("Error");  // 异常退出
    }

    conn->execute("COMMIT");
}   // 无论正常还是异常，conn 都会自动归还
```

**2. 自动资源管理**

编译器负责调用析构函数，无需人工干预：

```cpp
// ❌ 手动管理：容易出错
auto* conn = pool.acquire();
try {
    doWork(conn);
    pool.release(conn);  // 容易忘记
} catch (...) {
    pool.release(conn);  // 需要在每个退出路径调用
    throw;
}

// ✅ RAII：自动管理
{
    auto conn = pool.acquire();
    doWork(conn.get());
}   // 自动归还
```

**3. 接口简洁性**

用户无需关心资源释放细节，专注业务逻辑：

```cpp
// 就像使用普通智能指针一样简单
auto conn = pool.acquire();
conn->query("SELECT * FROM users");
// 完事，无需额外操作
```

### 设计权衡

**使用 `std::function` 的代价**：

-  **优点**：灵活，可以存储任意可调用对象
-  **缺点**：有运行时开销（类型擦除、堆分配）

**优化方案**（高性能场景）：

对于性能敏感的场景，可以避免 `std::function`：

```cpp
// 使用模板避免 std::function 的开销
template<typename Deleter>
std::unique_ptr<T, Deleter> acquire() {
    auto deleter = [this](T* ptr) { release(ptr); };
    return {findAvailableObject(), deleter};
}
```

但这会让返回类型更复杂，需要在易用性和性能间权衡。

## 线程安全的对象池

### 多线程环境下的挑战

在多线程场景中，对象池面临两个核心问题：

**1. 竞态条件（Race Condition）**

考虑以下场景：

```bash
时间点  线程A                    线程B
  1     检查对象1可用
  2                             检查对象1可用
  3     标记对象1为使用中
  4                             标记对象1为使用中（覆盖）
  5     使用对象1               使用对象1（同时使用！）
```

两个线程可能同时获取同一个对象，导致数据竞争。

**2. 等待与通知机制**

当池为空时，线程应该：

-  **忙等待**（Busy Wait）：不断尝试获取，浪费 CPU
-  **阻塞等待**（Blocking）：睡眠直到有对象可用

显然阻塞等待更高效，但需要线程间通信机制。

### 线程安全的核心设计

使用**互斥锁 + 条件变量**实现线程安全：

**关键组件**：

1. **互斥锁（`std::mutex`）**：保护共享数据的临界区
2. **条件变量（`std::condition_variable`）**：实现等待/通知机制
3. **超时机制**：避免无限等待导致死锁

### 线程安全实现的核心逻辑

```cpp
template<typename T>
class ThreadSafeObjectPool {
public:
    auto acquire(std::chrono::milliseconds timeout) {
        std::unique_lock<std::mutex> lock(mutex_);

        // 等待可用对象（带超时）
        if (!cv_.wait_for(lock, timeout, [this] {
            return !available_.empty();
        })) {
            throw std::runtime_error("获取对象超时");
        }

        // 取出对象
        auto obj = std::move(available_.back());
        available_.pop_back();

        // 创建归还逻辑
        auto deleter = [this](T* ptr) {
            std::unique_lock<std::mutex> lock(mutex_);
            available_.push_back(std::unique_ptr<T>(ptr));
            cv_.notify_one();  // 通知等待的线程
        };

        return std::unique_ptr<T, std::function<void(T*)>>(
            obj.release(), deleter);
    }

private:
    mutable std::mutex mutex_;
    std::condition_variable cv_;
    std::vector<std::unique_ptr<T>> available_;
};
```

### 工作流程详解

**获取对象（`acquire`）**：

1. **加锁**：`std::unique_lock` 获取互斥锁

2. **等待**：`cv_.wait_for()` 等待条件满足（有可用对象）
   - • 如果有对象：立即返回
   - • 如果没有：释放锁并睡眠，等待通知
   
3. **取出**：从容器中移除对象

4. **返回**：包装成智能指针返回

**归还对象（删除器）**：

1. **加锁**：保护共享数据
2. **放回**：将对象放回容器
3. **通知**：`cv_.notify_one()` 唤醒一个等待的线程

### 条件变量的工作原理

条件变量解决了"如何等待事件发生"的问题：

```cpp
// 等待方（线程A）
cv_.wait_for(lock, timeout, [this] {
    return !available_.empty();  // 条件谓词
});

// 通知方（线程B）
available_.push_back(obj);
cv_.notify_one();  // 唤醒一个等待线程
```

**关键点**：

- • `wait_for` 会**原子地**释放锁并进入睡眠
- • 被唤醒后会**自动重新获取锁**
- • 使用谓词避免**虚假唤醒**（Spurious Wakeup）

### 超时机制的重要性

超时机制避免以下问题：

**1. 死锁场景**：

```cpp
// 假设池只有1个对象
auto obj1 = pool.acquire();           // 成功
auto obj2 = pool.acquire();           // 死锁！永远等不到

// 使用超时避免死锁
try {
    auto obj2 = pool.acquire(5s);     // 5秒后超时
} catch (const std::exception& e) {
    // 处理超时，避免程序挂起
}
```

**2. 服务降级**：

在高负载时，超时可以让系统快速失败，而非无限等待：

```cpp
try {
    auto conn = pool.acquire(100ms);  // 快速失败
    processRequest(conn);
} catch (const std::exception&) {
    return error("Service temporarily unavailable");
}
```

### 性能优化考虑

**1. 锁的粒度**

```cpp
// ✅ 好：锁粒度小
size_t available() const {
    std::lock_guard<std::mutex> lock(mutex_);
    return available_.size();  // 只锁住必要部分
}

// ❌ 差：锁粒度大
void doWork() {
    std::lock_guard<std::mutex> lock(mutex_);
    // 长时间操作...
}
```

**2. 避免锁竞争**

- • 使用 `notify_one()` 而非 `notify_all()`（减少唤醒开销）
- • 考虑使用无锁队列（更高级的优化）

**3. 读写锁**

如果查询操作远多于修改，可以使用 `std::shared_mutex`：

```cpp
std::shared_lock<std::shared_mutex> lock(mutex_);  // 读锁
// 多个线程可以同时读取
```

## 对象池的高级优化技巧

### 1. 动态扩容策略

**固定大小池的问题**：

- • **负载高峰**：池满时无法服务新请求，导致拒绝服务
- • **资源浪费**：按峰值配置导致平时资源闲置

**动态扩容的设计思想**：

采用**弹性池**（Elastic Pool）策略：

- • **初始大小**：满足正常负载（如 10 个连接）
- • **最大大小**：应对峰值负载（如 50 个连接）
- • **扩容策略**：需要时按需创建
- • **收缩策略**：空闲时逐步释放（可选）

**核心实现逻辑**：

```cpp
T* acquire() {
    std::unique_lock<std::mutex> lock(mutex_);

    // 1. 优先使用现有对象
    if (!available_.empty()) {
        return takeFromPool();
    }

    // 2. 池空了，检查是否可以扩容
    if (current_size_ < max_size_) {
        auto obj = createNewObject();
        current_size_++;
        return obj;  // 直接返回新对象
    }

    // 3. 达到上限，等待或抛异常
    throw std::runtime_error("对象池已达最大容量");
}
```

**扩容时机的权衡**：

| 策略     | 优点     | 缺点         | 适用场景   |
| -------- | -------- | ------------ | ---------- |
| 即时扩容 | 响应快   | 可能过度扩容 | 延迟敏感型 |
| 延迟扩容 | 资源节约 | 首次请求慢   | 资源受限型 |
| 按需扩容 | 平衡     | 实现复杂     | 通用场景   |

**收缩策略（可选）**：

定期检查对象的空闲时间，超过阈值则销毁：

```cpp
void shrink() {
    auto now = std::chrono::steady_clock::now();

    available_.erase(
        std::remove_if(available_.begin(), available_.end(),
            [&](const auto& obj) {
                return (now - obj->lastUsedTime()) > 5min;
            }),
        available_.end()
    );
}
```

### 2. 对象健康检查

**为什么需要健康检查？**

长期运行的系统中，对象可能因各种原因变得"不健康"：

- • **网络连接**：TCP 连接断开、服务端重启
- • **资源泄漏**：内存、文件句柄泄漏
- • **状态损坏**：多线程竞争、异常恢复不完全

**健康检查的两种策略**：

**策略 1：被动检查（使用时检查）**

```cpp
T* acquire() {
    T* obj = getObjectFromPool();

    // 使用前检查健康状态
    if (!obj->isHealthy()) {
        obj->reset();  // 尝试恢复
        if (!obj->isHealthy()) {
            recreateObject(obj);  // 恢复失败，重新创建
        }
    }

    return obj;
}
```

**优点**：简单，无额外开销
**缺点**：首次使用时可能延迟较高

**策略 2：主动检查（定期后台检查）**

```cpp
void startHealthCheckThread() {
    health_check_thread_ = std::thread([this]() {
        while (!stop_) {
            std::this_thread::sleep_for(30s);  // 每30秒检查一次

            std::lock_guard<std::mutex> lock(mutex_);
            for (auto& obj : available_) {
                if (!obj->isHealthy()) {
                    LOG_WARNING("Unhealthy object detected, recreating...");
                    obj = std::make_unique<T>();
                }
            }
        }
    });
}
```

**优点**：用户无感知，延迟稳定
**缺点**：增加系统开销

**最佳实践：混合策略**

- • **定期主动检查**：检测大部分问题
- • **使用前快速检查**：补充检测遗漏的问题

### 3. 性能优化：无锁对象池

**互斥锁的性能瓶颈**：

在高并发场景下，锁竞争成为性能瓶颈：

```cpp
线程数：1      2      4      8      16
QPS：  50K   90K   150K   180K   170K  ← 性能不再增长
```

**无锁对象池的原理**：

使用**原子操作**（CAS）替代互斥锁：

```cpp
template<typename T>
class LockFreeObjectPool {
public:
    T* acquire() {
        while (true) {
            Node* head = head_.load(std::memory_order_acquire);
            if (!head) return nullptr;  // 池空

            // CAS 操作：尝试将头节点移除
            if (head_.compare_exchange_weak(head, head->next,
                                             std::memory_order_release,
                                             std::memory_order_acquire)) {
                return &head->object;
            }
            // CAS 失败，重试
        }
    }

private:
    struct Node {
        T object;
        Node* next;
    };
    std::atomic<Node*> head_;
};
```

**注意事项**：

- • **ABA 问题**：需要特殊处理（如使用版本号）
- • **内存顺序**：正确使用 memory order 至关重要
- • **复杂度**：实现复杂，容易出错

**建议**：

- • 普通场景：使用互斥锁版本（简单可靠）
- • 极高并发（QPS > 100K）：考虑无锁版本

### 4. 预热（Warm-up）

**冷启动问题**：

对象首次创建可能触发：

- • 内存分配
- • 网络连接
- • 资源初始化

导致首批请求延迟高。

**预热策略**：

```cpp
void warmUp() {
    std::vector<RAII_Obj> objects;

    // 1. 获取所有对象（触发创建和初始化）
    for (size_t i = 0; i < pool.size(); ++i) {
        objects.push_back(pool.acquire());
    }

    // 2. 可选：执行一次虚拟操作
    for (auto& obj : objects) {
        obj->ping();  // 建立连接、分配缓存等
    }

    // 3. 归还所有对象
    objects.clear();
}

// 启动时调用
pool.warmUp();
```

**效果**：

- • 首批请求延迟：从 100ms 降至 10ms
- • 减少启动后的延迟抖动

## 对象池的最佳实践

### 设计原则

1. **初始容量设置**

   - • 根据系统负载预估初始大小
   - • 避免过大造成资源浪费
   - • 避免过小导致频繁扩容

2. **对象重置策略**

   - • 归还时必须完全重置对象状态
   - • 清理临时资源和缓存
   - • 恢复初始状态

3. **超时机制**

   - • 获取对象时设置合理超时
   - • 避免无限等待造成死锁
   - • 超时后抛出异常或返回错误

4. **监控和统计**

   ```cpp
   struct PoolStats {
       size_t total_size;      // 池总大小
       size_t available;       // 可用对象数
       size_t in_use;          // 使用中对象数
       size_t acquire_count;   // 获取次数
       size_t timeout_count;   // 超时次数
   };
   ```

### 常见陷阱

**陷阱 1：忘记重置对象状态**

```cpp
// ❌ 错误：没有重置状态
void release(Connection* conn) {
    available_.push_back(conn);  // 直接归还
}

// ✅ 正确：归还前重置
void release(Connection* conn) {
    conn->reset();  // 清理状态
    available_.push_back(conn);
}
```

**陷阱 2：死锁风险**

```
// ❌ 错误：可能死锁
auto conn1 = pool.acquire();
auto conn2 = pool.acquire();  // 如果池只有1个对象，这里会死锁

// ✅ 正确：使用超时机制
try {
    auto conn1 = pool.acquire(std::chrono::seconds(5));
    auto conn2 = pool.acquire(std::chrono::seconds(5));
} catch (const std::exception& e) {
    // 处理超时
}
```

**陷阱 3：资源泄漏**

```cpp
// ❌ 错误：异常导致对象未归还
Connection* conn = pool.acquire();
doWork(conn);  // 如果抛出异常，对象永远不会归还
pool.release(conn);

// ✅ 正确：使用 RAII
{
    auto conn = pool.acquire();
    doWork(conn.get());
}  // 自动归还，异常安全
```

### 池大小设置的科学方法

**1. CPU 密集型任务**

```
池大小 = CPU 核心数 + 1
```

**原理**：

- • CPU 密集型任务受 CPU 核心数限制
- • +1 是为了在某个线程阻塞时仍有线程可用

**2. I/O 密集型任务**

```
池大小 = CPU 核心数 × (1 + 等待时间 / 计算时间)
```

**3. 数据库连接池**

需考虑更多因素：

```
连接池大小 = min(
    应用并发数 / 应用实例数,
    数据库最大连接数 × 0.8
)
```

### 常见性能问题及解决方案

**问题 1：获取对象延迟高**

**症状**：`acquire()` 经常超时

**原因分析**：

- • 池太小，供不应求
- • 对象使用时间过长
- • 对象泄漏（未归还）

**解决方案**：

```cpp
// 1. 增加池大小
pool.resize(current_size * 1.5);

// 2. 设置对象使用超时
auto obj = pool.acquire();
if (obj.ageInUse() > 30s) {
    LOG_ERROR("Object held too long!");
}

// 3. 启用泄漏检测
pool.enableLeakDetection(true);
```

**问题 2：内存占用过高**

**症状**：对象池占用大量内存

**原因分析**：

- • 池大小设置过大
- • 对象本身占用内存大
- • 没有实现对象收缩

**解决方案**：

```cpp
// 1. 根据负载动态调整
if (pool.idleRate() > 0.5) {
    pool.shrink(pool.size() * 0.8);  // 缩减到 80%
}

// 2. 使用轻量级对象
// 例如：连接对象只保存句柄，不缓存数据

// 3. 定期释放空闲对象
pool.evictIdle(5min);  // 释放空闲超过 5 分钟的对象
```

**问题 3：锁竞争严重**

**症状**：CPU 利用率低，线程大量阻塞在锁上

**原因分析**：

- • 高并发下互斥锁成为瓶颈
- • 临界区过大

**解决方案**：

```cpp
// 1. 减小临界区
// ❌ 错误：临界区太大
{
    std::lock_guard<std::mutex> lock(mutex_);
    auto obj = findObject();
    obj->doWork();  // 不应该在锁内执行
}

// ✅ 正确：最小临界区
Object* obj;
{
    std::lock_guard<std::mutex> lock(mutex_);
    obj = findObject();
}
obj->doWork();  // 在锁外执行

// 2. 使用分段锁（Sharded Lock）
// 将池分成多个分片，每个分片独立锁
class ShardedPool {
    static constexpr size_t SHARD_COUNT = 16;
    std::array<Pool, SHARD_COUNT> shards_;

    Pool& getShard(std::thread::id tid) {
        return shards_[std::hash<std::thread::id>{}(tid) % SHARD_COUNT];
    }
};

// 3. 考虑无锁实现（极端情况）
```

------

## 总结与实践建议

### 核心要点回顾

**1. 对象池的本质**

对象池是一种**空间换时间**的策略：

- • 牺牲内存空间（预创建对象）
- • 换取时间性能（避免频繁创建销毁）
- • 适用于高成本对象的复用场景

**2. RAII 是关键**

使用 RAII 风格实现对象池带来三大好处：

- • **异常安全**：无论何种退出路径都能正确归还
- • **代码简洁**：用户无需手动管理生命周期
- • **编译期保证**：编译器负责资源释放，减少人为错误

**3. 线程安全的必要性**

生产环境中，对象池必须是线程安全的：

- • 使用**互斥锁 + 条件变量**保护共享状态
- • 实现**超时机制**避免死锁
- • 考虑**锁粒度优化**提升并发性能

**4. 对象重置至关重要**

对象归还时必须**彻底重置状态**：

- • 回滚事务
- • 清理缓存
- • 重置配置
- • 检查健康状态

这是对象池正确性的根本保证。

### 适用场景决策指南

**✅ 强烈推荐使用对象池的场景**：

| 场景       | 创建成本   | 使用频率 | 预期收益  | 典型应用   |
| ---------- | ---------- | -------- | --------- | ---------- |
| 数据库连接 | 50-100ms   | 极高     | **5-10x** | Web 后端   |
| 网络连接   | 10-50ms    | 高       | **3-5x**  | 微服务     |
| 线程       | 100-1000μs | 高       | **2-4x**  | 并发服务器 |
| 大对象     | 视大小而定 | 中高     | **2-3x**  | 游戏开发   |

**⚠️ 谨慎使用对象池的场景**：

- • **小对象**（< 1KB）：创建成本低，池化收益有限
- • **长生命周期对象**：持有时间长，失去复用意义
- • **状态复杂对象**：重置逻辑复杂，容易出错
- • **不频繁使用**：使用间隔长，内存浪费

**❌ 不推荐使用对象池的场景**：

- • POD 类型（Plain Old Data）
- • RAII 资源包装器（如 `std::unique_ptr`）
- • 有严格所有权语义的对象

**最后，记住这句话**：

> **好的代码不是写出来的，是优化出来的。**
> **而对象池，就是优化路上最值得掌握的武器之一。**

 
<!-- markdown for nginx, see https://phus.lu -->
<script>
!function(){
	var dom = {
		element: null,
		get: function (o) {
			var obj = Object.create(this)
			obj.element = (typeof o == "object") ? o : document.createElement(o)
			return obj
		},
		add: function (o) {
			var obj = dom.get(o)
			this.element.appendChild(obj.element)
			return obj
		},
		text: function (t) {
			this.element.appendChild(document.createTextNode(t))
			return this
		},
		attr: function (k, v) {
			this.element.setAttribute(k, v)
			return this
		}
	}

	if (!document.head) return
	head = dom.get(document.head)
	head.add('meta').attr('charset', 'utf-8')
	head.add('meta').attr('name', 'viewport').attr('content', 'width=device-width,initial-scale=1')

	if (!document.body) {
		document.write(["<div class=\"container\">",
		"<h3>nginx.conf</h3>",
		"<textarea rows=6 cols=50>",
		"# download markdown.html to /wwwroot",
		"location ~ \\.md$ {",
		"    default_type text/html;",
		"    add_after_body /markdown.html;",
		"}",
		"</textarea>",
		"</div>"].join("\n"))
		return
	}

	var bodytext = document.body.innerHTML
	document.body.innerHTML = ''

	div = dom.get('div').attr('class', 'container')

	div.add('script').attr('src', 'https://cdnjs.cloudflare.com/ajax/libs/marked/0.5.2/marked.min.js').attr('integrity', 'sha256-zFUosuESzULu5P+SZdjRRtBZR8+1u5RZDlbt3Q5KL8U=').attr('crossorigin', 'anonymous')
	div.add('link').attr('rel', 'stylesheet').attr('href', 'https://cdnjs.cloudflare.com/ajax/libs/github-markdown-css/5.1.0/github-markdown-light.min.css').attr('integrity', 'sha256-WQx0Y6LLZeGv3V3NVVge+YIL5MIOt45RPuFdkyNodls=').attr('crossorigin', 'anonymous')

	title = decodeURIComponent(document.location.pathname.replace(/.*\//, '').replace(/\.html$/, ''))
	document.title = '《' + title.replace(/\.md$/, '') + '》'
	tbody = div.add('table').add('tbody')
	tbody.add('tr').add('th').text(title).attr('class', 'octicon-book')
	tbody.add('tr').add('td').add('div').attr('id', 'readme').attr('class', 'markdown-body')

	wait = function (name, callback) {
		var interval = 10; // ms
		window.setTimeout(function() {
			if (window[name]) {
				callback(window[name])
			} else {
				window.setTimeout(arguments.callee, interval)
			}
		}, interval)
	}
	wait('marked', function() {
		document.getElementById("readme").innerHTML = marked.parse(bodytext)
	})

	document.body.appendChild(div.element)
}()
</script>

<style>
body {
	margin: 0;
	font-family: "ubuntu", "Tahoma", "Microsoft YaHei", Arial, Serif;
}
.markdown-body {
	float: left;
	font-family: "ubuntu", "Tahoma", "Microsoft YaHei", Arial, Serif;
}
.container {
	padding-right: 15px;
	padding-left: 15px;
	margin-right: auto;
	margin-left: auto;
}
@media (min-width: 768px) {
	.container {
		max-width: 80%;
	}
}
@media (min-width: 992px) {
	.container {
		max-width: 70%;
	}
}
@media (min-width: 1200px) {
	.container {
		max-width: 60%;
	}
}
table {
	width: 100%;
	max-width: 100%;
	margin-bottom: 20px;
	border: 1px solid #ddd;
	padding: 0;
	border-collapse: collapse;
}
table th {
	font-size: 14px;
}
table tr {
	border: 1px solid #ddd;
	padding: 5px;
}
table th, table td {
	border: 1px solid #ddd;
	font-size: 14px;
	line-height: 20px;
	padding: 3px;
	text-align: left;
}
.octicon-book {
	background-position: center left;
	background-repeat: no-repeat;
	padding-left: 20px;
	background-image: url("data:image/svg+xml;charset=utf8,%3Csvg xmlns='http://www.w3.org/2000/svg' width='16' height='16' viewBox='0 0 16 16'%3E%3Cpath d='M3,5 L7,5 L7,6 L3,6 L3,5 L3,5 Z M3,8 L7,8 L7,7 L3,7 L3,8 L3,8 Z M3,10 L7,10 L7,9 L3,9 L3,10 L3,10 Z M14,5 L10,5 L10,6 L14,6 L14,5 L14,5 Z M14,7 L10,7 L10,8 L14,8 L14,7 L14,7 Z M14,9 L10,9 L10,10 L14,10 L14,9 L14,9 Z M16,3 L16,12 C16,12.55 15.55,13 15,13 L9.5,13 L8.5,14 L7.5,13 L2,13 C1.45,13 1,12.55 1,12 L1,3 C1,2.45 1.45,2 2,2 L7.5,2 L8.5,3 L9.5,2 L15,2 C15.55,2 16,2.45 16,3 L16,3 Z M8,3.5 L7.5,3 L2,3 L2,12 L8,12 L8,3.5 L8,3.5 Z M15,3 L9.5,3 L9,3.5 L9,12 L15,12 L15,3 L15,3 Z' /%3E%3C/svg%3E");
}
</style>