Locks AutoCloseable？

时间：2011-08-06 08:46:36

标签： java resources java-7 resource-management locks

Locks AutoCloseable？也就是说，而不是：

Lock someLock = new ReentrantLock();
someLock.lock();
try
{
    // ...
}
finally
{
    someLock.unlock();
}
我可以说：

try (Lock someLock = new ReentrantLock())
{
    someLock.lock();
    // ...
}
在Java 7中

？

11 个答案:

答案 0 :(得分：47)

我正在考虑自己这样做并做了类似的事情：

public class CloseableReentrantLock extends ReentrantLock implements AutoCloseable { 
   public CloseableReentrantLock open() { 
      this.lock();
      return this;
   }

   @Override
   public void close() {
      this.unlock();
   }
}

然后将其作为课程的用法：

public class MyClass {
   private final CloseableReentrantLock lock = new CloseableReentrantLock();

   public void myMethod() {
      try(CloseableReentrantLock closeableLock = lock.open()) {
         // locked stuff
      }
   }
}

答案 1 :(得分：19)

不，Lock接口（也不是ReentrantLock类）都没有实现AutoCloseable接口，这是使用新的try-with-resource语法所必需的。

如果你想让它工作，你可以编写一个简单的包装器：

public class LockWrapper implements AutoCloseable
{
    private final Lock _lock;
    public LockWrapper(Lock l) {
       this._lock = l;
    }

    public void lock() {
        this._lock.lock();
    }

    public void close() {
        this._lock.unlock();
    }
}

现在您可以编写如下代码：

try (LockWrapper someLock = new LockWrapper(new ReentrantLock()))
{
    someLock.lock();
    // ...
}

我认为你最好坚持使用旧的语法。让锁定逻辑完全可见是更安全的。

答案 2 :(得分：5)

通用ReentrantLock既不实现也不提供任何实现try-with-resources语句所必需的office.js接口的东西。但是，这个概念对Java API来说并不完全陌生，因为FileChannel.lock()提供了这种功能。

到目前为止给出的答案共享具有一些问题的解决方案，例如在每次锁定调用上创建不必要的对象，暴露容易出错的API或在获取锁定之后但在输入try-finally之前风险失败。 / p>

Java 7 解决方案：

AutoCloseable

使用lambda：

的Leaner Java 8 解决方案 
public interface ResourceLock extends AutoCloseable {

    /**
     * Unlocking doesn't throw any checked exception.
     */
    @Override
    void close();
}

public class CloseableReentrantLock extends ReentrantLock {

    private final ResourceLock unlocker = new ResourceLock() {
        @Override
        public void close() {
            CloseableReentrantLock.this.unlock();
        }
    };

    /**
     * @return an {@link AutoCloseable} once the lock has been acquired.
     */
    public ResourceLock lockAsResource() {
        lock();
        return unlocker;
    }
}

演示：

public class CloseableReentrantLock extends ReentrantLock {

    /**
     * @return an {@link AutoCloseable} once the lock has been acquired.
     */
    public ResourceLock lockAsResource() {
        lock();
        return this::unlock;
    }
}

答案 3 :(得分：4)

try-with-resource适用于在try-block离开时创建和销毁的资源。它不适用于需要保持活力的资源。每次使用时都不会创建和销毁锁。它们保持活着，只是锁定和解锁。这就是为什么它们不是AutoClosable。

正如其他人已经建议的那样，可以使用try-with-resource块创建和销毁包装器，并在创建和销毁时进行锁定和解锁。

答案 4 :(得分：2)

没有完美的解决方案，除非你忽略了分配成本（大多数应用程序员可以，但锁库编写者不能）。然后你可以使用包装器

@RequiredArgsConstructor(access=AccessLevel.PRIVATE)
public final class MgLockCloseable implements AutoCloseable {
    public static MgLockCloseable tryLock(Lock lock) {
        return new MgLockCloseable(lock.tryLock() ? lock : null);
    }

    public static MgLockCloseable lock(Lock lock) {
        lock.lock();
        return new MgLockCloseable(lock);
    }

    @Override public void close() {
        if (isLocked()) {
            lock.unlock();
        }
    }

    public boolean isLocked() {
        return lock != null;
    }

    @Nullable private final Lock lock;
}

在这个构造中

try (LockCloseable lockCloseable = LockCloseable.lock(lock)) {
    doSomethingUnderLock();
} // automatic release

另请参阅我的question on CR。

答案 5 :(得分：1)

将@skoskav的Java8解决方案扩展到ReentrantReadWriteLock：

public interface ResourceLock extends AutoCloseable {
    /**
     * Unlocking doesn't throw any checked exception.
     */
    @Override
    void close();
}    

public class CloseableReentrantRWLock extends ReentrantReadWriteLock {

    /**
     * @return an {@link AutoCloseable} once the ReadLock has been acquired
     */
    public ResourceLock lockRead() {
        this.readLock().lock();
        return () -> this.readLock().unlock();
    }

     /**
     * @return an {@link AutoCloseable} once the WriteLock has been acquired.
     */
    public ResourceLock lockWrite() {
        this.writeLock().lock();
        return () -> this.writeLock().unlock();
    }
}

答案 6 :(得分：0)

public class AutoCloseableLockWrapper implements AutoCloseable, Lock{
    private final Lock lock;
    public AutoCloseableLockWrapper(Lock l) {
        this.lock = l;
    }
    @Override
    public void lock() {
        this.lock.lock();
    }

    @Override
    public void lockInterruptibly() throws InterruptedException {
        lock.lockInterruptibly();
    }

    @Override
    public boolean tryLock() {
        return lock.tryLock();
    }

    @Override
    public boolean tryLock(long time, TimeUnit unit) throws InterruptedException {
        return lock.tryLock(time,unit);
    }

    @Override
    public void unlock() {
        lock.unlock();
    }

    @Override
    public Condition newCondition() {
        return lock.newCondition();
    }
    @Override
    public void close() {
        this.lock.unlock();
    }
}

答案 7 :(得分：0)

考虑user2357112's shrewd advice：

public class CloseableLock {

  private class Unlocker implements AutoCloseable {

    @Override
    public void close() throws Exception {
      lock.unlock();
    }

  }

  private final Lock lock;

  private final Unlocker unlocker = new Unlocker();

  public CloseableLock(Lock lock) {
    this.lock = lock;
  }

  public AutoCloseable lock() {
    this.lock.lock();
    return unlocker;
  }

}

使用：

CloseableLock lock = new CloseableLock(new ReentrantLock());

try (AutoCloseable unlocker = lock.lock()) {
    // lock is acquired, automatically released at the end of this block
} catch (Exception it) {
    // deal with it
}

让CloseableLock实施java.util.concurrent.locks.Lock可能会很有趣。

答案 8 :(得分：0)

根据Stephen的回答和user2357112的想法，我编写了以下课程。

MyLock类本身不可关闭，强制类的用户调用get（）。

public class MyLock  {
    public class Session implements AutoCloseable {
        @Override
        public void close() {
            freeLock();
        }
    }

    private ReentrantLock reentrantLock = new ReentrantLock();

    public Session get() { 
        reentrantLock.lock();
        return new Session();
    }

    private void freeLock() {
        reentrantLock.unlock();
    }
}

这是一个典型的用途：

MyLock myLock = new MyLock();
try( MyLock.Session session = myLock.get() ) {
    // Lock acquired
}

答案 9 :(得分：0)

这是另一个行之有效的解决方案，并且效率很高，但每个锁定请求的ThreadLocal查找代价却很大。此解决方案缓存AutoCloseable部件/包装器，并在每个线程的基础上重新使用它。

首先，我们在一个普通的ResourceLock周围有一个包装器类Lock，我们将拥有许多包装类。这是我们要重用的部分。包装器实现了Lock接口，因此其行为类似于普通的Lock但可以自动关闭：

public class ResourceLock implements AutoCloseable, Lock {

    private Lock lock;

    public ResourceLock(Lock lock) {
        this(lock, true);
    }
    
    public ResourceLock(Lock lock, boolean eagerLock) {
        this.lock = lock;
        
        if (eagerLock) {
            lock.lock();
        }
    }

    public void lock() {
        lock.lock();
    }

    public void lockInterruptibly() throws InterruptedException {
        lock.lockInterruptibly();
    }

    public Condition newCondition() {
        return lock.newCondition();
    }

    ResourceLock setLock(Lock lock) {
        this.lock = lock;

        return this;
    }

    public boolean tryLock() {
        return lock.tryLock();
    }

    public boolean tryLock(long time, TimeUnit unit) throws InterruptedException {
        return lock.tryLock(time, unit);
    }

    public void unlock() {
        lock.unlock();
    }

    @Override
    public void close() {
        lock.unlock();
    }
}

在没有可重用形式的情况下，您可以像这样简单地使用它：

try (ResourceLock ignore = new ResourceLock(rwl.writeLock())) {
    // Resource locked in here
}

或者我们可以添加一个具有缓存功能的包装器，该包装器将使我们每个线程重用ResourceLock个对象。

public class ResourceLockCache {

    private final Lock lock;
    private final Supplier<ResourceLock> cachingStrategy;

    public ResourceLockCache(Lock lock) {
        this.lock = lock;

        final ThreadLocal<ResourceLock> strategy = new ThreadLocal<ResourceLock>() {

            @Override
            protected ResourceLock initialValue() {
                return new ResourceLock();
            }

        };

        this.cachingStrategy = strategy::get;
    }

    public ResourceLockCache(Lock lock, Supplier<ResourceLock> cachingStrategy) {
        this.lock = lock;
        this.cachingStrategy = cachingStrategy;
    }

    public ResourceLock getAsResource() {
        final ResourceLock activeLock = cachingStrategy.get();

        activeLock.setLock(lock);

        return activeLock;
    }

    public ResourceLock getAsResourceAndLock() {
        final ResourceLock activeLock = cachingStrategy.get();

        activeLock.setLock(lock);
        activeLock.lock();

        return activeLock;
    }
}

现在，我们可以重复使用每个自动关闭的锁了：

ResourceLockCache rlc = new ResourceLockCache(new ReentrantLock());
// Or this to change caching strategy to new object per lock
ResourceLockCache rlc2 = new ResourceLockCache(new ReentrantLock(), ResourceLock::new);

try (ResourceLock ignore = rlc.getAsResourceAndLock()) {
    // Resource locked in here
}

还有一个ReadWriteLock变体，可以满足更复杂的锁定需求。它实现了ReadWriteLock接口，因此它更加通用，因为您可以使用诸如tryLock等复杂的锁定策略：

public class ResourceRWLockCache implements ReadWriteLock {

    private final ReadWriteLock rwl;
    private final Supplier<ResourceLock> cachingStrategy;

    public ResourceRWLockCache(ReadWriteLock rwl) {
        this.rwl = rwl;

        final ThreadLocal<ResourceLock> strategy = new ThreadLocal<ResourceLock>() {

            @Override
            protected ResourceLock initialValue() {
                return new ResourceLock();
            }

        };

        this.cachingStrategy = strategy::get;
    }

    public ResourceRWLockCache(ReadWriteLock rwl, Supplier<ResourceLock> cachingStrategy) {
        this.rwl = rwl;
        this.cachingStrategy = cachingStrategy;
    }

    public ResourceLock readLock() {
        final ResourceLock activeLock = cachingStrategy.get();

        activeLock.setLock(rwl.readLock());

        return activeLock;
    }

    public ResourceLock readLockAndLock() {
        final ResourceLock activeLock = cachingStrategy.get();

        activeLock.setLock(rwl.readLock());
        activeLock.lock();

        return activeLock;
    }

    public ResourceLock writeLock() {
        final ResourceLock activeLock = cachingStrategy.get();

        activeLock.setLock(rwl.writeLock());

        return activeLock;
    }

    public ResourceLock writeLockAndLock() {
        final ResourceLock activeLock = cachingStrategy.get();

        activeLock.setLock(rwl.writeLock());
        activeLock.lock();

        return activeLock;
    }
}

ResourceRWLockCache rwl = new ResourceRWLockCache(new ReentrantReadWriteLock());
// Or this to change caching strategy to new object per lock
ResourceRWLockCache rwl2 = new ResourceRWLockCache(new ReentrantReadWriteLock(), ResourceLock::new);

try (ResourceLock ignore = rwl.writeLockAndLock()) {
    // Resource locked in here
}

希望该解决方案可以通过重新使用资源释放处理程序来帮助实现单锁和多锁策略。

答案 10 :(得分：-1)

我认为带有锁和 val streamingConnection by instance<StreamingConnection>() streamingConnection.subscribe(Topics.OUTPUT_ORDER, OrderHandler()) streamingConnection.subscribe(Topics.OUTPUT_TRANSACTION, TransactionHandler()) 的简单util方法比使用带锁的try-with-resource语句要好。

赞：

Runnable

用法示例：

public static void locked(Lock lock, Runnable r) {
    lock.lock();

    try {
        r.run();
    } finally {
        lock.unlock();
    }
}

优势：

  • 没有为try-with-resource创建虚拟变量。
  • 我认为这很清楚。

缺点

  • 为每个调用分配一个locked(lock, () -> { // Do your stuff }); 实例，其他一些解决方案则避免了这种情况。但这在几乎所有情况下都是微不足道的。
  • 仅在可以使用Java 8时有效。
相关问题
最新问题