乐观锁与悲观锁
乐观锁：
假设总是最好的情况
当其它线程去读写数据的时候，总认为不会发生问题，因此没有上锁，
直到数据修改完，准备提交的时候，才会上锁，完成后释放。
悲观锁：
假设总是最坏的情况
当其它线程去读写数据的时候，总认为别的线程会对数据进行修改，因此都会上锁，
每次只允许一个线程对数据进行修改，其它线程会被阻塞挂起，
从数据开始修改就将数据锁住，直到更改完才释放锁，
排它锁与共享锁
排它锁：
写锁（X锁）
在某一个时刻只能被某一个线程占有，其它线程必须等待锁释放之后才能获取锁
共享锁：
读锁（S锁）
允许多个线程同时获取一个锁
活锁与死锁
活锁：
事务T1封锁了数据R，事务T2又请求封锁R，于是T2等待。
T3也请求封锁R，当T1释放了R上的封锁之后系统首先批准了T3的请求，T2仍然等待。
T4又请求封锁R，当T3释放了R上的封锁之后系统又批准了T4的请求……
T2有可能永远等待，这就是活锁的情形
线程A和B都需要过桥(都需要使用进程),而都礼让不走(那到的系统优先级相同,都认为不是自己优先级高),就这么僵持下去.（很绅士，互相谦让）
解决办法：采用先来先服务
死锁：
互相等待（拿不到资源互相占用资源）
a1已经封锁了数据R1，正请求对数据R2封锁，
a2已经封锁了数据R2，正请求对数据R1封锁，
解决办法：一次封锁法，每个事务必须一次将所有要使用的数据全部加锁
饿锁：
这是个独木桥(单进程),桥上只能走一个人,B来到时A在桥上,B等待;
而此时比B年龄小的C来了,B让C现行(A走完后系统把进程分给了C),
C上桥后,D又来了,B又让D现行(C走完后系统把进程分个了D)
以此类推B一直是等待状态.
mongodb锁的机制
Mongodb使用读写锁来允许很多用户同时去读一个资源，比如数据库或者集合。读采用的是共享锁，写采用的是排它锁。