为了程序能够编译通过和在设备中正常运行，主工程除了依赖第三方的工程和jar包之外，还需要依赖安卓系统本身的代码，也就是我们在sdk的每个版本中看到的android.jar，这里面集成了android的所有API，随着android sdk的升级，高版本的sdk中会增加很多新的API，比如ActionBar、Fragment、RecyclerView等，如果在低版本的sdk中需要使用高版本新增的API怎么办？不可能去更新移动设备中的android.jar吧，因为硬件设备集成的sdk版本是固定的，android.jar也是固定的，设备中的一些参数、硬件选型也是根据当前sdk版本来定的，所以最好的方式是将新增的API以依赖包的形式集成到需要使用高版本API的应用程序中。

    我之前曾经写过一篇Library cache内部机制详解，但是遗留了一些关于11g中mutex的改进的问题，最近因为有些11g的数据库频频发生mutex相关的等待事件，所以我又多这个问题做了一些探讨。关于Mutex，可以参考ORACLE mutex实现机制这篇文章，mutex是从10g开始引入的，在library cache中有大量的使用，它的主要作用有两个：一是用来替换library cache pin，二是作为更轻量级的latch使用。

    Library cache是Shared pool的一部分，它几乎是Oracle内存结构中最复杂的一部分，主要存放shared curosr（SQL）和PLSQL对象（function，procedure，trigger）的信息，以及这些对象所依赖的table，index，view等对象的信息。 Library cache需要解决三个问题： 1.快速定位的问题：Library cache中对象众多，Oracle如何管理这些对象，以便服务进程可以迅速找到他们需要的信息。比如某个服务进程需要迅速定位某个SQL是否存在于Library ...