ILock 介面
定義
重要
部分資訊涉及發行前產品,在發行之前可能會有大幅修改。 Microsoft 對此處提供的資訊,不做任何明確或隱含的瑕疵擔保。
Lock 實作提供的鎖定操作比方法 synchronized 和語句所能達成的更廣泛。
[Android.Runtime.Register("java/util/concurrent/locks/Lock", "", "Java.Util.Concurrent.Locks.ILockInvoker")]
public interface ILock : Android.Runtime.IJavaObject, IDisposable, Java.Interop.IJavaPeerable
[<Android.Runtime.Register("java/util/concurrent/locks/Lock", "", "Java.Util.Concurrent.Locks.ILockInvoker")>]
type ILock = interface
interface IJavaObject
interface IDisposable
interface IJavaPeerable
- 衍生
- 屬性
- 實作
備註
Lock 實作提供的鎖定操作比方法 synchronized 和語句所能達成的更廣泛。 它們允許更靈活的結構,可能具有截然不同的特性,並可能支援多個相關 Condition 物件。
鎖是一種用來控制多個執行緒對共享資源存取的工具。 通常,鎖提供對共享資源的專屬存取:一次只能有一個執行緒取得該鎖,且所有對共享資源的存取都必須先取得該鎖。 然而,有些鎖可能允許同時存取共享資源,例如某個 ReadWriteLock的讀取鎖。
使用 synchronized 方法或語句可存取每個物件所關聯的隱含監控鎖,但強制所有鎖的取得與釋放必須以區塊結構方式進行:當取得多個鎖時,必須以相反順序釋放,且所有鎖必須在取得時的相同詞彙範圍內釋放。
雖然方法與語句的範圍機制 synchronized 讓使用監視鎖的程式設計變得容易許多,也有助於避免許多常見的鎖相關程式錯誤,但有時你仍需要以更靈活的方式操作鎖。 例如,一些同時瀏覽資料結構的演算法需要使用 ”hand-to-hand”或 ”chain locking“:你先取得節點 A 的鎖,再取得節點 B,然後釋放 A 並取得 C,接著釋放 B 並取得 D,依此類推。 介面 Lock 的實作允許在不同範圍內取得與釋放鎖,並允許以任意順序取得與釋放多個鎖,從而使用此類技術。
隨著彈性增加,也帶來了更多責任。 缺乏區塊結構鎖定,消除了方法 synchronized 與語句自動釋放鎖的功能。 在大多數情況下,應使用以下成語:
{@code
Lock l = ...;
l.lock();
try {
// access the resource protected by this lock
} finally {
l.unlock();
}}
當鎖定與解鎖發生在不同範圍內時,必須注意確保所有在鎖被持有期間執行的程式碼都以 try-finally 或 try-catch 保護,以確保鎖在必要時能被釋放。
Lock實作在方法與語句使用上提供額外功能synchronized,例如提供非阻塞的嘗試取得鎖#tryLock()()、嘗試取得可中斷的鎖(#lockInterruptibly以及可逾時的嘗試取得鎖)。#tryLock(long, TimeUnit)
類別 Lock 也可以提供與隱含監控鎖截然不同的行為與語意,例如保證排序、非重入使用或死鎖偵測。 如果實作提供了這些專門語意,那麼實作必須記錄這些語意。
請注意, Lock 實例只是一般物件,且本身可以作為陳述中的 synchronized 目標。 取得實例的監視鎖 Lock 與呼叫該實例的任何 #lock 方法並無明確關聯。 建議為避免混淆,除非在實例本身的實作中,否則不要以此方式使用 Lock 實例。
除非另有說明,傳遞null任何參數的值都會導致拋出。NullPointerException
<h2>記憶體同步</h2>
所有Lock實作 <em>must</em> 強制執行與內建監控鎖所提供的相同記憶體同步語意,詳見 cite<第17>章 Java 語言規範</引用>:<ul><li>成功的lock操作具有與成功 <em>Lock</em> 動作相同的記憶體同步效果。
<li>成功的 unlock 操作具有與成功 <em>Unlock</em> 動作相同的記憶體同步效果。
</ul>
未成功的鎖定與解鎖操作,以及重入鎖定/解鎖操作,則不需要任何記憶體同步效果。
<h2>實作考量</h2>
三種鎖定擷取方式(可中斷、不可中斷及定時鎖定)可能在效能特性、排序保證或其他實作特性上有所不同。 此外,在特定<類別中可能無法中斷 >em<進行>中或 emLock 獲取鎖定的過程。 因此,實作不必為三種鎖取得形式定義完全相同的保證或語意,也不必支援持續中斷鎖定取得。 實作必須清楚記錄每種鎖定方法所提供的語意與保證。 同時也必須遵守此介面中定義的中斷語意,只要支援鎖獲取中斷:這要麼是完全中斷,要麼僅在方法輸入時中斷。
由於中斷通常意味著取消,且中斷檢查通常不頻繁,實作可能偏好對中斷的回應而非一般方法回傳。 即使可以證明中斷發生在另一個動作可能解除阻塞之後,這點依然成立。 實作應該記錄這種行為。
已在1.5中新增。
Java 文件 java.util.concurrent.locks.Lock。
本頁部分內容為基於 Open Source Project 所創建與分享的作品,並依授權條款所描述的使用進行修改。
屬性
| 名稱 | Description |
|---|---|
| Handle |
取得底層 Android 物件的 JNI 值。 (繼承來源 IJavaObject) |
| JniIdentityHashCode |
回傳包裹實例的 |
| JniManagedPeerState |
管理貴族的狀況。 (繼承來源 IJavaPeerable) |
| JniObjectReferenceControlBlock |
|
| JniPeerMembers |
成員存取與召喚支援。 (繼承來源 IJavaPeerable) |
| PeerReference |
回傳JniObjectReference包裹後的 Java 物件實例。 (繼承來源 IJavaPeerable) |
方法
| 名稱 | Description |
|---|---|
| Disposed() |
當實例被處理後才被召喚。 (繼承來源 IJavaPeerable) |
| DisposeUnlessReferenced() |
如果沒有未解決的參考資料,則 |
| Finalized() |
當實例完成後才會被通知。 (繼承來源 IJavaPeerable) |
| Lock() |
取得鎖。 |
| LockInterruptibly() |
除非目前執行緒被 Thread#interrupt 中斷,否則會取得鎖。 |
| NewCondition() |
回傳一個 |
| SetJniIdentityHashCode(Int32) |
將回傳的值設為 |
| SetJniManagedPeerState(JniManagedPeerStates) |
|
| SetPeerReference(JniObjectReference) |
將回傳的值設為 |
| TryLock() |
只有在召喚時鎖是空的,才能獲得該鎖。 |
| TryLock(Int64, TimeUnit) |
若在指定等待時間內鎖空閒且當前執行緒未被 Thread#interrupt 中斷,則會取得該鎖。 |
| Unlock() |
釋放鎖。 |
| UnregisterFromRuntime() |
取消註冊此實例,讓執行時不會在未來 Java.Interop.JniRuntime+JniValueManager.PeekValue 的呼叫中回傳該實例。 (繼承來源 IJavaPeerable) |
擴充方法
| 名稱 | Description |
|---|---|
| GetJniTypeName(IJavaPeerable) |
取得實例 |
| JavaAs<TResult>(IJavaPeerable) |
試著強制 |
| JavaCast<TResult>(IJavaObject) |
執行 Android 執行時檢查型別轉換。 |
| JavaCast<TResult>(IJavaObject) |
|
| TryJavaCast<TResult>(IJavaPeerable, TResult) |
試著強制 |