常见锁机制

加锁的目的

  多线程访问共享资源的时候，避免不了资源竞争而导致数据错乱的问题，所以都会在访问共享资源之前加锁，保证共享资源在任意时间里，只有一个线程访问。

互斥锁

  互斥锁是一种独占锁,比如当线程A加锁成功后，此时互斥锁已经被线程A独占，只要线程A没有释放手中的锁，线程B加锁就会失败，互斥锁加锁失败后，线程会释放CPU，给其他的线程，于是线程B就会释放CPU让给其他线程，既然线程B释放掉了CPU，自然线程B加锁的代码就会被阻塞。
  lock尝试加锁，如果加锁不成功，线程阻塞，阻塞到持有该互斥量的其他线程解锁为止；unlock主动解锁，同时将阻塞在该锁上的所有线程全部唤醒，至于哪个线程先被唤醒取决于优先级、调度，默认先阻塞先唤醒。
  在访问共享资源前加锁，访问结束后立即解锁。锁的粒度越小越好。

  锁粒度就是通常说的锁级别。数据库引擎具有多粒度锁定，允许一个事务锁定不同类型的资源。为了尽量减少锁定的开销，数据库引擎自动将资源锁定在适合任务的级别。锁定在较小的粒度(例如行)可以提供并发度，但开销较高，因为如果锁定了许多行，则需要持有更多的锁。锁定在较大的粒度(例如表)会降低并发度，因为锁定整个表限制了其他事务对表中任意部分的访问，但其开销较低，因为需要维护多的锁较少。做一个奇妙的比喻，人是不同的线程，卫生间是共享资源，当你需要使用卫生间，你就会把卫生间锁起来，这就是加锁，卫生间就是你的加锁粒度。但卫生间不止可以上厕所，还有浴室，洗手池等，这就涉及到优化加锁粒度的问题，如果把马桶、洗手池、浴室分别隔离加锁，那么现在卫生间就可以三个人使用，达到卫生间资源的最大化利用，提高了并发度，但开销就变大了，以前卫生间加一道锁可以做三件事，但现在做三件事需要加三道锁。

  对于互斥锁加锁失败而阻塞的现象，是由操作系统内核实现的。当加锁失败时，内核会将线程置为睡眠状态，等到锁被释放后，内核会在合适的时机唤醒线程，当这个线程成功取到锁后，于是就可以继续执行。所以，互斥锁加锁失败后，会从用户态陷入内核态，让内核切换线程，虽然简化了使用锁的难度，但存在一定的性能开销成本——两次线程上下文切换的成本：

• 运行—>阻塞，当线程加锁失败时，内核会把线程的状态从运行设置为阻塞，然后把CPU切换给其他线程运行；
• 阻塞—>就绪，当锁被释放，之前阻塞状态的线程会变成就绪，然后内核会在合适的时候，把CPU切换给该线程运行。
    线程的上下文切换是，当两个线程是属于同一个进程，因为虚拟内存是共享的，所以在切换的时候，虚拟内存的资源保持不动，只需要切换线程的私有数据，寄存器等不共享的数据。上下文切换的时间大概在几十纳秒到几微妙之间，如果你锁住的代码执行时间比较短，那可能切换的时间比你锁住的代码执行时间还要长。所以，如果确定被锁住的代码执行时间很短，就不应该使用互斥锁，而应该使用自旋锁，否则使用互斥锁。

自旋锁

  自旋锁加锁失败后，线程会忙等待，直到它拿到锁。
  自旋锁是通过CPU提供的CAS（Compare and Swap）函数，在用户态完成完成加锁和解锁操作，不会主动产生线程上下切换，所以相比互斥锁来说，会快一下，开销也小一些。
  一般加锁的过程，包含两个步骤：
   1）查看锁的状态，如果锁是空闲的，则执行第二步；
  2）将锁设置为当前线程持有。
  CAS函数就把这两个步骤合并为一条硬件级指令，形成原子指令，这样就保证了这两个步骤是不可分割的，要么一次性执行完两个步骤，要么两个步骤都不执行。
  使用自旋锁的时候，当发生多线程竞争锁的情况，加锁失败的线程会忙等待，直到它拿到锁。这里的忙等待可以用while循环等待实现，不过最好使用CPU提供的PAUSE指令来实现忙等待，因为可以减少循环等待时的耗电量。自旋锁是比较简单的一种锁，一直自旋，利用CPU周期，直到锁可用。需要注意，在单核CPU上，需要抢占式的调度器（即不断通过时钟中断一个线程，运行其他线程）。否则，自旋锁在单CPU上无法使用，因为一个自旋的线程永远不会放弃CPU。
  自旋锁开销少，在多核系统下一般不会主动产生线程切换，适合异步、协程等在用户态切换请求的编程方式，但如果被锁住的代码时间过长，自旋的线程会长时间占用CPU资源，所以自旋的时间和被锁住的代码执行的时间是成正比的。

读写锁

  读写锁由读锁和写锁构成，如果只读取共享资源用读锁加锁，如果要修改共享资源则用写锁加锁。所以，读写锁适用于能明确区分读操作和写操作的场景。
  其工作原理是：当写锁没有被线程持有时，多个线程能够并发地持有读锁，这大大提高了共享资源的访问效率，因为读锁是用于读取共享资源的场景，所以多个线程同时持有读锁也不会破坏共享资源的数据，但是一旦写锁被线程持有后，读线程的获取读锁的操作会被阻塞，而且其他写线程的获取写锁的操作也会被阻塞。所以写锁是独占锁，因为任何时刻只能有一个线程持有写锁，类似互斥锁和自旋锁，而读锁是共享锁，因为读锁可以被多个线程同时持有，读写锁再读多写少的场景中能发挥优势。
  根据实现的不同，读写锁可以分为读优先锁和写优先锁。读优先锁的期望是读锁能被更多的线程持有，以便提高读线程的并发性，它的工作方式是：当读线程A先持有了读锁，写线程B在获取写锁的时候，会被阻塞，并且在阻塞过程中，后续来的读线程C仍然可以成功获取读锁，最后直到读线程A和C释放读锁后，写线程B才可以成功获取读锁。

  而写优先锁是优先服务写线程，其工作方式是：当写线程A先持有读锁，写线程B在获取写锁的时候，会被阻塞，并且在阻塞过程中，后续来的读线程C获取读锁会失败，于是读线程C将被阻塞在获取读锁的操作，这样只要读线程A释放读锁后，写线程B就可以成功获取读锁。

  读优先锁对于读线程并发性更好，但也不是没有问题，如果一直有读线程获取读锁，那么写线程将永远取不到写锁，这就造成了写线程饥饿的现象。写优先锁可以保证写线程不会饿死，但是如果一直有写线程获取写锁，读线程也会被饿死。既然不管优先读锁还是写锁，对方可能会出现饿死问题，那么就不偏袒任何一方—公平读写锁。公共读写锁比较简单的一种方式是：用队列把获取锁的线程排队，不管是写线程还是读线程都按照先进先出的原则加锁即可，这样读线程仍然可以并发，也不会出现饥饿的现象。

乐观锁与悲观锁

  互斥锁、自旋锁、读写锁都属于悲观锁。悲观锁做事比较悲观，它认为多线程同时修改共享资源的概率比较高，于是很容易发生冲突，所以访问共享资源前，先上锁。相反地，如果多线程同时修改共享资源的概率比较低，就可以采用乐观锁。乐观锁做事比较乐观，它假定冲突的概率很低，先修改完共享资源，再验证这段时间内有没有发生冲突，如果没有其他线程在修改资源，那么操作完成，如果发现其他线程已经修改过这个资源，就放弃本次操作。放弃后如何重试，这跟业务场景息息相关，虽然重试的成本很高，但是冲突的概率足够低的话，还是可以接受的。
  不管使用的哪种锁，我们的加锁的代码范围应该尽可能的小，也就是加锁的粒度要小，这样执行速度会比较快。再来，使用上了合适的锁，就会快上加快了。

待理解完善