大量资源访问--锁设计

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

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

或者我们有进一步的策略，创建一个固定数量的锁，通过哈希的方式，把不同的文件哈希到同一把锁上，这样我们可以减少锁的数量，但是会带来另一个问题，那就是如果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()函数里面呢？

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