【IT168 技术】Mutex是Oracle从10g开始使用的一种数据结构，与latch极其类似，也是用于SGA内存结构的并发访问控制。在10g中，Mutex主要用于保护Cursor相关的内存结构，Parent Cursor, Child Cursor , Cursor Stat，同时兼有Pin Cursor的并发访问控制作用。

　　而从11g开始，Mutex又代替了library cache latch等多个与library cache相关的latch。

　　Mutex与latch相比，有哪些优点?我个人认为最重要的有2点：

　　Mutex通常在被保护对象内部，这样mutex的数量就多了很多，争用就更少。比如11g中，每一个Latch Latch Hash Bucket由一个mutex保护，而bucket数量高达131072，相比library cache latch最多只有67个child latch，数量上多了很多。很显然，分布在131072个Mutex上的竞争比67个Library cache latch上的竞争少得多。

　　Mutex从结构上来讲比latch更多简单，整个Mutex只有十几个字节，而Oracle在对Latch的结构优化和精简的情况下最少也有100多个字节。这样更小的结构意味着在处理Mutex时也只需要更少的指令，而更快。

　　Mutex代替Cursor上的library cache pin，比library cache pin更有效率。

　　本文主要描述如何通过system state dump来分析mutex的等待，因此对Mutex的工作机制以及相应的等待事件详解不做过多介绍。有机会我会在另外的文章中专门来讲这两部分。

　　我们来分析的system state dump来源于一个朋友，他的系统里面出现大量的’cursor: pin S wait on X’和’cursor: Mutex X’等待事件。他将产生的system state dump发给我，以分析出产生问题的root cause。由于system state dump比较在在，同时里面涉及的一些内容不适合放在网上，因此本文只给出分析过程，没有上传trace文件。数据库的版本是11.1.0.7。

　　首先试图找到’cursor: pin S wait on X’等待的阻塞进程，随便找到一个等待cursor:pin S wait on X的会话，在dump trace 文件中查找waiting for ‘cursor: pin S wait on X’：