我在許多關于可重入鎖的教程中看到,他們創建了一個新的可重入鎖并注入了資源,在 try/finally 塊中呼叫了可重入鎖的鎖定和解鎖。我不明白這個鎖和執行緒中使用的資源之間的聯系。下面是一個關于可重入鎖的教程示例
資源代碼
public class Resource {
public void doSomething(){
//do some operation, DB read, write etc
}
public void doLogging(){
//logging, no need for thread safety
}
}
執行緒宣告代碼中使用的資源
public class ConcurrencyLockExample implements Runnable{
private Resource resource;
private Lock lock;
public ConcurrencyLockExample(Resource r){
this.resource = r;
this.lock = new ReentrantLock();
}
@Override
public void run() {
try {
if(lock.tryLock(10, TimeUnit.SECONDS)){
resource.doSomething();
}
} catch (InterruptedException e) {
e.printStackTrace();
}finally{
//release lock
lock.unlock();
}
resource.doLogging();
}
}
有人可以解釋一下這是如何防止多個執行緒同時訪問給定資源導致競爭條件的嗎???這個可重入鎖是在資源中創建物件級鎖還是類級鎖???
uj5u.com熱心網友回復:
在某種意義上,aReentrantLock既不是類級別的鎖,也不是物件級別的鎖。在更實際的意義上,它與它們中的任何一個相同。
真的,您應該忘記“類級別”和“物件級別”鎖定。這些不是有用的區別。
您可以將任何物件用作塊lock中的物件。synchronized(lock){...}“物件級別”鎖定僅僅意味著,在 a 的某個方法中class C,您選擇的物件是該類的一個實體;而“類級別”意味著您選擇使用C.class作為鎖定物件。
但是,您也可以使用其他物件*,并且synchronized(lock)無論您為lock.
* 這是經驗豐富的軟體開發人員經常使用的模式:
public class C {
private final Object lock = new Object();
public MyType myMethod(...) {
...
synchronized(lock) {
...
}
...
}
}
使用物件的原因private是某些使用類的客戶端代碼的作者C可能會使用實體C作為鎖。這不是一個聰明的主意,但沒有什么能阻止他們這樣做。如果兩個不同的作者選擇使用同一個物件作為鎖,可能會出現無法預料的互動(例如,在最壞的情況下,死鎖)。但是類的作者通過使用其他類無法訪問C的物件來避免這個問題。lock
轉載請註明出處,本文鏈接:https://www.uj5u.com/net/481904.html
上一篇:開放MP。兩個連續回圈的并行化
