1、新建一个表，插入1010000数据：
create table test(id int identity(1,1) ,name varchar(600))
go
insert into test
values(replicate('a',600));
go 1010000
create index idx_test_id on test(id)
2、新开一个会话（A），运行如下语句，由于没有提交，所以会阻塞其他要修改相同数据的会话：
begin tran
update test
set name = replicate('f',500)
where id = 100000
3、再新开一个会话（B），运行如下语句，由于需要修改id为 100000的数据，所以被上一个会话A阻塞了。
需要特别注意的是，在语句中使用了查询提示repeatableread，那么select语句对记录获取的S锁，只有在commit或rollback时，才会释放。
begin tran select * from test with(repeatableread) where id >= 9000 and id <= 100000 select sysdatetime()
4、再开一个会话（C），运行如下语句，由于需要修改id为100000的数据，所以被会话A阻塞了
begin tran
update test
set name = replicate('k',589)
where id = 100000
select sysdatetime()
5、在会话A中，通过commit来提交事务，这个时候，会话B会马上返回结果，但会话C还是继续被阻塞，这个时候C被B会话阻塞。
接下来，在会话B中执行commit，于是会话C立即返回。
从以上的现象大致能看出，数据库锁中的队列机制，也就是当很多会话都需要访问相同的资源时，会有一个队列机制，一开始A对资源加上独占锁，获取到资源，但没有提交，所以没有释放资源上的锁。
会话B也需要访问相同的资源，由于会话需要读数据，所以需要加上共享锁，但由于共享锁和之前资源上的独占锁，不兼容，就导致了会话B被阻塞住了，那么会话B就进入到一个等待队列里。
会话C也需要访问相同的资源，由于需要修改数据，所以需要加上独占锁，但于会话A已加上的独占锁，不兼容，于是会话C也被阻塞住了，那么会话C也会进入到等待队列中，排在会话B之后。
会话C被阻塞的原因：
从上图可以看出，会话C在把Page 1 ：21339上的IU锁改为IX锁时，没有grant，而是处于convert状态，之所要修改，是因为需要修改id为100000的数据。
而之前已经在1 ：21339上加了IU锁，在RID 1:21339:1 上加了U锁，要修改这个这个页中的数据，必须要把IU锁修改为IX锁，如果成功，那么继续把U锁修改为X锁。
从上述分析中，可以看出SQL Server中的锁采用是队列的机制，即先进先出。