实现锁的方式就是排队咯，那么排队就是有enqueue这么个结构来管理 管理锁的结构叫队列，即enqueue
所有和enqueue相关的函数都叫KSQ-- kernal service enqueue
lock是从应用层面看到的锁，enqueue是oracle内部管理锁的一个结构。
可以用v$lock_type这个视图的type和description字段去看AWR中看到的锁类型和解释，也可以去看看这些锁的id1_tag和id2_tag是啥意思
锁描述可以忽略，咱们看锁模式就可以
锁与锁之间可以共享资源的表格(红色的表示持有者，黄色的表示申请者)
比如有个用户在一个对象资源上持有4级锁(S)，另一个用户如果申请1级2级和4级锁则都可以共享，别的就不允许了。
下面通过一个流程来解释
首先有一个TM-432-0的锁资源，有个S1的会话在这个上面持有一个S锁，这个时候S2会话想在这个锁资源上申请一个X锁，由于4级锁和6级锁不共享，因此S2会话只能在waiters队列等待，然后S1的会话这个时候做完了S锁的事务想升级成X锁，就会在converters队列做一个升级，在S1会话的S锁释放后，converters队列S1的X锁就会立马被owners列通知去持有TM-432-0的锁资源(因为oracle一定是先扫描convert队列，在扫描waiter，此时S1的S锁已经升级成了X锁，并且只有X锁了，原来的S锁已经没了)，这个时候S3和S4的会话也想在持有S锁，但是由于被S2的X锁申请给堵塞了，所以只能在waiters队列等待。
在S1的X锁也释放后，oracle去扫描converters队列发现是空的，就去waiters队列里扫描，把排在第一个的S2会话的X锁持有TM-432-0的锁资源，在等到S2会话X锁释放后，owners列就会去通知S3和S4去持有S锁(因为4级锁和4级锁可以共享，此时这个锁资源就会有两个owner)。
在上述过程中产生的等待叫做enq等待，比如enq:TM contention，enq:TX contention
下面通过一个实验来验证：
session1：
SQL> conn test/oracle
Connected.
SQL> LOCK TABLE test IN SHARE MODE;
Table(s) Locked.
session2：
SQL> conn test/oracle
Connected.
SQL> LOCK TABLE test IN EXCLUSIVE MODE;
...(此时在等待)
session3和session4：
LOCK TABLE test IN SHARE MODE;
...(在等待S2的X锁)
session1(S锁convert成X锁)：
SQL> LOCK TABLE test IN EXCLUSIVE MODE;
Table(s) Locked.
session1发起commit或者rollback命令释放锁资源，session2发现就立刻持有了X锁：
s1:
SQL> commit;
Commit complete.
s2:
SQL> LOCK TABLE test IN EXCLUSIVE MODE;
Table(s) Locked.
session2释放X锁，session3和session4一起持有了S锁：
s2:
SQL> commit;
Commit complete.
s3,s4:
SQL> LOCK TABLE test IN SHARE MODE;
Table(s) Locked.
