wordpress页面评论岳阳整站优化

(Owed by: 春夜喜雨 http://blog.csdn.net/chunyexiyu)

首先是这几种锁的不同与介绍：Mutex锁、读写锁、线程可重入锁。

Mutex读锁

Mutex锁，有加锁状态、未加锁两种状态；
[未加锁状态]时，任一线程申请锁后，该锁进入[加锁状态]；
[加锁状态]时，进程内的所有线程再申请锁时均需要等待，需要等该锁释放后，才能再申请到锁；

RWLock读写锁

ReadWriteMutex读写锁，有加写锁状态、加读锁状态、未加锁三种状态；
[未加锁状态]时，任一线程申请读锁后，该锁进入[加读锁状态]；
[未加锁状态]时，任一线程申请写锁后，该锁进入[加写锁状态]；
[加读锁状态]时，任一线程申请读锁时，申请返回成功，该锁锁状态不变；
[加读锁状态]时，任一线程申请写锁时，申请等待，需要等该读锁释放后，才能申请到写锁；
[加写锁状态]时，任一线程申请读锁时，申请等待，需要等该读锁释放后，才能申请到读锁；
[加写锁状态]时，任一线程申请写锁时，申请等待，需要等该读锁释放后，才能再申请到写锁；

ThreadMutex重入线程锁

ThreadMutex锁，有加锁状态、未加锁两种状态；
[未加锁状态]时，任一线程申请锁后，该锁进入[加锁状态]；
[加锁状态]时，该申请到锁的线程下，再次申请该锁时，申请返回成功，该锁锁状态不变；
[加锁状态]时，非该申请到锁的线程，申请加锁时，申请等待，需要等该线程锁释放后，才能再申请到锁；

使用问题

无论Mutex锁，还是读写锁，还是线程锁。
都存在着，当某个状态加锁时，另一个处申请该锁需要等待的情况，
例如Mutex的加锁情况；
例如读写锁的写锁状态时，或者读取状态申请写锁时；
例如线程锁的其它线程申请锁状态时；
只要存在等待另一个锁释放，那么一旦在某些情况下，该锁占用的周期长了，其它hang住的时间就会长，这个对于高并发系统来说就不容易忍受的。

如何设计高并发系统的锁

怎么设计高并发系统呢？
对于使用锁的情况，我觉得核心点还是，快进快出，申请锁可以，快速用完快速归还；
不要持有锁过长；
不要在持有锁的时候做耗时长的事情；
不要在持有锁的时候做IO操作，无论少量还是大量；
不要在持有锁的时候做大量的计算操作；
不要在持有锁的时候做大量的内存申请释放操作；

如果需要计数，可以直接用std::atomic，快进快出，就一个变量的加锁时间，符合上面的要求；
如果需要唯一进入条件的话，也可以用bool型的std::atomic::compare_exchange_strong，来做唯一进入某个处理的限定；
这些方法都是用轻量级的快进快出加锁解锁的atomic来替代不可预期加锁时长的mutex。

所以总体来看，让加锁快进快出，是高并发系统加锁设计的核心。
当然了，如果可以通过数据结构，设计出无锁设计，那也是相当好的，“无招胜有招”。

(Owed by: 春夜喜雨 http://blog.csdn.net/chunyexiyu)