首页 > 代码库 > Oracle core06_latch&lock
Oracle core06_latch&lock
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的时候尽可能的要短,减少争用。