Java Sonar / FindBugs-多線程正確性

Question

聲納報告以下問題：

Multithreaded correctness - Method does not release lock on all
exception paths findbugs : UL_UNRELEASED_LOCK_EXCEPTION_PATH
This method acquires a JSR-166 (java.util.concurrent) lock, but does not release it on all exception paths out of the method. In general, the correct idiom for using a JSR-166 lock is:  



Lock l = ...;
l.lock();
try {
    // do something
} finally {
    l.unlock();
}

在此代碼段中：

   public synchronized void put(T element) throws PreconditionException {
        Precondition.notNull(element, "Nullobject is not allowed");
        lock.lock();
        try {
            buffer[writeIndex++] = element;
            if (writeIndex >= capacity) {
                writeIndex = 0;
            }
            if (size.get() >= capacity) {
                // buffer is full
                readIndex++;
                lastOverflow.set(System.currentTimeMillis());
                if (readIndex >= capacity) {
                    readIndex = 0;
                }
                return;
            }
            size.incrementAndGet();
        } finally {
            try {
                notEmpty.signal();
            } catch (Exception e) {
               e.printStackTrace();
            }
            lock.unlock();
        }
    }

我不明白，出於什么原因，這不安全嗎？

Answer 1

我認為這表明，因為如果您的代碼在notEmpty.signal();行上引發了Throwable的另一個子類（例如Error notEmpty.signal(); 那么該鎖將不會被釋放。

您可以說，如果出現錯誤，則應用程序將關閉，或者捕獲Exception是在此代碼中正確的操作。 我確實同意這一點，但是正如FindBugs所說的那樣，有一些代碼路徑最終導致該鎖沒有被釋放...並且沒有什么阻止開發人員擴展Throwable：'（。

Answer 2

您可以為解鎖添加一個finally，以確保它被調用，這與可能導致嘗試捕獲的異常路徑形成對比。

此外，如您所知，捕獲異常並僅將其記錄下來不應該保留用於生產。

} finally {
            try {
                notEmpty.signal();
            } catch (Exception e) {
               e.printStackTrace();
            }
            finally {
               lock.unlock();
            }
        }