lock and latch
在oracle中为了保护共享资源，使用了两种不同的锁机制lock和latch，这两种锁有明显不同点：
1，lock和pin，采用的是队列的方式，先来先服务的策略，latch和mutex，采用的是抢占的方式，fast
fail模式
2，lock可以hold的时间比较长，而latch时间会非常的短
3，lock主要用户锁定对象，面向用户，latch主要锁定的是内存，面向系统
理解这两种锁的设计思想，可以应用在实际的生产过程中，首先：
1，这两种锁的粒度不同，一个粒度粗，一个粒度细
2，根据不同的场景，设计适合场景的锁机制
因为latch保护的内存中的数据，而数据的组织oracle使用了多种方式：
1，array
主要使用固定长度的对象的集合，这样可以直接定位到任意对象的地址，在空间的分配上，
可以一次分配定长或者递增长度的chunk。
2，linked list
这里可以是单向的链表，或者双向的链表，linked list是比较常用的结构，比如index中的leaf block。
linked
list可以组织成FIFO的队列，也可以组织成LIFO的堆栈。
3，B 树
B数数据结构，是oracle在index中使用的方式，查找的效率和数的高度有关。\
4，hash table
在数据量比较小的时候，可以使用array或者linked List，但是，当数据量比较大的时候，查找的时间效率上，hash
table会更有效率，时间复杂度是O(1)。
在对目前常用的数据结构中，对于查询而言，有三种方式效率比较高：
1，二分查找
这需要数据时有序的，
2，B
树查找
在大并发的修改情况下，会有瓶颈
3，hash表
查找的效率是O（1），比较适合大并发的修改情况下使用
所以，在oracle中，对大量小的内存空间的并发管理上，通常使用hash
table数据结构。
hash的主要思想是：
设定一个固定的数量的bucket（通常是2的幂次方），然后对对象应用hash函数，映射到其中的一个bucket当中。
但bucket的数量，hash算法等会影响到管理和使用的开销。
这里有几个原则：
1，不同的对象可能映射到同一个bucket中
2，同一个bucket中不能有太多的对象
3，hash算法尽量要是对象分布均衡
对于每一个bucket中，多个对象使用linked list进行组合，例如library cache中的对象，包括两个结构，
hash
bucket，hash chain。
这里对oracle的阻塞的概念做一个解释：
1，多版本一致，读写互不阻塞
这是对用户而言，在data
level，在使用oracle时，访问和修改数据可以做到，读读不阻塞，读写不阻塞，写写阻塞，因为oracle使用undo机制实现了多版本一致性
2，内存结构，互相阻塞
对于oracle的内存结构，在raw
memory
level，使用latch的方式，写是独占锁，读是共享锁，实现了读读不阻塞，读写阻塞，写写阻塞的方式。所以对于latch而言，获取和释放latch的速度要非常快，以减少更改内存结构的过程中，对读的阻塞。
所以，通常的应用设计过程中，第一种更多是对热点数据的修改争用，造成的enqueue，相比较而言，对应用服务器的可扩展性和并发能力产生很大的影响，而第二种可能是应用设计的不合理，而latch对oracle数据库系统的并发能力和可扩展性的影响更大，因为其不能做到读写互不阻塞，并发能力大大减弱。
latch：
1，本质：
latch的本质其实是信号量，使用内存的一个地址进行存储，并对信号量进行一系列的原子操作。在多用户系统下，原子操作意味着其不会被进程的调度所中断，
在原子操作的生命周期会完全占有cpu，在多cpu的架构上，通过独占内存总线来实现原子操作。
在oracle中，latch分为exclusive和shared模式，在reader和write的逻辑处理上，有两种模型：
1，check and
change
首先writer去check信号量的值，发现为zero，就去修改，然后就相当于获得了latch，就可以修改latch所保护的对象了。这里包含了两个操作，一个是check，
一个是change，当处在多线程处理中，或者多cpu架构中，就会破坏一致性。
2，compare and
swap
设置一个flag，使用寄存器保存信号量的值，当flag没有被设置的时候，writer设置flag，这时开始阻塞了reader再去更改信号量，writer开始不停的compare两个，
当值相等的时候，即reader已经释放完shared
latch的时候，writer就可以独占latch了。
2，latch统计
当session获取latch的过程中，如果重试，在重试一定次数的时候，进入sleep，这时并不像enqueue一样，会有FIFO管理队列来管理阻塞的情况，直到被唤醒。
而因为获取latch而sleep的session会被os
offline cpu的运行队列中，进入wait list。然后会被被唤醒重试。
3，latch scalability
这里主要是两个方面，latch的数量和latch获得的时间：
1. latch数量：这里是一个平衡点，latch数量少，你们一个latch管理的恭喜主要就比较多，会产生严重的争用，但当为每一个恭喜主要分配一个latch的时候，系统管理latch的开销又会大幅升高。所以针对library cache中hash bucket，oracle通常设置了cpu_count个latch来管理，在oracle 11g中，采用了mutexes来替代latch来管理部分latch，即针对每一个object分配一个mutex，这样大大减少了争用。
2. latch时间：latch hold的时候尽可能的要短，减少争用。