【整理】关于各种各样的锁

文章目录

• 各种各样的锁
• • 互斥锁
  • 读写锁
  • 条件变量
  • 信号量
  • 自旋锁
  • 共同点：
  • 分为两类：
  • 乐观锁、悲观锁
  • 行锁、页锁、表锁
  • • MyISAM
    • InnoDB

各种各样的锁

互斥锁

互斥锁–保护了一个临界区，在这个临界区中，一次最多只能进入一个线程。如果有多个进程在同一个临界区内活动，就有可能产生竞态条件(race condition)导致错误，其中包含递归锁和非递归锁，（递归锁：同一个线程可以多次获得该锁，别的线程必须等该线程释放所有次数的锁才可以获得）。

读写锁

读写锁–从广义的逻辑上讲，也可以认为是一种共享版的互斥锁。可以多个线程同时进行读,但是写操作必须单独进行,不可多写和边读边写。如果对一个临界区大部分是读操作而只有少量的写操作，读写锁在一定程度上能够降低线程互斥产生的代价。

条件变量

条件变量–允许线程以一种无竞争的方式等待某个条件的发生。当该条件没有发生时，线程会一直处于休眠状态。当被其它线程通知条件已经发生时，线程才会被唤醒从而继续向下执行。条件变量是比较底层的同步原语，直接使用的情况不多，往往用于实现高层之间的线程同步。使用条件变量的一个经典的例子就是线程池(Thread Pool)了。

信号量

信号量–通过精心设计信号量的PV操作，可以实现很复杂的进程同步情况（例如经典的哲学家就餐问题和理发店问题）。而现实的程序设计中，却极少有人使用信号量。能用信号量解决的问题似乎总能用其它更清晰更简洁的设计手段去代替信号量。

自旋锁

自旋锁–当要获取一把自旋锁的时候又被别的线程持有时,不断循环的去检索是否可以获得自旋锁,一直占CPU资源。

共同点：

• 每种类型的同步对象都有一个init的API，它完成该对象的初始化，在初始化过程中会分配该同步对象所需要的资源（注意是为支持这种锁而需要的资源，不包括表示同步对象的变量本身所需要的内存）
• 每种类型的同步对象都一个destory的API，它完成与init相反的工作
• 对于使用动态分配内存的同步对象，在使用它之前必须先调用init
• 在释放使用动态分配内存的同步对象所使用的内存时，必须先调用destory释放系统为其申请的资源
• 每种同步对象的默认作用范围都是进程内部的线程，但是可以通过修改其属性为PTHREAD_PROCESS_SHARED并在进程共享内存中创建它的方式使其作用范围跨越进程范围
• 无论是作用于进程内的线程，还是作用于不同进程间的线程，真正参与竞争的都是线程（对于不存在多个线程的进程来说就是其主线程），因而讨论都基于线程来
• 这些同步对象都是协作性质的，相当于一种君子协定，需要相关线程主动去使用，无法强制一个线程必须使用某个同步对象

分为两类：

• 第一类是互斥锁、读写锁、自旋锁，它们主要是用来保护临界区的，也就是主要用于解决互斥问题的，当尝试上锁时大体上有两种情况下会返回：上锁成功或出错，它们不会因为出现信号而返回。另外解锁只能由锁的拥有着进行
• 第二类是条件变量和信号量，它们提供了异步通知的能力，因而可以用于同步和互斥。但是二者又有区别：
  • 信号量可以由发起P操作的线程发起V操作，也可以由其它线程发起V操作；但是条件变量一般要由其它线程发起signal（即唤醒）操作
  • 由于条件变量并没有包含任何需要检测的条件的信息，因而对这个条件需要用其它方式来保护，所以条件变量需要和互斥锁一起使用，而信号量本身就包含了相关的条件信息（一般是资源可用量），因而不需要和其它方式一起来使用
  • 类似于三种锁，信号量的P操作要么成功返回，要么失败返回，不会因而出现信号而返回；但是条件变量可能因为出现信号而返回，这也是因为它没包含相关的条件信息而导致的。

乐观锁、悲观锁

悲观锁就是先进行加锁，如果某一个线程想要取这个数据，就会一致阻塞到获得锁；

乐观锁不会向加锁，在更新的时候回去判断一下在此期间这个数据有没有被更新，可以使用 版本号机制 和 CAS算法 实现；乐观锁适用于多读操作的场景，这样就可以避免重复加锁释放锁的开销，可以提高吞吐量；

缺陷：

• ABA 问题
• 循环时间长，开销大
• 只能保证一个共享变量的原子操作

行锁、页锁、表锁

行锁、表锁 - 详细介绍

InnoDB 支持表、行（默认）锁，MyISAM 仅支持表级锁；

• 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。
• 行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。
• 页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般

MyISAM

在使用MyIsam时，我们只可以使用表级锁，而MySQL的表级锁有两种模式：

表共享锁（Table Read Lock）和表独占写锁（Table Write Lock），他们在工作时表现如下：

• 对某一个表的读操作，不会阻塞其他用户对同一表请求，但会阻塞对同一表的写请求；
• 对MyISAM的写操作，则会阻塞其他用户对同一表的读和写操作；
• MyISAM表的读操作和写操作之间，以及写操作之间是串行的。

当一个线程获得对一个表的写锁后，只有持有锁的线程可以对表进行更新操作。其他线程的读、写操作都会等待，直到锁被释放为止。

InnoDB

InnoDB实现了以下两种类型的行锁。

• 共享锁（s）：允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。
• 排他锁（Ｘ）：允许获取排他锁的事务更新数据，阻止其他事务取得相同的数据集共享读锁和排他写锁。

另外，为了允许行锁和表锁共存，实现多粒度锁机制，InnoDB还有两种内部使用的意向锁（Intention Locks），这两种意向锁都是表锁。

• 意向共享锁（IS）：事务打算给数据行共享锁，事务在给一个数据行加共享锁前必须先取得该表的IS锁。
• 意向排他锁（IX）：事务打算给数据行加排他锁，事务在给一个数据行加排他锁前必须先取得该表的IX锁。