http://www.ixora.com.au/q+a/0011/08200945.htm中有如下描述：
When an object has been located in (or loaded into) the library cache, the session "remembers" its location by maintaining a null mode lock on the object. When a session needs to use an object, if it already (or still) has the library cache lock, then it can proceed with the pin request. If it does not yet have a lock then a get operation is needed to get a lock before the pin can be requested.
This probably makes little sense unless you understand the distinction between the handle of a library cache object and its heaps. Locks protect the handle. Pins protect the heaps. The heaps are the "body" parts of the object that get loaded as required, except for heap 0 which contains the identifying information about the object. When we speak of an object being aged out and then reloaded, it is actually the heaps other than heap 0 of which we are speaking. Heap 0 is never aged out while any session is holding a lock on its handle.
The fundamental reason for the distinction between locks and pins is that it in theory allows an object's identity to be checked using a shared lock on the handle while another session has an exclusive pin on one or more of its heaps. The distinction is also important for maintaining cache coherence.
我對上述描述的理解：
get表示請求對象、獲得對象句柄；
pin根據句柄找到實際對象並執行，但對象內容可能因爲老化而pin不到所以出現reload；
一個session需要使用一個object時，如果是初次使用，則必然是先get然後pin並維護這個object的句柄。下次再使用這個object時，因爲已經維護該句柄，所以直接pin而沒有了get過程。如果對象老化則移除共享池，再次請求則會出現reload。