数据库锁有哪几种？

1、共享锁(Shared lock)

　　T1: select * from table (请想象它需要执行1个小时之久，后面的sql语句请都这么想象）

　　T2: update table set column1='hello'　

　　过程：
　　T1运行 （加共享锁)
　　T2运行
　　If T1 还没执行完
　　　　T2等......
　　else
　　　　锁被释放
　　　　T2执行
　　endif
　　T2之所以要等，是因为T2在执行update前，试图对table表加一个排他锁，
　　而数据库规定同一资源上不能同时共存共享锁和排他锁。所以T2必须等T1

2、更新锁(Update lock)

　　T1: select * from table(updlock) (加更新锁)

　　　　update table set column1='hello'

　　T2: select * from table(updlock)

　　　　update table set column1='world'

　　更新锁的意思是：“我现在只想读，你们别人也可以读，但我将来可能会做更新操作，我已经获取了从共享锁（用来读）到排他锁
　　（用来更新）的资格”。一个事物只能有一个更新锁获此资格。
　　T1执行select，加更新锁。
　　T2运行，准备加更新锁，但发现已经有一个更新锁在那儿了，只好等。
　　当后来有user3、user4...需要查询table表中的数据时，并不会因为T1的select在执行就被阻塞，照样能查询

3、排他锁（独占锁，Exclusive Locks)　

　　T1: update table set column1='hello' where id<1000

　　T2: update table set column1='world' where id>1000

　　假设T1先达，T2随后至，这个过程中T1会对id<1000的记录施加排他锁.但不会阻塞T2的update。

4、意向锁(Intent Locks）

　　T1: select * from table (xlock) where id=10 --意思是对id=10这一行强加排他锁
　　T2: select * from table (tablock) --意思是要加表级锁

　　假设T1先执行，T2后执行，T2执行时，欲加表锁，为判断是否可以加表锁，数据库系统要逐条判断table表每行记录是否已有排他锁，
　　如果发现其中一行已经有排他锁了，就不允许再加表锁了。只是这样逐条判断效率太低了。

　　实际上，数据库系统不是这样工作的。当T1的select执行时，系统对表table的id=10的这一行加了排他锁，还同时悄悄的对整个表
　　加了意向排他锁(IX)，当T2执行表锁时，只需要看到这个表已经有意向排他锁存在，就直接等待，而不需要逐条检查资源了。

5、计划锁(Schema Locks)

　　alter table .... (加schema locks，称之为Schema modification (Sch-M) locks

　　DDL语句都会加Sch-M锁
　　该锁不允许任何其它session连接该表。连都连不了这个表了，当然更不用说想对该表执行什么sql语句了。

什么是条件锁，读写锁，自旋锁，可重入锁？

展开全部

自旋锁(Spin lock)

自旋锁与互斥锁有点类似，只是自旋锁不会引起调用者睡眠，如果自旋锁已经被别的执行单元保持，调用者就一直循环在那里看是

否该自旋锁的保持者已经释放了锁，"自旋"一词就是因此而得名。其作用是为了解决某项资源的互斥使用。因为自旋锁不会引起调用者睡眠，所以自旋锁的效率远

高于互斥锁。虽然它的效率比互斥锁高，但是它也有些不足之处：

1、自旋锁一直占用CPU，他在未获得锁的情况下，一直运行－－自旋，所以占用着CPU，如果不能在很短的时 间内获得锁，这无疑会使CPU效率降低。

2、在用自旋锁时有可能造成死锁，当递归调用时有可能造成死锁，调用有些其他函数也可能造成死锁，如 copy_to_user()、copy_from_user()、kmalloc()等。

因此我们要慎重使用自旋锁，自旋锁只有在内核可抢占式或SMP的情况下才真正需要，在单CPU且不可抢占式的内核下，自旋锁的操作为空操作。自旋锁适用于锁使用者保持锁时间比较短的情况下。

两种锁的加锁原理

互斥锁：线程会从sleep（加锁）——>running（解锁），过程中有上下文的切换，cpu的抢占，信号的发送等开销。

自旋锁：线程一直是running(加锁——>解锁)，死循环检测锁的标志位，机制不复杂。

互斥锁属于sleep-waiting类型的锁。例如在一个双核的机器上有两个线程(线程A和线程B)，它们分别运行在Core0和

Core1上。假设线程A想要通过pthread_mutex_lock操作去得到一个临界区的锁，而此时这个锁正被线程B所持有，那么线程A就会被阻塞

(blocking)，Core0 会在此时进行上下文切换(Context

Switch)将线程A置于等待队列中，此时Core0就可以运行其他的任务(例如另一个线程C)而不必进行忙等待。而自旋锁则不然，它属于busy-waiting类型的锁，如果线程A是使用pthread_spin_lock操作去请求锁，那么线程A就会一直在

Core0上进行忙等待并不停的进行锁请求，直到得到这个锁为止。

两种锁的区别

互斥锁的起始原始开销要高于自旋锁，但是基本是一劳永逸，临界区持锁时间的大小并不会对互斥锁的开销造成影响，而自旋锁是死循环检测，加锁全程消耗cpu，起始开销虽然低于互斥锁，但是随着持锁时间，加锁的开销是线性增长。

两种锁的应用

互斥锁用于临界区持锁时间比较长的操作，比如下面这些情况都可以考虑

1 临界区有IO操作

2 临界区代码复杂或者循环量大

3 临界区竞争非常激烈

4 单核处理器

至于自旋锁就主要用在临界区持锁时间非常短且CPU资源不紧张的情况下，自旋锁一般用于多核的服务器。

lock与Syntronized的区别

转自自：

java并发之Lock与synchronized的区别

1）Lock是一个接口，而synchronized是Java中的关键字，synchronized是内置的语言实现；

2）synchronized在发生异常时，会自动释放线程占有的锁，因此不会导致死锁现象发生；而Lock在发生异常时，如果没有主动通过unLock()去释放锁，则很可能造成死锁现象，因此使用Lock时需要在finally块中释放锁；

3）Lock可以让等待锁的线程响应中断，而synchronized却不行，使用synchronized时，等待的线程会一直等待下去，不能够响应中断；

4）通过Lock可以知道有没有成功获取锁，而synchronized却无法办到。

5）Lock可以提高多个线程进行读操作的效率。

在性能上来说，如果竞争资源不激烈，两者的性能是差不多的，而当竞争资源非常激烈时（即有大量线程同时竞争），此时Lock的性能要远远优于synchronized。所以说，在具体使用时要根据适当情况选择。

两者在锁的相关概念上区别：

1.可重入锁

如果锁具备可重入性，则称作为可重入锁。像synchronized和ReentrantLock都是可重入锁，可重入性在我看来实际上表明了锁的分配机制：基于线程的分配，而不是基于方法调用的分配。举个简单的例子，当一个线程执行到某个synchronized方法时，比如说method1，而在method1中会调用另外一个synchronized方法method2，此时线程不必重新去申请锁，而是可以直接执行方法method2。

看下面这段代码就明白了：

1

2

3

4

5

6

7

8

9

class MyClass

{

public synchronized void method1()

{

method2();

}

public synchronized void method2()

{

}

}

上述代码中的两个方法method1和method2都用synchronized修饰了，假如某一时刻，线程A执行到了method1，此时线程A获取了这个对象的锁，而由于method2也是synchronized方法，假如synchronized不具备可重入性，此时线程A需要重新申请锁。但是这就会造成一个问题，因为线程A已经持有了该对象的锁，而又在申请获取该对象的锁，这样就会线程A一直等待永远不会获取到的锁。

而由于synchronized和Lock都具备可重入性，所以不会发生上述现象。

2.可中断锁

可中断锁：顾名思义，就是可以相应中断的锁。

在Java中，synchronized就不是可中断锁，而Lock是可中断锁。

如果某一线程A正在执行锁中的代码，另一线程B正在等待获取该锁，可能由于等待时间过长，线程B不想等待了，想先处理其他事情，我们可以让它中断自己或者在别的线程中中断它，这种就是可中断锁。

在前面演示lockInterruptibly()的用法时已经体现了Lock的可中断性。

3.公平锁

公平锁即尽量以请求锁的顺序来获取锁。比如同是有多个线程在等待一个锁，当这个锁被释放时，等待时间最久的线程（最先请求的线程）会获得该所，这种就是公平锁。

非公平锁即无法保证锁的获取是按照请求锁的顺序进行的。这样就可能导致某个或者一些线程永远获取不到锁。

在Java中，synchronized就是非公平锁，它无法保证等待的线程获取锁的顺序。

而对于ReentrantLock和ReentrantReadWriteLock，它默认情况下是非公平锁，但是可以设置为公平锁。

看一下这2个类的源代码就清楚了：

在ReentrantLock中定义了2个静态内部类，一个是NotFairSync，一个是FairSync，分别用来实现非公平锁和公平锁。

我们可以在创建ReentrantLock对象时，通过以下方式来设置锁的公平性：

1

ReentrantLock

lock = new ReentrantLock(true);

如果参数为true表示为公平锁，为fasle为非公平锁。默认情况下，如果使用无参构造器，则是非公平锁。

另外在ReentrantLock类中定义了很多方法，比如：

isFair() //判断锁是否是公平锁

isLocked() //判断锁是否被任何线程获取了

isHeldByCurrentThread() //判断锁是否被当前线程获取了

hasQueuedThreads() //判断是否有线程在等待该锁

在ReentrantReadWriteLock中也有类似的方法，同样也可以设置为公平锁和非公平锁。不过要记住，ReentrantReadWriteLock并未实现Lock接口，它实现的是ReadWriteLock接口。

4.读写锁

读写锁将对一个资源（比如文件）的访问分成了2个锁，一个读锁和一个写锁。

正因为有了读写锁，才使得多个线程之间的读操作不会发生冲突。

ReadWriteLock就是读写锁，它是一个接口，ReentrantReadWriteLock实现了这个接口。

可以通过readLock()获取读锁，通过writeLock()获取写锁。

性能比较

在JDK1.5中，synchronized是性能低效的。因为这是一个重量级操作，它对性能最大的影响是阻塞的是实现，挂起线程和恢复线程的操作都需要转入内核态中完成，这些操作给系统的并发性带来了很大的压力。相比之下使用Java提供的Lock对象，性能更高一些。Brian

Goetz对这两种锁在JDK1.5、单核处理器及双Xeon处理器环境下做了一组吞吐量对比的实验，发现多线程环境下，synchronized的吞吐量下降的非常严重，而ReentrankLock则能基本保持在同一个比较稳定的水平上。但与其说ReetrantLock性能好，倒不如说synchronized还有非常大的优化余地，于是到了JDK1.6，发生了变化，对synchronize加入了很多优化措施，有自适应自旋，锁消除，锁粗化，轻量级锁，偏向锁等等。导致在JDK1.6上synchronize的性能并不比Lock差。官方也表示，他们也更支持synchronize，在未来的版本中还有优化余地，所以还是提倡在synchronized能实现需求的情况下，优先考虑使用synchronized来进行同步。

c语言双线程锁的例子？

在Linux使用C语言编辑程序使用互斥锁实现两个线程之间同步，一个线程负责从标准输入设备中读取数据，而另一个线程则负责将读入的数据输出到标准输出设备上，当输入“end”时结束该程序。

指纹锁的门没关，会被别人添上指纹吗？

会。

指纹锁在使用过程中，指纹表面会产生油脂，因此在传感器表面会留存一定的指纹信息，很多不法分子就通过技术手段复制部分指纹信息到指纹膜上，进而欺骗传感器。

一般这种情况对于光学指纹传感器来说是有一定的安全隐患，但电容指纹传感器由于通过电容值来测定活体，所以被骗过的几率相对较小。为了杜绝指纹被盗取，有些智能锁产品在指纹读取器上，增加了纳米防指纹疏油层，防止指纹被盗取。

SQLServer锁机制与锁模式如何正确掌握？

SQL SERVER里的锁机制：NOLOCK（不加锁） 此选项被选中时，SQL Server 在读取或修改数据时不加任何锁。

在这种情况下，用户有可能读取到未完成事务（Uncommited Transaction）或回滚(Roll Back)中的数据, 即所谓的“脏数据”。

HOLDLOCK（保持锁） 此选项被选中时，SQL Server 会将此共享锁保持至整个事务结束，而不会在途中释放。

例如，“ SELECT * FROM my_table HOLDLOCK”就要求在整个查询过程中，保持对表的锁定，直到查询完成才释放锁定。

UPDLOCK（修改锁） 此选项被选中时，SQL Server 在读取数据时使用修改锁来代替共享锁，并将此锁保持至整个事务或命令结束。

使用此选项能够保证多个进程能同时读取数据但只有该进程能修改数据。

TABLOCK（表锁） 此选项被选中时，SQL Server 将在整个表上置共享锁直至该命令结束。

这个选项保证其他进程只能读取而不能修改数据。

PAGLOCK（页锁） 此选项为默认选项， 当被选中时，SQL Server 使用共享页锁。

TABLOCKX（排它表锁） 此选项被选中时，SQL Server 将在整个表上置排它锁直至该命令或事务结束。

这将防止其他进程读取或修改表中的数据。