java强制获取锁？

Question

I am working with a somewhat outdated workflow engine, it allows for defining an individual step that executes Java code, but not more than this.

Each invocation of a workflow process operates in its own thread, with any subprocesses executing in the same thread synchronously.

The workflow engine does not allow for capturing of all exceptions that occur in a process. I need to make some subprocesses operate single-threaded, ie to wait if another thread is executing the subprocess.

All I could come up with so far is to acquire a lock at the first step in a subprocess, and release it at the end steps. If an exception occurs in the process, it isn't always possible to capture it.

... s_lock = new ReentrantLock(); ...
... s_timeout = 10; ...

public static void acquireLock() throws InterruptedException {
    if( !s_lock.tryLock(s_timeout, TimeUnit.SECONDS)) {
        System.out.println("WARN: Forcing acquire of lock.");
        s_lock = new ReentrantLock();   // discard old lock and create a new one
        s_lock.lock();
    }
}

public static void releaseLock() {
    if( s_lock.isHeldByCurrentThread()) {
        s_lock.unlock();
    } else {
        System.out.println("WARN:  lock not held by thread.");          
    }
}

There must be a better way? Is it possible to automatically release the lock if a thread terminates?

Answer 1

Is it possible to automatically release the lock if a thread terminates?

Not with any of the standard Lock implementations. AFAIK, they all have the restriction that only the thread that acquired a lock can release it. So in your use-case where each workflow process is in a different thread, a later workflow process cannot cannot break a lock abandoned when an earlier process fails.

But all is not lost. The javadoc for Lock.unlock() says this:

Implementation Considerations

A Lock implementation will usually impose restrictions on which thread can release a lock (typically only the holder of the lock can release it) and may throw an (unchecked) exception if the restriction is violated. Any restrictions and the exception type must be documented by that Lock implementation.

Note that the restriction is not mandated. So you could write your own Lock implementation without the restriction on unlock() .

Furthermore, if you can guarantee that the threads that run workflow processes are not reused, there is a scheme that could be used to break the lock safely .

• When a thread acquires one of these locks, it passes a tuple consisting of the current Thread object and the lock to a separate lock monitor thread.

• The lock monitor thread periodically scans the tuples for all outstanding locks.

• For each tuple, the monitor calls Thread.isAlive() to test if the thread holding the lock is still running. When a thread with a lock is no longer running, the monitor thread unlocks the lock, and discards the tuple.

This unfortunately entails polling, but you should be able to implement this so that the monitor thread only polls while there are locks in acquired state.

---

Implementing the custom Lock class and the lock monitor would not be trivial ...

---

By the way, your current approach is flawed:

• If the timeout is small, there is a risk that you will break the lock while the original workflow process is still running.

• If the timeout is large, then a failed workflow process may block other workflow processes for too long.

• There is no "half-way" point where you get guaranteed reliable locks and responsiveness.