线程池单例、线程安全、重入与死锁

懒汉模式要靠一个静态指针把对象'先记住'，真正第一次访问时再 new。这类写法的重点不是'晚创建'本身，而是你得处理好并发。否则两个线程同时看到空指针，就可能各造一个对象，单例直接失效。

要做成懒汉，通常还要把构造函数私有化，并禁用拷贝构造和赋值运算，这样外部就没法绕开 GetInstance() 自己造实例。

懒汉的核心是延时加载。对服务器启动速度来说，这通常比一上来就把所有对象铺开更实用。

单例式线程池

线程池做成单例，最直接的好处是：整个进程里只维护一套线程，不会因为业务方各自 new 一个线程池，把机器上的资源拆得七零八落。

构造函数私有化，保证外面不能随便创建。

private:
ThreadPool(int threadnum = defaultthreadnum) : _threadnum(threadnum), _is_running(false), _wait_thread_num(0) {
    for (int i = 0; i < _threadnum; i++) {
        std::string name = "thread-" + std::to_string(i + 1);
        _threads.emplace_back([this](const std::string &name) { this->Routine(name); }, name);
    }
    LOG(LogLevel::INFO) << "thread pool obj create success";
}

再把拷贝构造和赋值禁掉：

ThreadPool<T> &operator=(const ThreadPool<T> &) = delete;
ThreadPool(const ThreadPool<T> &) = delete;

单例里需要一个静态指针保存实例：

class ThreadPool {
private:
    // 单例中静态指针
    static ThreadPool<T> *_instance;
};
template <class T> ThreadPool<T> *ThreadPool<T>::_instance = nullptr;

获取实例的时候，第一次创建，后面直接返回同一个对象：

void Start() {
    if (_is_running) return;
    _is_running = true;
    for (auto &t : _threads) {
        t.Start();
    }
    LOG(LogLevel::INFO) << "thread pool running success";
}
// 获取单例
ThreadPool<T> *GetInstance() {
    if (!_instance) {
        _instance = new ThreadPool<T>();
        LOG(LogLevel::DEBUG) << "线程池单例首次被使用，创建并初始化，addr: " << ToHex(_instance);
        _instance->Start();
    }
    return _instance;
}

这里有个常见误区：成员函数虽然能访问类内静态成员，但你得先有对象才能调用成员函数。可单例本身就是为了避免外部先造对象，所以 GetInstance 更适合做成 static。

// 获取单例
static ThreadPool<T> *GetInstance() {
    // ...
}

但这样还不够。多线程同时进来时，还是可能创建出多个实例。做法就是双重检查加锁：先无锁判断一次，只有在空指针时才进锁，再判断一次，最后才创建。

template <class T> class ThreadPool {
public:
    static ThreadPool<T> *GetInstance() {
        // A, B, C
        {
            // 线程安全，提高效率式的获取单例
            if (!_instance) {
                LockGuard lockguard(&_singleton_lock);
                if (!_instance) {
                    _instance = new ThreadPool<T>();
                    LOG(LogLevel::DEBUG) << "线程池单例首次被使用，创建并初始化，addr: " << ToHex(_instance);
                    _instance->Start();
                }
            }
        }
        return _instance;
    }
private:
    static Mutex _singleton_lock;
};
template <class T> Mutex ThreadPool<T>::_singleton_lock;

这套写法不算花哨，但很实用。优点是第一次创建时有保护，后续访问大多数时候不需要加锁，性能还能接受。

线程安全与重入问题

线程安全说的是：多个线程同时访问共享资源时，结果还能保持正确，不互相踩。

一般来说，只处理局部变量的函数问题不大；一旦动到全局变量、静态变量，又没有同步保护，就容易出事。

重入说的是：同一个函数在上一次还没执行完时，又被另一个执行流重新进入。只要这种重复进入不会带来错误结果，这个函数就是可重入的，否则就是不可重入。

一个偏实用的理解是：

• 线程安全更像是'多个线程一起用会不会乱'
• 重入更像是'这个函数能不能在执行中途再次被打断并重新进入'

两者相关，但不是一回事。

重入常见有两种情况：

• 多线程同时进入同一个函数
• 信号打断后再次进入函数

常见的不安全函数，通常有这些特征：

• 依赖全局变量或静态变量
• 返回静态缓冲区地址
• 调用带有全局状态的库函数
• 在函数内部修改共享状态却没有同步

常见的可重入函数，通常满足这些条件：

• 不使用全局变量或静态变量
• 不返回静态或全局数据
• 不依赖不可重入的库函数
• 所需数据由调用者传入，或者使用局部副本

可重入与线程安全的关系

有个常见结论可以先记住：可重入函数一定是线程安全的，但线程安全不一定可重入。

原因很简单。线程安全通常靠锁来解决，可是如果一个函数在持锁期间再次被信号打断并重入，第二次进入还要申请同一把锁，就很容易把自己卡死。这时候函数在并发意义上是安全的，在重入意义上却已经出问题了。

所以我更愿意把它理解成两层约束：线程安全管的是并发访问，重入管的是函数能否在中途再次进入。前者更偏系统调用场景，后者更偏函数实现细节。

常见锁概念

死锁

死锁就是一组执行流都占着别人的资源不放，又都在等别人先释放，最后大家一起卡住，谁也走不动。

假设线程 A 和线程 B 都必须同时拿到锁 1 和锁 2，才能继续往下走：

单独申请一把锁是原子的，但连续申请两把锁就未必了：

最后就会变成这样：

死锁的四个必要条件

• 互斥条件：一个资源一次只能被一个执行流使用
• 请求与保持条件：执行流拿到部分资源后，还继续请求其他资源，同时不释放已持有资源

• 不剥夺条件：已经拿到的资源，在使用完之前不能被强行收回

• 循环等待条件：多个执行流形成首尾相接的等待链

避免死锁

破坏死锁条件，通常从'循环等待'这一项下手最实际。常见做法有三种：一次性申请资源、使用超时机制、统一加锁顺序。

// 定义两个共享资源（整数变量）和两个互斥锁
int shared_resource1 = 0;
int shared_resource2 = 0;
std::mutex mtx1, mtx2;
// 一个函数，同时访问两个共享资源
void access_shared_resources() {
    // std::unique_lock<std::mutex> lock1(mtx1, std::defer_lock);
    // std::unique_lock<std::mutex> lock2(mtx2, std::defer_lock);
    // 
    // 使用 std::lock 同时锁定两个互斥锁
    // std::lock(lock1, lock2);
    // 现在两个互斥锁都已锁定，可以安全地访问共享资源
    int cnt = 10000;
    while (cnt) {
        ++shared_resource1;
        ++shared_resource2;
        cnt--;
    }
    // 当离开 access_shared_resources 的作用域时，lock1 和 lock2 的析构函数会被自动调用
    // 这会导致它们各自的互斥量被自动解锁
}
// 模拟多线程同时访问共享资源的场景
void simulate_concurrent_access() {
    std::vector<std::thread> threads;
    // 创建多个线程来模拟并发访问
    for (int i = 0; i < 10; ++i) {
        threads.emplace_back(access_shared_resources);
    }
    // 等待所有线程完成
    for (auto &thread : threads) {
        thread.join();
    }
    // 输出共享资源的最终状态
    std::cout << "Shared Resource 1: " << shared_resource1 << std::endl;
    std::cout << "Shared Resource 2: " << shared_resource2 << std::endl;
}
int main() {
    simulate_concurrent_access();
    return 0;
}

这段代码里真正值得盯住的，不是'加锁了'，而是'怎么加锁'。一把一把手动拿锁，最容易在复杂路径里留下死角；统一由 std::lock 或者固定顺序去处理，会省很多后续麻烦。

STL、智能指针和线程安全

STL 容器默认不是线程安全的。原因不复杂：STL 的目标是性能，不是替你兜底并发问题。真要为了每个容器都加通用锁，性能会掉得很明显，而且不同容器的锁粒度也不一样，没法一刀切。

所以多线程场景下，容器安全通常要靠调用者自己保证。

智能指针也是一样，不是所有都一个处理方式。

• unique_ptr 只在单个所有者内生效，通常不用考虑并发共享
• shared_ptr 需要维护引用计数，多个线程共享时要处理这个计数的同步

标准库已经把这件事处理掉了，引用计数通常通过原子操作来保证安全，避免你每次拷贝一个 shared_ptr 都得自己上锁。

其他常见锁

悲观锁：先假设数据一定会被别人改，所以读写前先加锁。简单直接，代价是并发度一般。

乐观锁：先假设别人不会改，不先加锁；提交更新时再检查数据有没有变化。常见实现是版本号和 CAS。

CAS：比较内存中的当前值和期望值，相等就更新，不相等就失败重试。很多无锁结构都会用它。

自旋锁：拿不到锁就一直试，不挂起。适合临界区很短的场景，不适合长时间等待。