HashMap 和 ReentrantLock 的并发问题

Question

I have a piece of code that on startup creates a HashMap of key to ReentrantLock.

void constructor() {
        this.lockMap = new HashMap<>();
        for (int i=0; i<100; i++) {
             this.lockMap.put(i, new ReentrantLock(true));
        }
}

During concurrent execution, I try to lock the lock inside the lockMap in the following manner:

runConcurrently() {
         ii = 10;
         if (!lockMap.containsKey(ii)) {
                log.error("lock id is not found in the lockMap " + ii);
         }
        
         locked = lockMap.get(ii).tryLock();
         if (!locked) {
             return;
         }
         runCriticialSection();
         lockMap.get(ii).unlock();
    }

    void runCriticialSection() {
       log.info("hello");
       log.info("I'm here");                                                      
    }

so here is what I have seen happen once in while every 4 hours the code is running, in a very rare occurrence.

I see these logs:

hello.
hello.
I'm here.
I'm here.

and then I see this log right after on third time accessing the hasmap on the same key ii =10:

lock id is not found in the map 10.
NullPointerExeception ... trying to access the map.

where I should see in guaranteed ordering:

hello.
I'm here.
hello.
I'm here.

The Hashmap never gets modified during execution at all.

is there an issue with hashmap not being concurrent hashmap? is get, not threadsafe in absence of modifications? I am specifically not using it due to locking slowness in concurrent hasmap. But the hashmap is only created on startup and never modified after. I find it very weird where it seems the lock has been acquired twice and it seems like the element is missing from the map.

Answer 1

There is no concurrency issue with the map itself, if the map is never modified after the constructor . If so, threads will only ever see that final version of the map. Else, the behaviour is undefined.

No exclusive access of the critical section

From your output, it appears that (at least) two threads accessed runCriticialSection simultaneously.

This is due to the fact that you are using a different lock for each value of ii . A lock only excludes another thread from locking it, if that other threads uses that same lock! Thus, threads that do not use the same value of ii , will effortlessly run runCriticialSection simultaneously. That can result in the described output anomaly as shown above, as follows:

1. Thread 1 executes log.info("hello");
2. Thread 2 executes log.info("hello");
3. Thread 1 executes log.info("I'm here");
4. Thread 2 executes log.info("I'm here");

If you want exclusive access to a section, always use the same lock surrounding that section .

Coding problems

When the check fails that ii maps to a lock, you should not continue but instead return or throw an exception. If you don't, locked = lockMap.get(ii).tryLock(); throws a NullPointerExcetpion , because lockMap.get(ii) returns null .

Between locking the lock and unlocking it, you are running user code, in the form of runCriticalSection . If you change the implementation of that method later and it starts throwing things: your lock will never unlock! Always use try ... finally with a lock.

Fixing these issues, could lead to the following code:

if (!lockMap.containsKey(ii)) {
    log.error("lock id is not found in the lockMap " + ii);
    return;
}
locked = lockMap.get(ii).tryLock();
if (!locked) {
    return;
}
try {
    runCriticialSection();
}
finally {
    lockMap.get(ii).unlock();
}

Actually, I would just put the lock in a local variable, but that is a matter of opinion.

ReentrantLock lock = lockMap.get(ii);
if (lock == null) {
    log.error("lock id is not found in the lockMap " + ii);
    return;
}
locked = lock.tryLock();
if (!locked) {
    return;
}
try {
    runCriticialSection();
}
finally {
    lock.unlock();
}