Любой риск в AutoCloseable wrapper для java.util.concurrent.locks.Lock?

Question

С try-with-resource представлен на Java 7, я с удивлением обнаружил, что Lock не был доработан, чтобы быть AutoCloseable. Казалось, довольно простой, поэтому я добавил его себе следующим образом:

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

Это работает с AutoCloseableReentrantReadWiteLock класса и использование выглядит следующим образом:

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

Так как это кажется настолько простым и канонический использование авто -closing RAII Я думаю, что должна быть веская причина, по которой это не должно быть сделано. Кто-нибудь знает?

Answer 1

Это была большая дискуссия, когда try-with-resources было предложено в феврале/марте 2009 года

Джош Блох, автор предложения, сказал «This construct was designed for one thing and one thing only: resource management. It was not designed for locking.»

Там было отдельное предложение, чтобы покрыть замки отдельно, но ничего не получилось.

Я думаю, что основные причины блокировки не были покрыты были:

• не представляется возможным добавить методы интерфейса в Java 7
• производительности удар создания дополнительного объекта оболочки, реализованный правильный интерфейс
• философских возражений Lock быть другим видом ресурса из дескрипторов файлов (например, создание Lock не влечет за собой применение метода lock)

Вы можете сравнить все исторические арги-баржи на the archive page, например this thread.