Oracle Shared Pool读写并发及性能开销问题咨询

读写请求真的完全无法并发吗？ #

答案是否定的——Oracle并没有对整个Shared Pool加全局闩锁，而是采用了**闩锁细分（Latch Subsetting）**机制：它把Shared Pool拆分成多个独立的子区域，每个子区域对应一个专属闩锁。

• 只要读写请求对应的SQL哈希值落在不同的子闩锁区域，读写操作完全可以并行执行。
• 只有当多个请求命中同一个子闩锁区域时，才会触发读写互斥的规则。

所以你提到的10个写请求和1000个读请求，只要它们的目标子区域不重叠，大部分操作是同时进行的，不会完全被阻塞。

会不会导致过高的性能开销？ #

正常负载下不会，核心原因有两个：

• 闩锁持有时间极短：不管是解析SQL写入Shared Pool，还是读取共享游标，都是毫秒级甚至微秒级的操作，闩锁竞争的时间窗口非常小。
• 自适应的细分与哈希机制：Oracle会根据系统负载自动调整闩锁细分的数量，哈希算法会尽量把不同SQL分散到不同子区域，从根源上降低冲突概率。
  只有在极端场景下（比如大量重复解析相同SQL、Shared Pool配置过小导致频繁换出），才会出现显著的闩锁竞争，进而引发性能瓶颈。

写入SQL1同时读取SQL2会有什么问题？ #

分两种情况：

• 如果SQL1和SQL2的哈希值落在不同子闩锁区域：完全没影响，两者并行执行，互不干扰。
• 如果落在同一个子闩锁区域：
  • 写操作（解析SQL1并写入Shared Pool）会持有排他模式的闩锁，此时读SQL2的请求会被短暂阻塞，直到写操作释放闩锁；
  • 反过来，如果读SQL2的请求先拿到共享模式闩锁，写SQL1的请求会被阻塞。
    但这种阻塞都是极短时间的，不会造成长期性能问题，除非出现持续的高频冲突场景。

内容的提问来源于stack exchange，提问作者Blocked