Class AutoCloseableLock

  • All Implemented Interfaces:
    java.lang.AutoCloseable
    Direct Known Subclasses:
    AutoCloseableMultiLock, AutoCloseableSingleLock

    public abstract class AutoCloseableLock
    extends java.lang.Object
    implements java.lang.AutoCloseable
    Concrete implementations are expected to lock their inner lock(s) in their own constructor.
    • Constructor Detail

      • AutoCloseableLock

        public AutoCloseableLock()
    • Method Detail

      • ofMany

        public static AutoCloseableLock ofMany​(java.util.concurrent.locks.Lock... locks)
      • close

        public void close()
        N.B. Since concurrent calls to close() is considered to be an error, there is no point in trying to optimize concurrent access via fine-grained locking or some lock-free construct (e.g. AtomicBoolean). The synchronized keyword on close is expected to be very cheap in the non-contended case (which, as stated above, is expected to always be true unless we have a bug). Therefore, it is more valuable to minimize the overhead of instances of this class via a primitive closed boolean protected by coarse synchronization than to introduce one more object to each instance of AutoCloseableLock.
        Specified by:
        close in interface java.lang.AutoCloseable
      • unlock

        protected abstract void unlock()
        Concrete implementations should do whatever work is required to unlock their inner lock(s).