ReentrantLock的一个问题

今天在回顾java并发编程时遇到一个问题,有点奇怪
代码如下

class BlockMutex {    private Lock lock = new ReentrantLock();    public BlockMutex() {        lock.lock();    }    public void f(String name) {        lock.lock();        System.out.println(name+" lock acquired in f() ");    }}

BlockMutex是一个可能存在并发问题的资源,所以我使用lock以实现同步,创建该对象的线程在创建的时候就会持有对象锁,如构造器,在执行f()方法时候也要先申请锁

class BlockThread implements Runnable {    //线程创建BlockThread同时就持有了blockMutex锁    private BlockMutex blockMutex = new BlockMutex();    public BlockMutex getBlockMutex() {        return blockMutex;    }    @Override    public void run() {        System.out.println("waiting lock in f()");        blockMutex.f("BlockThread");        System.out.println("broken out of blocked call");    }}

这是一个Task task初始化的时候,该task就会持有锁，当task执行run方法的时候,会执行f()函数,因为BlockThread会初始化BlockMutex时就持有了BlockMutex的对象锁,而ReentrantLock是支持重入的,所以BlockThread理所应当继续执行f()方法

public static void main(String[] args) throws InterruptedException {        BlockThread blockThread=new BlockThread();        Thread thread = new Thread(blockThread);        thread.start();        TimeUnit.SECONDS.sleep(1);        System.out.println("main has finished ");    }

在main函数中进行测试
运行结果如下

waiting lock in f()main has finished 

我感觉奇怪的是blockThread线程在执行时竟然一直阻塞在f()方法中，按理说BlockThread已经持有了BlockMutex的对象锁,不应该继续申请锁.经过一段时间思考后我明白了blockThread线程并没有持有BlockMutex的对象锁,blockThread初始化是在主线程中进行,而锁的申请是在构造器中完成，所以持有BlockMutex的对象锁是主线程，为了验证这一思想,我们只要让主线程执行f()方法，如果无等待执行成功则我们这一思想成立,更改main函数如下

public class LockInterruptTest {    public static void main(String[] args) throws InterruptedException {        BlockThread blockThread=new BlockThread();        Thread thread = new Thread(blockThread);        blockThread.getBlockMutex().f("main");        thread.start();        TimeUnit.SECONDS.sleep(1);        System.out.println("main has finished ");    }}

运行结果

main lock acquired in f() waiting lock in f()main has finished 

猜想成立