單個java信號量的死鎖？

在我最近的一個答案，我給了限制訪問的理論信號燈爲例，內存資源：單個java信號量的死鎖？

public static byte[] createArray(int size) throws InterruptedException { 
    semaphore.acquire(size); 
    return new byte[size]; 
} 
public static void releaseArray(byte[] array) { 
    semaphore.release(array.length); 
}

我覺得這可能是僵局的來源如果分配交織不好：

semaphore = new Sempaphore(30, true); 
// T1         T2 
//--------------------------   ---------------------- 
a1 = createArray(10);           // 20 
             a3 = createArray(10);  // 10 
a2 = createArray(15);           // wait 
             a4 = createArray(15);  // wait 
// ...        // ... 
releaseArray(a1);      releaseArray(a3); 
releaseArray(a2);      releaseArray(a4);

我的觀察是否正確？如果是，我該如何避免這種情況（例如定時等待和回滾）？

來源

2009-07-30 akarnokd

是的，使用Semaphore.tryAcquire(permits, timeout, timeUnit)將是明智的做法。顯然你必須小心地釋放信號量在finally區塊以避免泄漏...

來源

2009-07-30 09:23:48

謝謝。我更感興趣的是如何在異常情況下進行回滾 - 在示例情況下，它很容易，只需釋放並返回到第1行並重試即可。但是，當線程內分配更加遠離時（例如，封裝昂貴的計算），我擔心這也無濟於事。也許我應該回到更粗糙的粒度鎖定模式？ – akarnokd 2009-07-30 09:30:09

單個java信號量的死鎖？

回答

相關問題