大量资源访问--锁设计

我们考虑这样一个场景：如果有大量的资源，比如上亿的文件，我们需要对文件进行读/写/更新/删除操作，每个操作可能会花费较长的时间，为了防止多线程并发对同一个文件同时进行操作，我们通常需要对同一个资源进行加锁，防止并发操作。

通常的做法是我们为每一个资源加一把锁，问题来了，有上亿的问题，那我们得同时新建上亿把锁，这样对系统是个非常大的负担，通常是不可取的。

或者我们有进一步的策略，创建一个固定数量的锁，通过哈希的方式，把不同的文件哈希到同一把锁上，这样我们可以减少锁的数量，但是会带来另一个问题，那就是如果A资源和B资源使用同一把锁，A资源获取锁后进行操作，通常会持续较长的时间，这时B资源的操作只能等待，这种在用户的角度是不可接受的。

这时我们会想，那何不在资源需要访问的时候新建一把锁，当资源操作完成后，删除掉这把锁呢？

的确，这种方式可以最大程度的减少锁的数量，同时减少不同资源之间的锁冲突，但是有个问题，由于是多线程访问，当单个线程访问时，如果判断是否应该新建锁，何时应该删除锁呢，删除锁时如何保证该锁没有被其他线程获取呢？

这时我们会考虑，那就新建一个全局锁来管理每个单个的锁，这样我们可以保证新建锁和删除锁的原子性了：

class RWLockRef
{
public:
    RWLockRef()
    {
        refCount_ = 0;
    }
    ~RWLockRef()
    {
    }

    void incrRefCount()
    {
        ++refCount_;
    }

    void decrRefCount()
    {
        --refCount_;
    }

    void lock(const ELockType lock_type)
    {
        if (lock_type == READ_LOCKER)
        {
            locker_.rdlock();
        }
        else
        {
            locker_.wrlock();
        }
    }

    void unlock()
    {
        locker_.unlock();
    }

    bool unuse()
    {
        return (refCount_ == 0);
    }

private:
    
    RWLock locker_;
    uint32_t refCount_;
};

class RWLockManager
{
public:
    RWLockManager();
    ~RWLockManager();
    
    RWLockRef* GetRWLockByID(const uint64_t id);
    void UnlockRWLockByID(const uint64_t id);

private:
    void init();
    RWLockRef* GetRWLockRef();
    void SetRWLockRef(RWLockRef* rw_lock_ref);

    map<uint64_t,RWLockRef*> lock_map_;
    SafeLock lock_;
};

class ScopedRWLockManager
{
public:
    ScopedRWLockManager(RWLockManager& rw_lock_manager, const uint64_t id, const ELockType lock_type)
        : rw_lock_manager_(rw_lock_manager),id_(id)
    {
        RWLockRef* rw_lock_ref = rw_lock_manager_.GetRWLockByID(id);

        if(NULL == rw_lock_ref)
        {
            return;
        }
        rw_lock_ref->lock(lock_type);
    }
    
    ~ScopedRWLockManager()
    {
        rw_lock_manager_.UnlockRWLockByID(id_);
    }
private:
    RWLockManager& rw_lock_manager_;
    uint64_t id_;
};

然后我们设计一个管理锁的类RWLockManager，该类含有一个全局的锁，当调用GetRwLockByID时，我们首先从lock_map里查找id对应的锁，如果找不到，则新建，同时将引用计数增加，

当调用UnlockRWLockByID时，我们首先进行解锁，同时将引用计数减少，如果引用计数减少为0，则将该锁删除。

从这里可以看出，在加锁的时候，是先获取RWLockRef锁指针，在GetRwLockByID函数外面进行加锁，而解锁是在UnlockRWLockByID内部解锁，这样设计是因为资源锁是针对具体的资源的，加锁后处理需要比较长的时间，为了不影响其他资源的等待，需要在函数外面进行加锁，而解锁可以立马返回，所以放在函数里面处理。

另外还有个问题，为什么RWLockRef需要将引用计数操作独立成两个函数incrRefCount()和decrRefCount()，而没有放到lock()和unlock()函数里面呢？

资源锁的每次的新建和删除会对性能有一定的影响，那么我们可以如何进一步优化？