Jakiekolwiek ryzyko w opakowaniu z możliwością automatycznego zamykania dla java.util.concurrent.locks.Lock?

Question

Wraz z try-with-resource wprowadzonym w języku Java 7, byłem zaskoczony, że Lock nie został doposażony jako AutoCloseable. Wydawało się dość proste, więc dodałem mu się następująco:

class Lock implements AutoCloseable { 
    private final java.util.concurrent.locks.Lock _lock; 
    Lock(java.util.concurrent.locks.Lock lock) { 
     _lock = lock; 
     _lock.lock(); 
    } 
    @Override 
    public void close() { 
     _lock.unlock(); 
    } 
} 

Działa to z klasą AutoCloseableReentrantReadWiteLock i używanie jest w następujący sposób:

try (AutoCloseableReentrantReadWiteLock.Lock l = _lock.writeLock()) { 
    // do something 
}   

Ponieważ wydaje się tak proste i kanoniczny Zastosowanie auto zamykanie RAII Myślę, że musi być dobry powód, aby tego nie robić. Ktoś wie?

Answer 1

To była wielka debata gdy try-with-resources został zaproponowany w luty/marzec 2009.

Josh Bloch, autor wniosku, że „This construct was designed for one thing and one thing only: resource management. It was not designed for locking.”

Był tam osobny wniosek na pokrycie zamki oddzielnie, ale nigdzie się to nie udało.

myślę głównych powodów zamki nie były objęte zostały:

nie
• możliwe dodanie metody do interfejsu w Javie 7
• wydajność trafienie tworzenia dodatkowego otoki obiekt, który realizowany poprawny interfejs
• zastrzeżenia filozoficzne do Lock są innym rodzajem zasobu z uchwytów plików (np. Utworzenie Lock nie pociąga za sobą wywołania metody lock)

Możesz śledzić wszystkie historyczne argy-bargy na the archive page, na przykład this thread.