Есть ли риск в оболочке AutoCloseable для 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
}        

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

Answer 1

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

Джош Блох, автор предложения, сказал: " Эта конструкция была разработана только для одной цели: для управления ресурсами. Она не была предназначена для блокировки".

Было отдельное предложение по отдельности закрывать замки, но оно никуда не делось.

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

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

Вы можете следить за всеми историческими событиями на странице архива, например, этой веткой.