Library Cache Lock是一种DDL锁，是Parse锁，维持着对象间的依赖关系，所以在执行时，所有依赖的对象都要等待。
session 1 执行 truncate table a， session 2 执行select *from a ，如果session 2 在session 之后执行，会发现等待时间 Library Cache Lock。因为 a表属于Library Cache Object中的一部分。
truncate table a执行时，整段sql是一个LibraryCache Object，受到LibraryCache lock的保护.
LibraryCache PIN 主要出现在修改Stored Procedure时.
在Oracle数据库中，如果运行一个SQL语句或者Stored Procedure，首先需要将它们加载到Shared Pool的Library Cache中，而这些对象也称之为Library Cache Object。
执行或者修改这些Library Cache Object时，会经历以下阶段。拿一个存储过程来举例说明，我们先来看执行时的情况：
1、首先，这个LibraryCache Object会获得一个Library Cache Lock，这个锁的mode=1，也就是NULL锁。如下：
ADDR KGLLKHDL KGLLKMOD KGLLKREQ KGLLKFLG
00002B4BD2F556F8 000000012FFD6F20 1 0 2
2、在获得了Library Cache Lock之后，这个对象会尝试获得Library Cache Pin。因为是执行，所以mode=2，也就是Row Share锁。如下：
ADDR KGLPNHDL KGLPNMOD KGLPNREQ KGLPNFLG
00002B4BD2F55D30 000000012FFD6F20 2 0 8
3、执行后，这个对象上的Library Cache Bin会释放。
12:00:19 SQL> select addr, kglpnhdl, kglpnmod,kglpnreq, kglpnflg from x$kglpn where kglpnhdl = '000000012FFD6F20';
no rows selected
4、因为Library Cache Lock是一种DDL锁，是Parse锁，维持着对象间的依赖关系，所以执行后仍然存在。只不过x$kgllk上的kgllkflg被reset为0。
ADDR KGLLKHDL KGLLKMOD KGLLKREQ KGLLKFLG
00002B4BD2F555A0 000000012FFD6F20 1 0 0
以上是执行一个Library Cache Object的过程。如果要对一个Library Cache Object进行修改，过程是类似的，但获取锁的模式会有不同。因为较难单独模拟，这里就不给出例子，只是做过程说明，后面会和执行的情况一起来模拟锁等待的情况。