IReadWriteLock 介面

定義

命名空間:: Java.Util.Concurrent.Locks

組件:: Mono.Android.dll

重要

部分資訊涉及發行前產品，在發行之前可能會有大幅修改。 Microsoft 對此處提供的資訊，不做任何明確或隱含的瑕疵擔保。

A ReadWriteLock 維護一對對對 Lock locks，一個用於唯讀操作，一個用於寫入。

[Android.Runtime.Register("java/util/concurrent/locks/ReadWriteLock", "", "Java.Util.Concurrent.Locks.IReadWriteLockInvoker")]
public interface IReadWriteLock : Android.Runtime.IJavaObject, IDisposable, Java.Interop.IJavaPeerable

[<Android.Runtime.Register("java/util/concurrent/locks/ReadWriteLock", "", "Java.Util.Concurrent.Locks.IReadWriteLockInvoker")>]
type IReadWriteLock = interface
    interface IJavaObject
    interface IDisposable
    interface IJavaPeerable

衍生: Java.Util.Concurrent.Locks.ReentrantReadWriteLock

屬性: RegisterAttribute

實作: IJavaObject IJavaPeerable IDisposable

備註

A ReadWriteLock 維護一對對對 Lock locks，一個用於唯讀操作，一個用於寫入。 #readLock 讀取鎖可以同時由多個讀取執行緒持有，只要沒有寫入者。 #writeLock 寫入鎖定是獨佔的。

所有ReadWriteLock實作都必須保證操作（如介面writeLock所規定）對記憶體同步的影響Lock，對所對應readLock的也成立。也就是說，成功取得讀取鎖的執行緒會看到上一次寫鎖釋出時所做的所有更新。

讀寫鎖定允許存取共享資料時比互斥鎖更高的並發性。它利用了這樣一個事實：雖然一次只有一個執行緒（ <em>writer</em> thread）可以修改共享資料，但在許多情況下，任意數量的執行緒可以同時讀取資料（因此 <才有 em>reader</em> threads）。理論上，使用讀寫鎖所允許的並行性增加，將使效能相較於互斥鎖有所提升。實務上，這種並發性提升只有在多處理器上才能完全實現，且必須在共享資料的存取模式適合時才會實現。

讀寫鎖是否會比互斥鎖提升效能，取決於資料被讀取與修改的頻率、讀寫操作的持續時間，以及資料爭用情況——即同時嘗試讀寫資料的執行緒數量。例如，一個最初填充資料、之後很少被修改、但經常被搜尋的集合（例如某種目錄），是使用讀寫鎖的理想選擇。然而，如果更新變得頻繁，資料大部分時間都被完全鎖定，並行性幾乎沒有增加。此外，若讀取操作過短，讀寫鎖實作的開銷（本質上比互斥鎖更複雜）可能會主導執行成本，尤其許多讀寫鎖實作仍會將所有執行緒序列化為一小段程式碼。最終，只有分析與測量才能判斷讀寫鎖是否適合您的應用。

雖然讀寫鎖的基本操作很直接，但實作必須做出許多政策決策，這些決策可能會影響該在特定應用程式中讀寫鎖的效能。這些政策的例子包括： <ul><li>判斷在讀寫雙方同時等待時，當寫入者釋放寫入鎖時，決定是否授予讀取鎖或寫入鎖。作者偏好很常見，因為寫作通常會短且不頻繁。讀取器偏好較少見，因為若讀取器如預期頻繁且壽命長，可能導致寫入延遲較長。公平，或者說 &in-order”實作也成為可能。

<li>判斷在讀取器處於啟動狀態且寫入者等待時請求讀取鎖的讀取器，是否會獲得讀取鎖定。偏好讀取者可能會無限期延遲寫入者，而偏好寫入者則可能降低並行的可能性。

<判斷>鎖是否為重入：帶有寫入鎖的執行緒能否重新取得該鎖？它能在持有寫入鎖時取得讀取鎖嗎？讀取鎖本身是重入式的嗎？

<li>寫入鎖定能否降級為讀取鎖而不允許有寫入者介入？讀取鎖能否升級為寫鎖，優先於其他等待的讀取或寫入者？

</ul> 在評估某個實作是否適合你的應用程式時，你應該考慮這些因素。

已在1.5中新增。

Java 文件 java.util.concurrent.locks.ReadWriteLock。

本頁部分內容為基於 Open Source Project 所創建與分享的作品，並依授權條款所描述的使用進行修改。

屬性

名稱	Description
Handle	取得底層 Android 物件的 JNI 值。 (繼承來源 IJavaObject)
JniIdentityHashCode	回傳包裹實例的 `java.lang.System.identityHashCode()` 值。 (繼承來源 IJavaPeerable)
JniManagedPeerState	管理貴族的狀況。 (繼承來源 IJavaPeerable)
JniObjectReferenceControlBlock	A `ReadWriteLock` 維護一對對對 `Lock locks`，一個用於唯讀操作，一個用於寫入。 (繼承來源 IJavaPeerable)
JniPeerMembers	成員存取與召喚支援。 (繼承來源 IJavaPeerable)
PeerReference	回傳JniObjectReference包裹後的 Java 物件實例。 (繼承來源 IJavaPeerable)

方法

名稱	Description
Disposed()	當實例被處理後才被召喚。 (繼承來源 IJavaPeerable)
DisposeUnlessReferenced()	如果沒有未解決的參考資料，則 `Dispose()`呼叫;否則，則不做任何事。 (繼承來源 IJavaPeerable)
Finalized()	當實例完成後才會被通知。 (繼承來源 IJavaPeerable)
ReadLock()	還回用於閱讀的鎖。
SetJniIdentityHashCode(Int32)	將回傳的值設為 `JniIdentityHashCode`。 (繼承來源 IJavaPeerable)
SetJniManagedPeerState(JniManagedPeerStates)	A `ReadWriteLock` 維護一對對對 `Lock locks`，一個用於唯讀操作，一個用於寫入。 (繼承來源 IJavaPeerable)
SetPeerReference(JniObjectReference)	將回傳的值設為 `PeerReference`。 (繼承來源 IJavaPeerable)
UnregisterFromRuntime()	取消註冊此實例，讓執行時不會在未來 Java.Interop.JniRuntime+JniValueManager.PeekValue 的呼叫中回傳該實例。 (繼承來源 IJavaPeerable)
WriteLock()	還原用於書寫的鎖。

擴充方法

名稱	Description
GetJniTypeName(IJavaPeerable)	取得實例 `self`類型的 JNI 名稱。
JavaAs<TResult>(IJavaPeerable)	試著強制`self`輸入 `TResult`，檢查強制在 Java 端是否有效。
JavaCast<TResult>(IJavaObject)	執行 Android 執行時檢查型別轉換。
JavaCast<TResult>(IJavaObject)	A `ReadWriteLock` 維護一對對對 `Lock locks`，一個用於唯讀操作，一個用於寫入。
TryJavaCast<TResult>(IJavaPeerable, TResult)	試著強制`self`輸入 `TResult`，檢查強制在 Java 端是否有效。

適用於