Qualche rischio in un wrapper AutoCloseable per java.util.concurrent.locks.Lock?

Question

Con try-with-resource introdotto in Java 7, sono stato sorpreso di vedere che lo Lock non è stato adattato per essere un AutoCloseable. Sembrava abbastanza semplice, così ho aggiunto io stesso come segue:

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(); 
    } 
} 

Questo funziona con una classe AutoCloseableReentrantReadWiteLock e il loro utilizzo è la seguente:

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

Dal momento che questo sembra così semplice e l'uso canonico di auto -closing RAII Penso che ci sia una buona ragione per non farlo. Qualcuno lo sa?

Answer 1

Questo è stato un grande dibattito quando try-with-resources è stato proposto nel febbraio/marzo 2009.

Josh Bloch, l'autore della proposta, ha detto che "This construct was designed for one thing and one thing only: resource management. It was not designed for locking."

C'era una proposta separata per coprire le serrature a parte, ma non è arrivato da nessuna parte.

Credo che i principali motivi serrature non sono stati coperti sono stati:

non
• possibile aggiungere i metodi per un'interfaccia in Java 7
• calo di prestazioni di creare un oggetto wrapper in più che ha implementato l'interfaccia corretta
• obiezioni filosofiche a Lock essere un diverso tipo di risorsa da handle di file (ad esempio, la creazione di un Lock non comporta richiamando il metodo lock)

È possibile seguire tutto lo storico argy-bargy su the archive page, ad esempio this thread.